On Wednesday, July 2, 2003, at 01:00 PM, [EMAIL PROTECTED] wrote:


Message: 3
Date: 2 Jul 2003 16:30:37 GMT
From: Martin Spott <[EMAIL PROTECTED]>
Subject: Re: [Flightgear-devel] Again: Threaded FlightGear ?
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>

"Curtis L. Olson" <[EMAIL PROTECTED]> wrote:

Just my two cents...


OpenGL can be multi-threaded on some implementations. Apple, (who by no coincidence sells lots of MP machines), has the GL_APPLE_FENCE extension for inserting synchronization primitives into the OpenGL pipeline. Of course, one has to use these carefully (avoid stalling the pipeline) to see the benefits, but there are real benefits and I've seen the proof.

BUT (and this a big but), as far as FlightGear is concerned, you'd be *much* better off focusing your energy on optimizing for single processor case first. There is *tons* of room for improvement in the rendering of static geometry. The current system is extremely inefficient, and this will only get worse as the performance gap between CPU's and GPU's continues to grow.

To rehash what I've shown before, the average number of triangles per node in the current scene graph is about 5. When you add up the state changes, culling, and other overhead, (keeping in mind that drivers/cards tend to perform best with large pieces of data and few state changes), you begin to get an idea about how inefficient the geometry rendering is. Another example: I get about 50 fps with geometry enabled, and 100fps with it disabled (comment out draw_geometry() in ssgVtxTable to see what I mean). You'd think it would be much more than that, but the culling operations keep it from going any higher - and this is on a 1Ghz CPU. In short, rendering is CPU-bound, not GPU-bound.

To fix this, we need more triangles per scene graph node, and probably should sort our nodes (by state) to get even fewer state changes. That this may require completely redoing the scenery subsystem, I will ignore ;-)

I don't really know how to go about fixing these things, I'm just reporting on what I think needs work - not that this needs to be done now, of course (optimization comes last in my book). I just anticipate it becoming more of a headache in the future when we try to increase scene complexity. Of course, it will need to be fixed to be able to compare visually with GPU-optimized sims.


_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to