Has anything ever come of this?

I am struggling with lack of "swap grouping" support on my HP/dual- nvidia cards with a gsync board.

My OpenGL apps are much better with swap groups enabled (NVIDIA glX calls),
 but my OSG apps look bad with nothing being done.

I was just about to hack my own OSG code, but saw this thread.
I can certainly do some testing if that is required..

ml


On Apr 15, 2008, at 3:17 AM, Robert Osfield wrote:

Hi Roland,

Thanks for the submission. I've just reviewed it, but won't merge anything yet. What I may do is merge parts of your changes, such as the extensions support.

The API parts will need further thought/discussion, items such as hardwiring the swap group id and swap barrier id to 1 is items that will obviously have to change. It might be that we just provide a public function for joining swap group and swap barrier, although it might just be more robust to set these up in the init (this way we avoid threading issues), and use extra parameters in Traits structure to control the source group and barrier ID's.

W.r.t compatibility with SGI's swap group/barrier functionality under X11, I wonder if this could be either ignored as the associated hardware/drivers have fallen off the product support at SGI, or emulate the newer NVidia swap group functions at the GraphicsWindow API level, but internally use the SGIX extensions.

Robert.

On Tue, Apr 15, 2008 at 8:58 AM, Smeenk, R.J.M. (Roland) <[EMAIL PROTECTED]> wrote:
Hi Robert,

we've been looking at clustering too. I've added the extension querying to the GraphicsWindowWin32 and GraphicsWindowX11 and a joinSwapGroup method to the GraphicsWindow. I had this code waiting for submission for a few weeks now, but due to this thread I feel urged to get the code out first. We still need to test our cluster properly (on Linux) and will probably be doing this in the coming weeks.

Changes were done against OSG2.2.

kind regards,

Roland Smeenk

From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Robert Osfield
Sent: maandag 14 april 2008 11:40
To: OpenSceneGraph Users
Subject: [osg-users] Feedback sought on osgViewer swap ready support forclusters

Hi All,

I'm looking for feedback from users who have worked on clusters that implement some forms of swap ready synchronization. In particular I'm looking at any hooks into osgViewer to allow users to implement their own swap ready implementation, also a software based swap ready could possibly be implemented as part of the core OSG as well.

The hook to adding a swap ready barrier into the view would look something like:

  viewer.setSwapReadyOperation(myCustomSwapReadyOperation);

Something like complicates the mater is that viewer on each slave of the cluster might have more than one graphics context that its rendering too, so in this case we'll have multiple graphics threads per slave, in which case these threads will need to join a barrier that treats each context like a separate machine or the barrier does a local synchronization of the threads on a machine before joining the cluster swap ready barrier.

I want to come up with a scheme that supports both ways above, but really need a bit more feedback on what goes into users own swap ready codes, i.e. what would your MyCustomSwapReadyOperation look like, i.e. what does it look right now, this will help me better understand how the most appropriate integration into osgViewer could be done.

Robert.




This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

_______________________________________________
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





_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to