There is certainly value in multithreading the software side of a rendering engine (for example visibility determination, LOD switching, etc), but the driver still wants things in a nice serial stream
with a minimum of state changes.
So the entire premise of combining multiple command buffers is hostile to the GPU, and the driver, simply because when switching between command buffers generated from one thread and another, it may
have to upload a significant amount of state, and more importantly it does not easily know WHICH state is different, so it would end up uploading the entire state again, this is commonly known as a
context switch and is far from fast (depends on OS and hardware).
Rendering is not necessarily a serial process but our current interface to the hardware is serial, therefore we must optimize solely for this current approach.
Handing processing jobs off to other threads is how console games function in general and I see much value in this approach, but in the end you still want to render your world, your effects, your
lights, and so on in a particular order (lest you end up with flickering due to render order).On 04/18/2010 01:37 PM, Bob Pendleton wrote:
On Sun, Apr 18, 2010 at 12:52 PM, Andre Leiradella wrote:
There’s much more to a rendering subsystem then issuing instructions for the
GPU.
That depends entirely on your definition of the term “Rendering subsystem”.
If it consists of nothing much but the interface between OpenGL and
the GPU, then no, there is not much else. If it include the entire
windowing system then yes, there is a lot more to it.
The term has different meanings to different people and its meaning
can change for the same person depending on the context of a
discussion. Sort of a useless term really.
On 18/04/2010 14:47, Mason Wheeler wrote:
As I understand it, most of the actual hardware rendering is done in
parallel by a multicore array of GPUs anyway. The DX or GL drivers take the
rendering instructions in and parallelize them under the hood. This being
true, there’s not much to be gained from actually issuing the instructions
in parallel, right?
One more thing. The maximum rate at which the GPU can process
rendering commands is the maximum rate at which the CPUs can generate
commands. Yeah, doh! Obvious, right?
Ok, in a multiprocessor system with a killer GPU it is possible that
you could wind up with a GPU that can render commands faster than a
single processor can generate commands. In that case, it would make
sense to have multiple threads sending commands to the GPU.
Is this likely to every happen? Sure, but that just means that the GPU
has enough left over cycles to keep up with other applications.
Bob Pendleton
From: Paulo Pinto
Subject: Re: [SDL] [OpenGL] Multi-thread renderer a good idea?
This is the best way of doing it. Let just one thread take care of drawing,
and send update requests
to him from another threads.
No need to complicate things.
DirectX 11 supports multithreading rendering, but I doubt there is much to
gain from it, when compared
with a proper separation of the application subsystems across processors.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier