20,741
edits
Howto:Use the system monitor: Difference between revisions
Jump to navigation
Jump to search
Howto:Use the system monitor (view source)
Revision as of 20:48, 21 February 2014
, 21 February 2014→Interpreting the OSG on screen stats: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2009-November/034777.html
m (→Profiling) |
(→Interpreting the OSG on screen stats: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2009-November/034777.html) |
||
| Line 86: | Line 86: | ||
And regarding all that, even if your box already is gpu bound this does not mean that other driver/hardware combinations are gpu bound too. Always: As much as needed and as few as possible. | And regarding all that, even if your box already is gpu bound this does not mean that other driver/hardware combinations are gpu bound too. Always: As much as needed and as few as possible. | ||
At the highest level: | |||
* Update: cpu processing your application is performing | |||
* Cull: cpu processing performed by osg in traversing the scene graph and packaging drawing state | |||
* Draw: cpu processing for sending drawing state to gpu and gpu processing | |||
of the drawing state | |||
If Update stage is large, you need to determine what part of your application is taking the time and optimize it. | |||
If Cull stage is large the scene hierarchy is too complex and needs to be optimized - spatial optimization, flatten static hierarchies, ... | |||
If Draw stage is large then you need to determine if you are vertex or pixel limited. If you grab the window corner and shrink/expand it's size | |||
and the performance increases/decreases significantly, then you are pixel/fill limited (too much depth complexity/too much pixel processing). | |||
If the performance doesn't change then you are probably vertex/transform limited (too many verts/too much vertex processing). | |||
It's actually much more complex than this, but it's how you can start diagnosing performance issues. | |||
Run your scene in osgViewer to see how fast it renders. You might have to build the scene in your regular app and then save the scene root to an .ive | |||
file, which you can load into osgViewer. | |||
A really good tool to use is an OpenGL command logger. It logs all the actual OpenGL commands that OSG is issuing and can help identify problem areas. | |||
== References == | == References == | ||