Re: [osg-users] vsync (was: OSG CPU usage)
Paul Martz wrote: It's really implementation dependent. The NVIDIA OpenGL driver on Windows, for example, allows you to issue a certain number of SwapBuffers calls before it blocks. I think the default is 2 calls, but this is controllable with a driver setting and can be as high as 10 (I think). but this basically means that you can't really depend on this functionality for not saturating your CPU, as the video driver might support it, it might allow 2 or more frames to be sent before blocking, etc. :( Akos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
Hi Akos, On Nov 20, 2007 9:34 AM, Ákos Maróy [EMAIL PROTECTED] wrote: Paul Martz wrote: It's really implementation dependent. The NVIDIA OpenGL driver on Windows, for example, allows you to issue a certain number of SwapBuffers calls before it blocks. I think the default is 2 calls, but this is controllable with a driver setting and can be as high as 10 (I think). but this basically means that you can't really depend on this functionality for not saturating your CPU, as the video driver might support it, it might allow 2 or more frames to be sent before blocking, etc. Most drivers you come across will block just fine if you enable vsync, and will allow the CPU to idle while waiting. Not having vysnc is the problem, rather than whether there is blocking or not, you can assume there is blocking as long as vsync. In case where vsync isn't on you potentially detect this and warn the user, or add in your own delay. There are also OpenGL/GLX etc extensions that allow you manually sync with frame boundary rather than rely on blocking from the FIFO, but these functions are not supported on all hardware and when they are aren't always reliably implemented. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
Paul Martz wrote: It's really implementation dependent. The NVIDIA OpenGL driver on Windows, for example, allows you to issue a certain number of SwapBuffers calls before it blocks. I think the default is 2 calls, but this is controllable with a driver setting and can be as high as 10 (I think). but this basically means that you can't really depend on this functionality for not saturating your CPU, as the video driver might support it, it might allow 2 or more frames to be sent before blocking, etc. ...but your process will block when it hits the device-specific limit for swap calls. So, this prevents your process from saturating the CPU (except for those initial few frames). Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
Paul Martz wrote: Vsync is usually on by default, can be toggled on or off by some driver options, and can also sometimes be toggled by OpenGL extensions. but does this mean that if I call rendering blocks unti the next vsync clock tick? Akos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
On Nov 19, 2007 9:25 AM, Ákos Maróy [EMAIL PROTECTED] wrote: Paul Martz wrote: Vsync is usually on by default, can be toggled on or off by some driver options, and can also sometimes be toggled by OpenGL extensions. but does this mean that if I call rendering blocks unti the next vsync clock tick? OpenGL drivers have a FIFO, your app fills the fifo with tokens and data, at the end of the frame you send in a swap buffers token and this goes into the FIFO with everything else. Normally the swap buffers call itself doesn't block (although some implementations do this), but the FIFO itself can only be cleared at the rate for one swap buffers call per frame so it'll fill and once filled up it will effectively block until previous frame was begun dispatching. The driver may allow several frames worth data in the fifo before block, this is driver dependent, and also dependent on just how data you have to pass to OpenGL- if you have massive models the CPU will be block on the FIFO right on the same frame rather than more than one frame begin backed in the FIFO. The end result of this is simpler though - put vsync on, and your frame loop will block and should iddle while its waiting for the FIFO to begin accepting new data. Some OpenGL drivers have been known to CPU resources when waiting rather than idling - ATI drivers were doing this for a while, but I believe this has now been fixed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
On Nov 19, 2007, at 6:02 AM, Robert Osfield wrote: On Nov 19, 2007 9:25 AM, Ákos Maróy [EMAIL PROTECTED] wrote: Paul Martz wrote: Vsync is usually on by default, can be toggled on or off by some driver options, and can also sometimes be toggled by OpenGL extensions. but does this mean that if I call rendering blocks unti the next vsync clock tick? in short: yes. OpenGL drivers have a FIFO, your app fills the fifo with tokens and data, at the end of the frame you send in a swap buffers token and this goes into the FIFO with everything else. Normally the swap buffers call itself doesn't block (although some implementations do this), but the FIFO itself can only be cleared at the rate for one swap buffers call per frame so it'll fill and once filled up it will effectively block until previous frame was begun dispatching. The driver may allow several frames worth data in the fifo before block, this is driver dependent, and also dependent on just how data you have to pass to OpenGL- if you have massive models the CPU will be block on the FIFO right on the same frame rather than more than one frame begin backed in the FIFO. The end result of this is simpler though - put vsync on, and your frame loop will block and should iddle while its waiting for the FIFO to begin accepting new data. Some OpenGL drivers have been known to CPU resources when waiting rather than idling - ATI drivers were doing this for a while, but I believe this has now been fixed. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org bob kuehne founder and ceo - blue newt software www.blue-newt.com734/834-2696 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
but does this mean that if I call rendering blocks unti the next vsync clock tick? It's really implementation dependent. The NVIDIA OpenGL driver on Windows, for example, allows you to issue a certain number of SwapBuffers calls before it blocks. I think the default is 2 calls, but this is controllable with a driver setting and can be as high as 10 (I think). -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
Robert Osfield wrote: As long as vsync is on, as it should almost should be then the CPU load shouldn't be overwhelming with a standard frame loop. you mentioned vsync several times in this discussion. can you elaborate, how this is turned on? I understand what you're saying is that there's a fixed rate (say 60Hz), and the rendering engine would only generate new frames at this rate. thus not 'all the time when it's idle', but basically wait for the next 'tick' that comes at 60Hz, and then render. do I understand correct? Akos ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vsync (was: OSG CPU usage)
Robert Osfield wrote: As long as vsync is on, as it should almost should be then the CPU load shouldn't be overwhelming with a standard frame loop. you mentioned vsync several times in this discussion. can you elaborate, how this is turned on? Vsync is usually on by default, can be toggled on or off by some driver options, and can also sometimes be toggled by OpenGL extensions. CRT monitors paint the screen with an electron gun at typically 60 times a second. After each full screen paint, the electron gun moves back to the start position, often called vblank. When vsync is enabled, your back buffer is swapped to your front (displayed) buffer during vblank. This is usually what you want; if the buffer was swapped while the electron gun was actively painting the display, then the displayed image (for that 1/60th of a second) would contain part of one frame and part of another. This is often referred to as image tearing and is usually avoided by enabling vsync. You usually want to disable vsync when measuring performance. If vsync is enabled, your frame rate is locked to some multiple of 60, such as 60, 30, 15, etc, which prevents you from obtaining an accurate performance measurement. When not measuring performance, you usually want vsync enabled to maintain image quality and eliminate tearing. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
