# Is using a dedicated thread just for sending gpu commands a good idea?

The most basic game loop is like this :

while(1)
{
update();
draw();
swapbuffers();
}


This is very simple but have a problem : some drawing commands can be blocking and cpu will wait while he could do other things (like processing next update() call).

Another possible solution i have in mind would be to use two threads :

one for updating and preparing commands to be sent to gpu, and one for sending these commands to the gpu :

//first thread
while(1)
{
update();
render(); // use gamestate to generate all needed triangles and commands for gpu
// put them in a buffer, no command is send to gpu
// two buffers will be used, see below
}

while(1)
{
wait();              // wait for second thread for data to come
send_data_togpu();   // send prepared commands from buffer to graphic card
swapbuffers();
}


also : two buffers would be used, so one buffer could be filled with gpu commands while the other would be processed by gpu.

Do you thing such a solution would be effective ? What would be advantages and disadvantages of such a solution (especially against a simpler solution (eg : single threaded with triple buffering enabled) ?

EDIT : I have taken a real example to show a situation where there would be an advantage :

Let's say i have a scene which consist of rendering same entity a lot of times (like in a RTS) :

in this example :

• updating world take 100 ms (because there is lot of entities)
• sending commands to gpu almost nothing (only calls to gldrawelements for the same entity, vertex buffers only sent once) (almost 1ms)
• scene rendering by gpu is also heavy, take 100 ms

total = ~200 ms (or 5 fps)

I dont think gpu could be draw something during update procedure because gpu doesnt have any idea when scene start (and cant assume glclear = beginning of scene rendering)

now lets say the system is using two independant threads :

• update take 100ms
• sending cmds take 1ms
• next update can already start no need to wait for gpu
• scene rendering take 100ms

total = ~100 ms (actually a little more than this because of synchronisation)

• There's actually no need to have two CPU threads to get the second scenario described in your edit. As I mentioned, the driver will already double-buffer the GPU commands behind the scenes. As long as you don't do anything that explicitly forces the CPU and GPU to wait for each other, you should get scenario 2 even with just one CPU thread. The boundary of one frame and the next is defined by the SwapBuffers call, so the driver has no problem identifying that. – Nathan Reed Jul 7 '12 at 18:16

• @tigrou (1) call glFinish. (2) it's driver-dependent. – Nathan Reed Jul 7 '12 at 18:17