On 01/26/2012 01:02 PM, Tim Moore wrote:
That is what I found at the time of that thread, testing with some models supplied by NIST. Newer hardware is highly optimized for massive geometry. For the record, I don't think the problem is bus contention, but lock contention in the NVidia driver. The amount of bus traffic involved in the OpenGL command stream is tiny.
Thanks for that. A couple of people have mentioned bringing this to NVidia's attention. We'll probably end up doing that.
The key to OpenGL performance in the 21st century is reducing the number of OpenGL function calls to a minimum... so says Captain Obvious. I'm glad the mesh optimizers turned out to be useful!
Yeah, once you get down to the data itself, it ends up being pretty obvious (5,500 draw calls runs slower than 9 draw calls? Really? :-) ).
There was a bit of digging to do before we got to that point, though. At the outset, we originally thought that an OpenGL program wasn't showing the same problem that an OSG program was, which pointed the blame at OSG. Turns out that we weren't doing an apples-to-apples comparison with the data sets. It wasn't until we could get precisely the same set of data into the OpenGL program that we could start looking at the data itself as the culprit.
Definitely a big thanks for the mesh optimizers. I was all set to start writing something myself, but then I realized they were already there :-)
Btw, the Linux tool "oprofile" is mentioned later in the thread, but I find the newer tool "perf" to be more useful.
Thanks, I'll check that out. --"J" _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
