Re: Performer loading Getting Stats

New Message Reply Date view Thread view Subject view Author view

david pratt (pratt++at++medusa.cs.nps.navy.mil)
Sat, 7 Jan 1995 17:02:09 -0800


Sharon's suggestion works as far as it goes, I can get they "standard graph" and
no warnings. However, when I try to get the polygon counts, pfQueryStats
returns 0 polygons made it past the cull. Trying everything, I ended up with
the polygon counts and Performer warnings that there were multiple pfStats
open. Basicly I am back to where I was before the post. Should I worry about
the warnings and trust the stats? The stats are going to be used for DB
evaluations, so they are very important.

On Jan 6, 4:16pm, Carl Christofferson wrote:
> Subject: Re: Performer loading Getting Stats
>
> I also wish to get polygon information on more than one channel. I
> would also like an aggregate report, but the multiple channel report
> is a good start. I tried Sharon's suggestion and got an annoying
> warning:
>
> Performer Warning (2): pfOpenStats(pfStats*) for 0x19204610 ignored
> Already have a different opened pfStats=0x191f9750 mask=0x1.
>
> Running with pfMultiprocess(1), I determined that performer 1.2 calls
> prOpenStats() from within pfSync() for each channel. As per the
> documentation the second and subsequent calls fail and print the error
> above. So, can I rely on the statistics gathered? Do I have any
> choice but to run with PFNFYLEVEL less than 2?
>
> Carl Christofferson
>
> >>>>> "src" == Fischler <Sharon> writes:
>
> src> +>---- On Jan 3, 9:35am, david pratt wrote:
> >> Subject: Re: Performer loading Getting Stats
> -> Happy New Year! May your code be bug free and your boss on
> -> travel.
> ->
> ->
> -> In the 1.2 manual it metions that some stats can only be
> -> gathered on a single channel per pipe. I have two (possibly
> -> more) channels in a pipe that I need to get the polygon and
> -> point count on. Is this possible?
>
> src> A pfFrameStats structure keeps the statistics for a single
> src> channel. You can collect statistics for each channel of a
> src> pipe by getting the pfFrameStats structure for each channel
> src> with pfGetChanFStats() and enabling the desired modes on each
> src> pfFrameStats structure.
>
>
> -> On a single channel / pipe configuration, I get a poly count
> -> that is too consistent for the visable geometry. Is the number
> -> of triangles the stats report based upon the actual number
> -> rendered or the number that makes it pass the cull process
> -> (gset based)?
>
> src> The latter - the number of triangles that made it past our
> src> cull.
>
> src> src.
>
>
> src> -- -----{-----{---++at++ -----{----{---++at++ -----{----{---++at++
> src> -----{----{---++at++ Sharon Rose Clay (Fischler) - Silicon
> src> Graphics, Advanced Graphics Dev. src++at++sgi.com (415) 390 -
> src> 1002 FAX: (415) 965 - 2658 MS 8U-590 -----{-----{---++at++
> src> -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
>
>
>
>
>-- End of excerpt from Carl Christofferson

-- 

Dave Pratt pratt++at++cs.nps.navy.mil (408) 656-2865 fax (408) 656-2814 Department of Computer Science, Naval Postgraduate School, Monterey, CA 93943 These are my opinions, talk to the PAO for the Navy's.


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:50 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.