Re: [Plib-devel] Work outstanding.

[Steve B. <sjb...@ai...>]

Gil Carter wrote:
> 
> At 09:25 AM 8/10/00 +0100, you wrote:
> >Gil wrote:
> >
> > >puTrace
> >
> >Sounds great! Obviously, the more info on bottlenecks there is, the
> >better. For example, it would be GREAT to know how much
> >texture-swapping there is going on, but I doubt this can be done
> >portably?
> 
> Over to Steve for this one, but I suspect that with a little user
> assistance (eg. "How much texture memory does your board have"), we can
> probably have a stab at guessing how much texture swapping from main memory
> to texture memory is occurring.

Well, there isn't a direct way to do either of those things.

You can ask OpenGL if a texture is resident though - so you could
start loading 1k x 1k textures and asking each one whether it's
resident or not - and when they stop being resident - you have a
*reasonable* idea of how much memory there is.  However, real hardware
can be VERY subtle - and the question may not actually be answerable.

 * On SGI ONYX machines, there are two BANKS of texture. When a map
   loads, the odd numbered MIPmaps go in one bank and the even numbered
   into the other.  It's possible to run out of texture memory in one bank
   and still have plenty in the other - so although *theoretically* you have
   free texture memory, your map won't be resident on the hardware.

 * 3D hardware may have on-chip texture cache, on-board texture RAM, AGP
   texture RAM and main memory texture RAM.  These represent a continuum
   of performance.  When you ask "how much memory is there" - you really
   need to ask "how much memory is there that can be accessed at better
   than 150 nanoseconds"... Some Intel i810 boards have NO TEXTURE MEMORY
   AT ALL...getting it all from AGP and using a tiny texture cache.  How
   many bytes should they return as texture memory size?

 * Some cards (GeForce, Voodoo-5 and S3 for example) have texture compression.
   Since you don't know in advance how much your map will compress, there is
   no way to answer the question "how many texels will my card hold?"

Since this question is unanswerable in a portable manner, OpenGL doesn't
attempt to answer it.

As for swapping, what I've done in the past is to check the glAreTexturesResident()
function to find out what textures are resident from frame to frame - if the
answer ever changes then you are swapping textures...but if it doesn't change,
that doesn't tell you that it *didn't* swap because something may have
swapped out and then swapped back in again a dozen times during the frame!

So, these are NOT good questions to ask!

> Anybody know if you can monitor AGP transactions to pick this kind of thing
> up?

Nope - and in any case, that wouldn't be portable because not all cards
use AGP - and lots of things other than textures go across the AGP.
 

> > >puFly
> >
> >Why not use PPE? It has several windows, a hierarchial view, great
> >viewing via mouse or keyboard or commands (for example, "view
> >everything"). It allows you to edit the model while seeing the
> >performance. Of course PPE can load all plib stuff, since it is build
> >on plib.

I agree. PPE has everything you could possibly need in a viewer.
 
> Well, the attraction with perfly is that it really doesn't do anything
> apart from load and display models.

Neither does PPE right now!   :-(

But seriously - if you are not actually in the process of editing a model,
all PPE does is to call ssgCullAndDraw in a tight loop on your model.  It's
perfect as a perfly equivelent for PPE.

>  Perfly's ability to change the rendering parameters is very nice...

PPE can do that.  Turn on and off lighting, shading, texture, wireframe, etc.

> and keeping it as a simple but powerful
> program means that the source stays compact - compact enough to go with the
> standard examples tarball for PLIB.

Well, I don't think it would be all that much of a stretch to assume that
since PPE is free, it'll become as ubiquitous as (say) GIMP - so everyone
who uses PLIB will already have it.  If that's the case, why bother with
another tool?  It's just a waste of disk space.

Having said that, you could write such a thing very easily and dump it
into PLIB-examples if you wanted to.  I don't feel a strong need to do
that.

> The real win with this is that people can build puFly and load up models
> very easily.  The code will be compact enough that people can see how to
> not only use the loaders, but also exercise all of the rendering
> methods.

That's why we have example programs - certainly.

However, Perfly is a mess because it's had anything and everything
slurped into it.  A bunch of simple single-function examples is
generally more instructive IMHO.

If you really want an example of how to put something together using
all the tools, just download TuxKart - it's only 4,000 lines of code.

>  Hopefully, puFly will have enough in it that people can use it as
> a basis for their own first tinkerings - I know I'm still using the
> original tux-on-a-box program as my starting point for experiments!

Yep.

Michael Jones (one time manager of the Performer project) told me that
he quite regretted making Perfly *so* complete because everyone just
hacked Perfly instead of writing appropriate programs from scratch.
You'd be amazed at the number of commercial Performer applications that
are just Perfly with a few hundred lines of code added.
 
> >We could create a new window for puTrace output.
> 
> I hadn't thought of puTrace being used inside PPE.  Given that PPE is a
> modelling package not a gaming engine, is this something you would really
> need to do?  Obviously it's possible, but I'm not really clear on what you
> would use it for; I'm open to comments on this.

Well, I'm not sure 'puTrace' is the right name here. 'ssgStatistics'
might be a better thing to imagine.  Having good rendering statistics
would be a VERY good thing for PPE.
 
>  >[autmatical docs]
> 
> >I am not against them. But I think we need a handcrafted doc for the
> >users of plib as well. For example, you have to give an overview of
> >plib.This fits nowhere in the code.

Yes, I agree.

> Very true.  I guess you can draw the distinction between a programmer's
> guide and an API reference - the API reference is automagically updated
> from source comments, while the programmer's guide is a more static
> document which gets updated when major new features get added.  I'm a big
> fan of nice docs, and I'm more than happy to put the effort into them
> provided other people can point out my errors :-)

Yes.

I dislike documentation embedded in code files because it makes the code
VERY hard to read...it's hard to see the three lines of code for the 30
lines of documentation.  Also, good documentation contains examples - and
I *really* hate having code buried inside comments inside *real* code
because it makes it virtually impossible to 'grep' code and search for
things without tripping over the stoopid examples.

Finally, the order of items in (say) a header file is the order that
makes sense when programming - that's rarely the order that makes for
a readable document.

And all of this is for what?  To avoid having two files?

I'm not very convinced.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net