Mesa Threaded OpenGL Dispatch Finally Landing, Big Perf Win For Some Games

[haagch]

I finally tried Borderlands with glthread (thanks steam for breaking yet another application) and it finally has playbable framerates:

[indepe]

In my opinion, Mesa could start with measuring just FPS difference of normal-vs-glthread via alternate frame rendering during the first 1000 frames, and then:

• automatically adapt to changes by repeating the measurement with probability P=0.001 (1 measurement per 1000 frames),
• repeat the measurement if Mesa detects changes in the type&structure of OpenGL requests,
• gradually work on "distributing & sinking the measurement down" to sub-frame concepts if possible,
• gradually work on "distributing & raising the measurement up" to multi-frame concepts if possible. mareko.

Yes, it should keep updating its measurements, since apps and games go through different graphics that may be as different as two games.

[bridgman]

Seems like these different instruction pointers cannot do very much. I base my experience on looking at CPU versus GPU rendering in a 3D program like Blender: the usual recommendation is to set the tile size small for CPU rendering, large for GPU rendering. As it is rendering, you can see little orange highlight lines appear in the render result window, showing which tiles are currently being processed: this is as many threads as your hardware will allow. On a CPU this could typically be 4 or 8, but on a GPU it is always 1. Hence my conclusion that GPUs are essentially single-threaded.

Every different pixel or vertex is a separate "little thread" - every chunk of 64 pixels or vertices is a "big thread" with separate instruction pointer. I'm guessing that the tiles you are seeing are larger than 64 pixels ?

I think what you are seeing is a single CPU thread per GPU, which feeds work to the GPU that might involve hundreds or thousands of threads.

[ldo17]

Every different pixel or vertex is a separate "little thread" - every chunk of 64 pixels or vertices is a "big thread" with separate instruction pointer.

Please, let’s not start muddying the meaning of the term “thread”. A “thread” is an instruction stream, no more, no less. So “SIMD” means “single instruction stream”, which means “single thread”.

Just to recap, with the Blender Cycles renderer, you can see multiple threads in action with CPU rendering, but only a single thread at a time with GPU rendering.

[TheBlackCat]

In my opinion, many single-threaded applications can be broken down into an unexpectedly high number of tiny concurrent tasks forming a dependency graph. An underlying problem usually inherently contains some concurrency.

Some can, some can't. But even when they can, in principle, it is often extremely difficult in practice due to the overhead of communicating between the tasks or the cost of preventing tasks from interfering with each other. In practice, even if a task could in principle be parallelized the cost of doing so is often larger than the benefit you get from parallelizing. And even when that isn't the case, there are often only a handful of tasks to do, not the dozens or hundreds the GPU would help you with. Add to that the fact that parallel programming in imperative languages tends to be very complicated and error-prone, and you end up with a situation where there isn't a huge incentive to massively parallelize most tasks. Instead, multiple cores lets you multitask better, which is good enough for most everyday use-cases anyway.