Hi Sergey,
I've used gDEBugger tool for rendering optimizations, it have modes that turn off some features of rendering so you can determine what impacts framerate most (like it have modes which turns off all lights(fixed pipeline vertex lighting impact), replaces all textures with 2x2 textures(memory bandwith\texture cache impact), turn off all draw calls, turn off vertex\fragment shaders, turn off rasterization (fillrate speed impact), etc). This way you can get some broad vision on what's your main problem. If you have something similar in your tool - give it a shot.
I've been using gDEBugger for a long time. It has helped find a few things, but recently it can't use the NVidia hardware counters in 256+ version drivers, so we only have access to some basic functionality.
Still, it was gDEBugger that first tipped me off to the poor batching of geometry that we were doing - its "Vertex Batches" tab in the analysis window is useful, it groups batches in a given number of vertices and then tells you which percentage of batches send that number of vertices, for example "you send 10% of your vertices with 68% of your batches".
It also shows the number of given OpenGL calls, which also showed me that our skydome was sending a large number of small triangle strips which is also inefficient.
So yes, I agree it's a good tool, but I really wish they would fix the problem with hardware counters in recent NVidia drivers (whether the problem is in the drivers or gDEBugger) so we could again use all this tool's capabilities.
J-S -- ______________________________________________________ Jean-Sebastien Guay [email protected] http://www.cm-labs.com/ http://whitestar02.webhop.org/ _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
