   CPU/GPU concurrency on Linux
  Greetings,I have a question for those of you with some expert knowledge of OpenGL and those drivers we have to put up with...I'm coding a (surprise, surprise!) rendering engine whose ultimate goal is to exploit parallel processing to increase rendering speed.One thing I'm currently relying on is that when I call glDrawElements(), the driver will look at my VBO, say "uhum..", push a draw command to the GPU and *return immediately* to the calling thread. So in my main loop, I basically collect rendering jobs from the application, and as soon as my buffer has some amount of geometry in it, I do the glDrawElements() thing.This works fine on Windows (Geforce 8600 GT, newest drivers, nothing special). I get a slight performance increase, just as expected, because while the Geforce is drawing, the main loop happily continues filling it's buffers - concurrency.Now I'm currently sitting before a Ubuntu machine with nvglx drivers (Geforce 7600 GT). And guess what my profiler is telling me? glDrawElements() gulps down 87% of my frame time. Huh.If I enable the concurrent code path which gives me more performance on Windows, performance drops on this machine! I think this is due to the overhead of flushing my rendering buffer about 5 times more often per frame.So, the question is obvious: how come?Are the Linux drivers simply more conservative regarding concurrency? That would be a sad thing, because the platform loses a lot of optimization potential. Or am I perhaps just doing something stupid? As mentioned, I'm using VBO, and for both vertex and index buffers. There are also no expensive state changes involved, all I'm doing is rendering white, unlit cubes...Thanks very, very much in advance for any insights on the subject!   
  If you are calling glFlush, I would recommend against it. You can lose performance due to it. Also, try using glDrawRangeElements since this tells the driver which range your indices will index.   ;  I have been wondering about this myself. Every document I have ever read on the subject tells me the glDraw*() calls operate asynchronously, and the OpenGL engine should only synchronise with my application on calls to glFlush() or swapBuffers(). However, glDraw*() calls feature prominently in my profiler, and swapBuffers never does, which would indicate the opposite behaviour.   ;  Sounds like there is no hardware acceleration. Can you post the output of xdpyinfo?   ;  @V-manI'm not calling glFlush(). I will try using glDrawRangeElements(), thanks for the hint.@swiftcoderYou also answered to my post on the Horde3D forums, am I right?On Windows, SwapBuffers() is the biggest part of my main loop profile, about the same time all the glDrawElements() take on Windows. So the Windows driver lets the hardware run concurrently. Perhaps newer Linux drivers do that too, how old is your glx driver?@deathkrushHardware acceleration works, I'm pretty sure of that. This machine is used for a lot of graphics programming.;Quote:Original post by random task@swiftcoderYou also answered to my post on the Horde3D forums, am I right?Yes.Quote:On Windows, SwapBuffers() is the biggest part of my main loop profile, about the same time all the glDrawElements() take on Windows. So the Windows driver lets the hardware run concurrently. Perhaps newer Linux drivers do that too, how old is your glx driver?A little research just explained that for me - I had left vsync enabled, and the CPU was yielded automagically while my app waited for vsync. Darn Macs with fancy schedulers...   ;  Depending on the driver the same thing can happen in windows, iirc NV's drivers do it and ATI drivers started doing so in the last year or so, although that might only be on Vista as it was in the driver rewrite.   ;  Hmm, seems like I have to do some more profiling on different machines/drivers.Now the 64$ question: How to design a fast renderer when you can't rely on the concurrent behavior of the underlying driver?Is it feasible to do run time measurement, and configure the renderer dynamically? Or just go for the best guess?In a real world application, where there are lots of textures and shaders, and clever state sorting has a big impact on performance, does it make any difference at all?OK, more like question*s*, but this really bugs me at the moment...Thanks for the info, BTW.   ;  CPU/GPU concurrency is very important especially in larger applications or proper games where there is alot of CPU processing to be done. You want to try as best as you can to have them both running concurrently.The way i do it is,MainLoop(){drawFrame //draws simulation modified in prev frame{  glVertex*  glDraw*  ....//all gl commands here, i expect all of them to return immediately//take care not to call glFinish()/glGet or any commands which will stall the pipeline here}//GPU is busy drawingrunGame()//CPU is busy processing next loop{//collect input//all cpu processing}endFrame(){swapBuffers();//synch}}