Comments within. -------- Original Message -------- Subject: Re: [Flightgear-devel] Statistics overlay accuracy. From: Csaba Halász <[EMAIL PROTECTED]> To: FlightGear developers discussions <flightgear-devel@lists.sourceforge.net> Date: 05/11/08 06:11 PM
> 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. >> 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). >> 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). > > 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. Regards, Matthew ------------------------------------------------------------------------- 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
