Performance can be affected by being load/store bound and/or floating point bound. Tools like VTune are really helpful in determining "hot spots" in the code for stuff running on the CPU. I don't know if they have something similar for GPUs or not.
In a former life, I wrote OpenGL driver code. We always optimized the heck out of vertex arrays and left the Begin/End construct (the slow path) pretty much alone. They both go through two totally different code paths. glBegin() usually invoked a huge check and re-munge of the OpenGL state engine. Lots of state changes with small primitives is not good for performance. The more you can minimize the change of state in the driver, the better. With the advent of the new GPUs with all their capabilities, I'm sure the drivers have undergone lots of changes so I don't know if this is still true. -Shayne -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Martz Sent: Monday, March 30, 2009 12:59 PM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] OpenGL 3.1 at GDC If the tool starts to act sluggish when rendering complex models, then moving away from glBegin/glEnd to buffer objects would improve performance. It would be unfortunate if someone were to use a poorly-written OpenGL or OSG application and blame the poor performance on OpenGL and mistakenly think that things would be better if the app had been written in D3D. Uneducated programmers can code poorly performing apps using either API. SketchUp really excels at very simple models on the order of a few hundred triangles or less, so I suspect the performance bottleneck they have designed into their application is probably not an issue for 99% of its target audience and usage cases. Nonetheless, there's no excuse why the app wasn't coded to at least use vertex arrays from the start, as they've been commonly available since the early days of consumer 3D hardware, '96-'97. As an aside, I understand @ Last Software (now the Google SketchUp division) was started by a former AutoCAD employee. (A note about performance tuning... I recall tinkering with the terrain rendering code at my former employer, which used glBegin/glEnd to render the terrain triangles. As a test to see how much of a performance hit this might be causing, I commented out the rendering code altogether, recompiled, and benchmarked it. I only saw about a 10% improvement. Obviously the application's bottlenecks were elsewhere, and spending time converting this to use buffer objects wouldn't help. Perhaps Google has done the same analysis with SketchUp and came to the same conclusion.) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of R Fritz Sent: Sunday, March 29, 2009 11:03 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenGL 3.1 at GDC > I guess I'm not too surprised. There seems to be an overall lack of > expertise in 3D graphics. Lots of people practice it without adequate > training or education. Ever look at a GL capture of SketchUp? It's > utter crap, glBegin/glEnd all the way. Would fixing the OpenGL problems of SketchUp improve its performance as a modeling tool? That's its great strength, after all. How would you make it work, if you were designing it? _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
