Nvidia is known for having problems scaling on multiple displays, basically if you have 4 windows on 4 different cards the driver will tell each card to render the content of all four windows, resulting in 4 times the needed number of setup trafic. This principle is there to make is possible to drag rendering windows from one card to another.
In the quadro line of drivers you can set a display affinity mask to limit which card is responciple for handling a given context. If you needed exactly 3 displays running at the same rez, then nvidias 3d surrond setup should possibly be a way of getting SLI to handle the multiple card optimisation for you. AMD is supposed to hadle this stuff better and I have in the past seen significant performance increase when moving from nvidia to AMD hardware with multiple cards. I have never experimented with the quadro line of cards. Brgs. Ralf On 19 October 2010 22:30, John Kelso <ke...@nist.gov> wrote: > Well, at least we don't feel so lonely anymore! > > But seriously, I'm sort of at a loss about what to try next. If worse > comes > to worse maybe I could try to code up an equivalent SceniX test program to > see if it has the same problem, but I really hope to not have to go > there... > > Thanks, > > John > > > On Tue, 19 Oct 2010, Martins Innus wrote: > > John, >> >> Can't help much except to say I saw the same thing. I had access >> to a system when the GTX 470 cards came out that had 2 cards and 4 >> displays hooked up. We could never get one instance of our software >> spanned across the 4 displays to run as fast as 4 separate instances. >> Tried twinview, xinerama, separate x-screens. I don't have access to >> the system anymore, but at the time I chalked it up to bad drivers since >> the cards had just come out. I can't remember if the frame drop was as >> dramatic, but it was certainly there. >> >> Martins >> >> On 10/19/10 3:11 PM, 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? >>> >>> 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 > -- Ralf Stokholm Director R&D Email: a...@arenalogic.com Phone: +45 28 30 83 52 Web: www.arenalogic.com This transmission and any accompanying documents are intended only for confidential use of the designated recipient(s) identified above. This message contains proprietary information belonging to Arenalogic Aps. If you have received this message by error, please notify the sender.
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
