<div dir="ltr">Hi Jannik,<br><br><br><div class="gmail_extra"><div class="gmail_quote">On 15 April 2015 at 11:55, Jannik Heller <span dir="ltr"><<a href="mailto:scrawl@baseoftrash.de" target="_blank">scrawl@baseoftrash.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for the hints - I am using a release build, and I already disabled double precision from cmake which gave me another nice boost.<br></blockquote><div><br></div><div>I am surprised you saw a boost with disable double precision.  What specific element you do you change w.r.t double precision?<br><br></div><div>For the change to double precision making a difference it's a hint that you have a scene that is poorly balanced.  <br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the stats handler I am seeing roughly the same amount of time spent in the cull, draw and GPU threads. After adding the double buffering the 3 threads all run in parallel so performance is decent now.<br>
I know that my app is CPU bound but there's not much I can do about it.<br>
Some of the time in the cull thread is spent updating vertex animations, and some time for organizing light lists. I have scenes with a lot more than 8 lights, so I have to check what lights are closest to a given sub-graph before rendering it. This system was really slow to begin with but I already optimized it a lot. Non the less setting the lights still has a noticable overhead.<br>
Next problem is the sheer number of objects - often thousands per scene. I tried batching before but the problem is the scenes I am working with are scripted, so objects can be moved or removed at any time, also, batching objects would interfere with the light lists - i.e. with too many objects sharing a large batch I can not set fine grained light lists on them.<br>
I'm looking forward to switching the light system to deferred shading in the future - I'm sure then it will be GPU bound. I still need a forward rendering fallback in place though.<br></blockquote><div><br></div><div>Thousands of objects per frame is not unusually for a scene graph application and should work fine rendering at 60hz on modern hardware.  If you are hitting CPU limits prematurely then it's another hint that the scene graph is poorly balanced.<br><br></div><div>There are lots of different things you can do to create a more efficient scene graph, exactly what to advice is hard to do without knowing more specifics about the application and types of data being handling.  Batching might be one thing to try, but only if it's established as the main bottleneck.  From what you've written I wonder if the animation element to your scene is what is slowing things down.   Are you using CPU based animation?  Could you shift it onto the GPU? <br><br></div><div>Robert.<br></div><div> </div></div></div></div>