Matthew Tippett wrote: > Comments within. > > -------- Original Message -------- > Subject: Re: [Flightgear-devel] Statistics overlay accuracy. > From: Csaba Halász <[EMAIL PROTECTED]> ... >> On Wed, Nov 5, 2008 at 11:26 PM, Matthew Tippett <[EMAIL PROTECTED]> wrote: >>> My two issues are >>> 1) It appears as if environment loading is added to 'draw' statistic. >> Scenery loading is done in the pager thread, don't think that is >> counted into the draw time. > > It seems be. When there are the stalls when moving to a new area or > seeing new parts of the scenery it appears to be attached to the draw. > > My rationale for this is that in the 'serialized' draw mode the start > time for each raw appears to be concurrent 10 milliseconds after each > other. The other couple of hundred of milliseconds for each camera seem > to run in parallel. > > When no stalling is occurring, the draws are correctly serialized. A portion of scenery loading is done within the draw threads: textures are bound and otherwise initialized (e.g., mipmaps are generated in hardware), shader programs are compiled and linked, and display lists are created. These operations require a valid OpenGL context, which the database pager doesn't have. There is some experimental code in the pager to share OpenGL contexts with the draw threads, but this is rarely used in practice.
There is code in the pager to "stream" these objects to the draw threads so that the impact of this compilation is minimized in any given frame. Several environment variables defined in OpenSceneGraph/src/osgDB/DatabasePager.cpp tune this process: OSG_DO_PRE_COMPILE, OSG_MINIMUM_COMPILE_TIME_PER_FRAME, OSG_MAXIMUM_OBJECTS_TO_COMPILE_PER_FRAME. Also, OSG_DATABASE_PAGER_DRAWABLE controls whether geometry is compiled into display lists or not. I have heard that display lists are not an advantage on ATI hardware; you could try setting that variable to "VertexArrays" and see if there is much difference in the stalls. Is it possible that the compilation operations, such as texture binding, are serialized in your OpenGL driver? > > >>> 2) There are blank periods in the graph that doesn't get attributed >>> to event, update, cull or draw.. >> Could be the time spent during synchronization, for example. I am not sure. > > Okay. > >>> For 1), I am dreading the comment that the measure is from >>> flightgear's call into, and return from osg. Meaning that it is the >>> 'osg' draw that does some black voodoo that both a driver and >>> flightgear have no control over. >> Sorry :) It is in fact OSG internal statistics. Everything fg does >> counts into the event time I think. We don't really call into OSG, >> rather, OSG calls into FG! (apart from our auxiliary threads) > > Is there an "uber-level" of statistics that provides lots of extra > details (like triangles, lots of other metrics, etc, etc). There is, with current OSG and FlightGear. As you cycle through the statistics you now have modes with detailed geometry information. > >>> Some of you may be aware that I am tuning for multiple asics. What I >>> am seeing is there seems to be consistent render times of 6-10 ms per >>> card for the flight data I am replaying. The fg cull operation is >>> nicely parallelized (although I need to confirm timings), but the >>> draws, although parallelized, seem to take an O(n) time to complete >>> (meaning 4 GPUs results in 40 ms for each of the draws that take 10 ms >>> if done serially). Is that when paging scenery, or the steady-state condition? >> We should carefully examine whether that is a result of the osg stats >> not being thread safe. It is a known fact that the *display* isn't, I >> don't know the status of the actual collection. > > I do not believe that this is related to the stats display. The > performance I am experiencing is consistent. There are a few things > that I can try to see if there is a driver issue, but realistically it > is a bit opaque without instrumenting osg. > I'll take a look at the compilation code in the pager and see if these operations are being serialized somehow. > Regards, > > Matthew Tim ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
