Hi, Here we had a setup with 2 NVidia cards and 4 screens on Linux (2 twinviews), on the application side we used a CompositeViewer with 2 views and 4 cameras (2 contexts), and we had a solid 60fps without problems :
http://www.tharsis-software.com/1-29972-Realisation.php?vid=18 But the application was pretty simple (except the 5842x768 video to render). As JP said, wath's your osgViewer configuration, are you using a CompositeViewer ? Cheers, On Wed, Oct 20, 2010 at 8:57 AM, J.P. Delport <jpdelp...@csir.co.za> wrote: > Hi John, > > > On 19/10/10 21:11, John Kelso wrote: > >> Hi, >> >> We have a pretty simple setup. 4 graphics cards, each is its own X11 >> display, as in :0.0, :0.1, :0.2, :0.3. No Twinview or Xinerama. >> >> We've found out that our hardware doesn't support mosaic mode. We >> installed >> the latest Nvidia driver and it made no difference. We're really sort of >> completely stumped at this point. >> >> Can anyone think of any test we can try to determine the cause of the >> problem? >> >> Is anyone else on the list using a similar setup? If so, have you seen >> this problem? >> > > I'm not sure we have the exact same setup, but we've recently had 4 screens > connected to 2 cards with each screen a separate X screen (i.e. you can't > drag windows between screens). Each screen had it's own osgviewer running in > a thread (iow one process, but 4 viewers in threads) and each viewer had its > own scene (basically just a 60Hz video stream). We had no problems running > all 4 at 60Hz. I suppose this is not much different from you running 4 > separate processes though. > > I think it might be worthwhile to create a simple test case for this that > people can try out on their setups with variations in cards, drivers and OSG > versions. > > In your tests, are you using CompositeViewer? > > rgds > jp > > > >> Thanks, >> >> John >> >> On Mon, 11 Oct 2010, J.P. Delport wrote: >> >> Hi, >>> >>> On 07/10/10 23:39, John Kelso wrote: >>> >>>> Hi, >>>> >>>> Many thanks for your speedy reply. >>>> >>>> We were considering trying mosaic mode if we couldn't come up with >>>> something >>>> that would fix the problem with our current display configuration. >>>> >>>> Switching to mosaic mode will require a good bit of code rewrite, but if >>>> that's the way to go I guess it's worth it in the long run. >>>> >>>> I'll look into WGL_NV_swap_group extension too. >>>> >>>> Any other ideas from the group? >>>> >>> >>> How is the nvidia driver set up? Single X screen, or screen per card? >>> Twinview? Xinerama? >>> >>> We've found strange driver issues with X screens spanning multiple cards. >>> >>> jp >>> >>> >>>> Thanks, >>>> >>>> John >>>> >>>> On Thu, 7 Oct 2010, Wojciech Lewandowski wrote: >>>> >>>> Hi John, >>>>> >>>>> This is odd but it sounds bit like swap buffers of the windows are >>>>> somehow >>>>> waiting for each other. I believe that WGL_NV_swap_group extension >>>>> is not >>>>> used by OSG. This extension could possible help you there. >>>>> >>>>> But I could be wrong on above. It is not really my main point I >>>>> wanted to >>>>> mention. Instead I wanted to suggest you check SLI mosaic mode. We >>>>> have done >>>>> some experiments on 4 channels on Linux / Nvidia QuadroPlex D2 in the >>>>> past. >>>>> At first we tried to go the same path as you describe. But later we >>>>> have >>>>> read somewhere that fastest method is to use one window filing whole >>>>> desktop >>>>> and split this window into 4 screen quarter slave views. Each slave >>>>> view >>>>> could be positioned so that it covers one monitor output. Such 4 >>>>> monitor >>>>> setup is possible with QP D2 drivers in SLI mosaic mode. >>>>> >>>>> Using producer config files one may easily create a .cfg that could be >>>>> passed from command line to osgViewer and set 4 channel slaves on >>>>> single >>>>> window. Best thing with using one window is that all four views use >>>>> the same >>>>> context so GL resources are shared and all four are swaped at once with >>>>> single SwapBuffer call. >>>>> >>>>> In our project we ended up with 4 channel rendering using SLI mosaic >>>>> and we >>>>> were pleasently surprised how fast it was performing in comparison to >>>>> separate gl contexts on 4 windows. You may check SLI mosaic if you >>>>> haven't >>>>> done this before.... >>>>> >>>>> Hope this helps, >>>>> Wojtek Lewandowski >>>>> -------------------------------------------------- >>>>> From: "John Kelso" <ke...@nist.gov> >>>>> Sent: Thursday, October 07, 2010 9:35 PM >>>>> To: <osg-users@lists.openscenegraph.org> >>>>> Subject: [osg-users] OSG seems to have a problem scaling to multiple >>>>> windows >>>>> on multiple graphics cards >>>>> >>>>> Hi all, >>>>>> >>>>>> Our immersive system is a single host computer with 8 cores and 4 >>>>>> graphics >>>>>> cards running Linux. (1) We are using OSG 2.8.3. >>>>>> >>>>>> We are having a heck of a hard time getting OSG to take advantage of >>>>>> our multiple graphics cards. Help! >>>>>> >>>>>> Here's what we did: >>>>>> >>>>>> If we load a fairly large model into our test program we can get a >>>>>> frame >>>>>> rate of about 150 FPS when displaying in a single window. (2) We are >>>>>> running single-threaded, and assign to a specific core. >>>>>> >>>>>> When we background this and run a second copy of the program to >>>>>> another >>>>>> graphics card and core then both programs run at 150 FPS. Same >>>>>> thing for >>>>>> running three and four copies at once. >>>>>> >>>>>> That is, four processes using four graphics cards on four cores run >>>>>> just >>>>>> as >>>>>> fast as a single process. All four cores are at near 100% CPU >>>>>> utilization >>>>>> according to top. So far, so good. >>>>>> >>>>>> Now we modify the program to load the model and create multiple >>>>>> windows on >>>>>> multiple cards. There's one window per card and each uses a different >>>>>> core. (3) >>>>>> >>>>>> The threading model is "CullThreadPerCameraDrawThreadPerContext", the >>>>>> default chosen by OSG. The environment variable >>>>>> OSG_SERIALIZE_DRAW_DISPATCH >>>>>> is not set, so it defaults to ON, which we think means draw in serial. >>>>>> >>>>>> If we draw to four windows on four different cards we get about 36 >>>>>> FPS. >>>>>> There are four different cores being used, and each has about 25% >>>>>> of the >>>>>> CPU. This probably this makes sense as the draws are in serial. 150 >>>>>> FPS/4 >>>>>> is about 36 FPS. As expected, we get nearly identical results if we >>>>>> create >>>>>> four windows on a single card using four different cores. >>>>>> >>>>>> If we set OSG_SERIALIZE_DRAW_DISPATCH=OFF we hope to see better >>>>>> performance, >>>>>> but with four windows on four graphics cards we only get 16 FPS! There >>>>>> are >>>>>> four different cores bring used, one at about 82%, and the other >>>>>> three at >>>>>> 75%, but what are they doing? Again, we get nearly identical >>>>>> results if >>>>>> using four windows on a single card. >>>>>> >>>>>> So.... >>>>>> >>>>>> How can we get OSG to draw to four windows on four cards in one >>>>>> process as >>>>>> fast as running four separate processes? >>>>>> >>>>>> Any pointers or suggestions are welcome. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> John >>>>>> >>>>>> >>>>>> 1 - Our immersive system consists of 3 projectors and a console each >>>>>> driven >>>>>> by an Nvidia FX5800 graphics card all genlocked for 3D stereo >>>>>> display. The four graphics cards are in two QuardoPlex Model D2 units >>>>>> connected to the host. The host computer is an 8 core Dell Precision >>>>>> T5400 running 64 bit Linux (CentOS 5.5). We are using Nvidia driver >>>>>> version 195.36.24 >>>>>> >>>>>> 2 - the program is attached- it uses only OSG. We run our tests with >>>>>> _GL_SYNC_TO_VBLANK=0 to get the maximum frame rate. >>>>>> >>>>>> 3 - one graphics context per window and one camera per window >>>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>>> 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 >>>> >>>> >>>> >>> >>> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > -- > This message is subject to the CSIR's copyright terms and conditions, > e-mail legal notice, and implemented Open Document Format (ODF) standard. > The full disclaimer details can be found at > http://www.csir.co.za/disclaimer.html. > > This message has been scanned for viruses and dangerous content by > MailScanner, and is believed to be clean. MailScanner thanks Transtec > Computers for their support. > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Serge Lages http://www.tharsis-software.com
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
