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: > [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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
