The glGet problem is totally separate from the HW latency and causes your rendering to become non-deterministic in that it may drop frames when frame locking to a specified rate. The HW latency is deterministic, which is a good thing because knowing that our sims can adjust accordingly. We have tested the latency from the quadro 5500 through the 5800. We have not tested any of the new fermi-based cards yet. The reason they have the latency is to optimize the pipeline and increase frame rate performance. So at this point, I do not expect fermi-based cards to be any different. Latency will be first thing we test when we get our hands on a Quadro 6000 later this year.
________________________________ From: osg-users-boun...@lists.openscenegraph.org on behalf of Buckley, Bob CTR MDA/DES Sent: Fri 8/6/2010 6:02 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG and vsync (UNCLASSIFIED) Whom at nVidia confirmed this built in latency and for what product line?Inserting a glGet is inducing latency, not something built in. Bob -----Original Message----- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Bunfield, Dennis AMRDEC/AEgis Sent: Monday, June 28, 2010 12:39 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG and vsync (UNCLASSIFIED) Classification: UNCLASSIFIED Caveats: FOUO Yes we found this through internal testing. Nvidia later confirmed it. This isn't related to double or triple buffering either. The pipeline as explained to me is similar to a break line in a car. Everything works well unless you inject an air bubble into the brake line. This would be similar to doing certain glGet's commands. The driver will tell the GPU to stop it's processing so that it can handle your glGet request. So for real-time programming you really need to be aware of this -- and don't do it --. Depending upon the type of readback you are performing you will introduce a momentary lag in the system because the GPU has to stop everything it is doing to respond back to you. glReadPixels behaves a little differently as long as the pixel format aligns with the frame buffer format where the driver can just dma that framebuffer back to the cpu. If your pixel formats are not aligned you will get bad performance again, because the GPU will have to stop what it is doing and reformat the data to send back. -----Original Message----- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Bruce Wheaton Sent: Monday, June 28, 2010 12:46 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG and vsync (UNCLASSIFIED) On Jun 23, 2010, at 3:35 PM, Bunfield, Dennis AMRDEC/AEgis wrote: > For Nvidia cards there is a built in 2 frames of latency. So even after > your sync you won't see the image you updated come out the DVI until 2 > render frames later. Where does this information come from Dennis? Where is this delay happening? I doubt it's triple buffering, since the extra memory would have to be accounted for, and it makes tearing mostly impossible (as on the Mac). So you believe the Gl command queue is buffered/delayed somewhere? Doesn't that have huge implications for things like glGet, making them impossible to use without at least halving the frame rate? Bruce _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g Classification: UNCLASSIFIED Caveats: FOUO _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
<<winmail.dat>>
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org