Thank you both for your replies. I think this little bit from Robert might be the issue:
robertosfield wrote: > However, if OpenGL FIFO fills up because the rate at which you are pushing > data into it exceeds the rate at which it's been emptied then the application > thread will stall and the draw dispatch times will go up. Sometimes you can > see some rather no linear draw dispatch times due to small changes in load on > the GPU suddenly causing the app to stall. Even when this happens there is > still a bit of leeway before > you start dropping frames. > The workload on the GPU has increased, and I can only assume that it's now not processing the commands as fast as it used to. So since the output is taking longer, and the input is equal, the driver will need to wait for the queue to empty a bit every now and then. We're not changing the amount of data read back from the GPU (I doubt we even read back anything), I'm not changing anything in the program. Brian, if I'm locked to VSync (which I'm not in my test case), and the GPU has more work to do than the CPU, I do NOT expect the command submissions to take longer if I enable these quality options. I'm sending the exact same amount of data and commands, so why would the driver suddenly take longer to queue those commands? The GPU will of course need more time to execute those commands, but I wasn't expecting that to show up under the 'Draw' time, since that time is the 'GPU' time. ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25852#25852 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
