I am now having on-going email conversations with Nvidia about this.  They also mentioned using swapgroups so I'll be happy to experiment with that to see if there is some joy to be had there.  The purpose of swapgroups, however was to provide a second level of sychronization after frame sync (see
http://www.donburns.net/OSG/Articles/Synchronization/  under "SwapReady").  On SGI's this was implemented in the guts by hardware (remember the bnc connectors on IR2? ), and used to synchronize separate pipes.

NVidia's defense to why they block rendering beyond two frames ahead, is that not doing so would incur memory leaks in the driver because the CPU could render ahead indefinitely.  I'm not sure the person I'm talking with is dead familar with the drivers because it would seem that this should be implemented with a high-water marker in the queue, and not by choosing to block in Swapbuffers (imagine if you were rendering single buffered and never called Swapbuffers). 

Swapbuffers is a poor choice for a blocking point.  It has been common practice to begin the next frame by sending down the next clear, projection matrix and any other information that does not require fresh dynamic data, directly after issuing a swapbuffers that returns immediately.  The application can then have the choice to block sometime later. In the case where we have multiple windows, we can use _one_ block point in the thread, rather than multiple blocks in swapbuffers.

-don

On 10/18/06, Colin Dunlop <[EMAIL PROTECTED]>
Hi Don,
 
did this used to work on SGI's from the mid 90's?
This extension provides the capability to synchronize the buffer swaps
>  of a group of GLX drawables.  A swap group is created, and drawables are
>  added as members to the swap group.  Buffer swaps to members of the swap
>  group will then take place concurrently.
Perhaps the chaps who authored the above work for NVidia now? ;-)
 
Just for your record I get the same identical performance drop factor using Coin3D Inventor
SoQt app on a QuadroFX3500 - so it does indeed seem to be down at the driver level. The
frame stats are an exact division of number of windows to monitor retrace.
 
Colin.
----- Original Message -----
From: Don Burns
Sent: Wednesday, October 18, 2006 2:08 PM
Subject: Re: [osg-users] Multi-window performance

I'm trying to raise the issue with NVidia, but so far I haven't gotten a resonse from my contacts over there. 

Just so you are not stuck, the work around, of course, is to use a single window with multiple viewports.  However, this may not work for everyone, especially if you are embedding several windows in different parts of a GUI, or need your viewports to be in non-contiguous space on the screen.

-don

On 10/18/06, Sebastian Olsson <[EMAIL PROTECTED]> wrote:
Don Burns wrote:
> The issue is two windows on one card, single threaded.  This should
> _not_ cause the performance to drop to 30 hz., but it does...

I can just confirm that the same thing happens here... Running single
threaded on Quadro FX and winXP I get 30hz with two windows. And in my
case I need four windows...leaving me with just 15hz...

/Seb

_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/


_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to