So I updated to current CVS, and now the behaviour is different. If a camera is looking at the sky, both cull and draw are short.
So I assume something was fixed somewhere which is great. Now I need to work out how to stop running out of memory :(... It looks like 64bits is the only way.. As an aside, the xml loader seems to be sub-optimal - loading the same file multiple times (for each camera?). Are there any hints on that behaviour? Regards... Matthew On 11/6/08, Tim Moore <[EMAIL PROTECTED]> wrote: > 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 > -- Sent from my mobile device ------------------------------------------------------------------------- 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
