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
_______________________________________________
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
