Hi John, On Thu, Oct 21, 2010 at 5:35 PM, John Kelso <[email protected]> wrote: > At this point I've run out of OSG things to try, but am open to suggestions. > At this point I'm assuming it's either an Nvidia driver bug or an OSG bug. > (Latest Nvidia driver, OSG 2.8.3)
>From the sound of the setup of hardware and software you have you should get the scaling that one expect from one such set up. Clearly the hardware is capable of doing it - running the separate apps shows this. This does leave the OSG or the NVidia driver. The OSG has scaled just fine in the past on other multi-graphics card systems, and the design and implementation should lead to good scaling. Personally I'd suspect the NVidia driver is the problem, but we can't rule out the OSG have some bottleneck that we've introduced inadvertently. One way to investigate whether the OSG being a problem would be to run the OSG against a dummy graphics contexts that just eats all the OpenGL calls. Is it possible to use Mesa in this way? Or perhaps just write a non GL library that implements all the function entry points but then does a non op or just logs the timings. Another route to take is to drop in some ATI cards and see how things scale. Others on this thread have indicated they have seen better scaling with ATI cards. Doing benchmarks of ATI vs NVidia showing that the NVidia drivers suck really badly for mult-context, multi-threaded apps should get their attention. Another approach might be to look to NVidia for an OpenGL example that claims to scale well, then go test it. Perhaps a tool like Equalizer has multi-threaded, multi-context support that could serve as testbed. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
