Profile information

[DavidYazel]

I just profiled the current rev of the xith3d engine running on top of logl.

It has some interesting results.  The breakdown is somthing like this:

14% in glDrawArray
5.4% in state sorting
5.86% in frustum culling
19% in transforming bounds after transform group is updated.
10% doing a commodification check on list iterator (looks like I will have to roll my own)
7% setting opengl state
3% in WindowsGLContext.makeCurrent
3% in swapBuffer

Rest is about 30 percent spread pretty evenly.

Here is the actual profile:

http://www.magicosm.net/xith3d/profile/data2.html

[gregorypierce]

While interesting, it would be more interesting if we had some idea of what it was doing at the time. How much were you drawing (poly wise). My last profile graph had my application spending over 35% of its time drawing. One thing I definitely don't have is lots of frame by frame bounds computations. I have fairly large box primitives that expand out in a direction based on an objects velocity so I can get cheap trivial rejects every frame and don't have to do anything expensive until I know they have hit something. These bounding primitives are sufficiently large such that I don't have to transform them after I animate objects.

Made my life easier and speed me up a good bit. As I read through your detailed profile, it looks like in your Java code you're doing a lot of things to minimize the load to the GPU - I went the opposite route and simply passed the load off to the GPU because from what I could tell, teh cards have just gotten so fast and the drivers are smart enough that I was wasting a lot of time doing stuff that the nvidia driver was doing anyways. Don't know if you have a copy of VTune of IPEAK, but I'm sure you'll find a profile at that level will reveal some interesting bits as well (on Windows anyways).

[DavidYazel]

Yes its no more than "interesting" at this point.  I am not pushing the card at all yet.  In fact as a test I doubled the number of triangles in the test object and the frame rate only dropped 1 percent.

Very shortly (as soon as I finish porting my ASE loader) I will be able to do more complex tests and see how things go.

It is true we are doing a lot of work to save the GPU and that is because a typical magicosm scene has a lot of objects surrounding the avatar and we need to effecively cull them.  As for state sorting, well, thats one of the strengths of a scenegraph renderer... that you can render in an order that is optimal for the card but makes no sense logically.

Games published by our own members! Check 'em out!

[josgood]

I just profiled the current rev of the xith3d engine running on top of logl.

It has some interesting results.  The breakdown is somthing like this:

...

3% in WindowsGLContext.makeCurrent

...

Thanks for posting your findings.  It's good to keep an eye on this stuff.

Is your code using the Animator class?  

The makeCurrent stat is curious.  I'm not claiming I'm an expert on JOGL (nee Jungle), but I thought it invoked makeCurrent just once for each thread switch.  That would mean once when an Animator is started than once again when it's stopped (e.g. makeCurrent( NULL, NULL ) ).

I know, I should just look at your code.  My excuse is I'm prepping my house to be painted.