Hi Tugkan, On Wed, Aug 18, 2010 at 10:39 AM, Tugkan Calapoglu <tug...@vires.com> wrote: > Actually, draw always required more time than cull. If you look OSG > examples, draw usually takes more time than cull. Now that draw reaches > 16 ms border, this started to hurt us.
It is typical for cull to be shorted than draw dispatch, which ever traversal is breaking frame will be the one you need to address. Thinking that you can thread draw dispatch to make it faster is not going to help though as it will do more harm than good as it's the actually just dispatching data to the OpenGL fifo, filling it from two threads will just cause lots of issues in OpenGL driver that has to manage two contexts and card as well as CPU cache coherency. I must add that draw dispatch is a little complex to profile though as it depends upon the being able to fill the OpenGL fifo, and if the fifo fills up it'll block the draw dispatch. This effect can lead to the draw dispatch looking like it's breaking frame but it's actually the OpenGL driver/graphics card that is the bottleneck. > My actual observation is that, both cull and draw require more CPU time > with larger scenes, but since draw is generally more performance hungry, > it becomes bottleneck earlier. This is something one would expect, ideally you'd have LOD'ing to keep the large scenes well balanced - for instance it's possible to LOD the whole earth and use paging and still get 60Hz, so while you might have Terrabytes of data the app only has what it memory what it needs with the complexity kept relatively even throughout the database. High fidelity town database will of course push things more than usual terrain paging app, but the same principles can apply, although one might need to get more creative with the LOD generation and management. For yourselves LOD'ing may not be an appropriate solution, or even required. I believe the key question you need to ask is why draw dispatch is getting so expensive. Is it the OpenGL fifo blocking? Is it that you have too much separate state? Too many transforms? Too many separate drawables? Solutions will vary depending upon what is the bottleneck so it's important to work to pinpoint it. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
