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:50, 21 February 2014

2,671 bytes added ,  21 February 2014
m
→‎Interpreting the OSG on screen stats: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35917.html
(→‎Interpreting the OSG on screen stats: http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2009-November/034777.html)
m (→‎Interpreting the OSG on screen stats: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35917.html)
Line 80: Line 80:
A simple help is to switch on the onscreen stats in the viewer or flightgear  and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu.
A simple help is to switch on the onscreen stats in the viewer or flightgear  and see if the yellow bar is longer than the orange one. A yellow bar longer than the orange one means that the cpu is not able to saturate the gpu.
Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease!
Again, beware this does in no way mean that you should write complicated shaders to saturate the gpu! This rather means that the geometry setup/state change time - the yellow one - must decrease!
Once your orange bar is longer than the yellow one, you can start to care for the shaders and their execution. When thinking about shaders, keep in mind that different GPU's perform very different on the same shader.
How to achieve that is a very long chain of right decisions. Starting with the
modeler:
Avoid having leaf geometry with very small parts. Collapse as much triangles
as sensible for culling into the same leaf geometry. Sure if geometry needs a
different texture or anything that requires a different OpenGL state you cannot
collapse this into the same leaf. May be it makes sense then to collapse the
textures into a common one. Then you might be able to collapse more geometry.
Avoid animations that are not really required. If you need a transform node in
between some geometry, the geometry below the transform needs to be drawn
seperate which takes time on the cpu. Everything that needs geometry to be
drawn seperately should be avoided to that level where it stops to make sense
because of culling.
May be introduce some level of detail. Not just avoid the whole model in some
distance, but also provide a static model without animations, simple geometry
for the mid range. May be provide some more culling friendly and detaild with
the animations you need for the short range.
Keep in mind that culling a model that you are close to should make you split
the model into more parts that could possibly be culled away. But for culling
a far away model is probably very sufficient to cull it either as a whole or
not.
Avoid state changes. Use as much common state as possible. Osg does a good job
in sorting together draws using the same state, but if the overall scene
contains plenty of different state osg cannot change that.
A new texture is a new state for example. A new shader is a new state. ....


Once your orange bar is longer than the yellow one, you can start to care for  
Once your orange bar is longer than the yellow one, you can start to care for  
the shaders and their execution. When thinking about shaders, keep in mind that different GPU's perform very  
the shaders and their execution.
When thinking about shaders, keep in mind that different GPU's perform very  
different on the same shader.
different on the same shader.


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.
Appart from OpenGL we spend a lot of time in scenegraph traversal. This is  
mostly due to plenty of structural and often needless nodes in the scenegraph.
The reason or this is that historically the xml files did some implicit
grouping for *every* animation in the xml file. To make that reilably work I
had to introduce a huge amount of group nodes in the xml file loader. These
really hurt today as they introduce a whole lot of group nodes that just have
a single child which need to be traversed for update and for cull. Profiling
shows that Group::traverse is the most used function in flightgear.
The lowest hanging fruit could be to optimize away the redundant nodes from
the top level model that gets loaded by a database pager request. We cannot do
that recursively once a model part is loaded since the mentioned grouping
nodes might be referenced in any level in the model hierarchy above the
currently loaded model. So only the top level model could do this without
braking tons of models.


At the highest level:
At the highest level:
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/68091"

Navigation menu