Re: [Plib-devel] Work outstanding.

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Wolfram Kuss" <w_...@rz...>
To: <pli...@li...>
Sent: Friday, August 11, 2000 2:55 PM
Subject: Re: [Plib-devel] Work outstanding.


> Steve wrote:
>
> >> >For example, it would be GREAT to know how much
> >> >texture-swapping there is going on, but I doubt this can be done
> >> >portably?
> >>
>
> >However, real hardware can be VERY subtle
>
> Yes, I know. Generally speaking, I loved optimizing till about 10
> years ago. Until then, you could pretty much tell beforehand whether a
> change would speed up the program. But with several caches, pipelines
> that are filled by compilers, branch prediction etc it has become much
> harder and sometimes when I optimized something for speed I ended
> up making it slower :-(.
>
> >Since this question is unanswerable in a portable manner,
>
> That's what I feared.
>
> >So, these are NOT good questions to ask!
>
> Ok, I realize that there is no portable way to measure things, no one
> answer (after all, not all users have the same
> hardware), its not clearly defined etc.
> But I still think a ballpark figure could help enormously. I think
> it can still happen that large parts of the time per frame is spent in
> texture swapping.

Here's an idea.  You could still take a stab at the amount of texture memory _consumed_ even if not the amount _available_.  It's
still not all the simple since you'd need to know which mipmap levels are in use - I'm not sure you can do that.

But what would be useful would be a list of all the textures currently in use by the ssg scenegraph (even if they are culled/never
textured with), and by clicking on them you could replace that texture with the dummy red/white check pattern.

If you notice a sudden increase in frame rate then you know that on this particular hardware, with this scene-graph, looking in that
direction from that viewpoint that texture swapping is happening.. Heh, not get I suspose but it would be a useful UI.
  "Hey, this model is rendering really slowly let's try turning that texture off".

You could write a function that could monitor the frame rate and automatically try replacing texturing to look for swapping but I
think that's about as far as you can go.

Would it be practical to have some kind of playback/record mechanism in ssg or is that too much work, or too much of an impact in
performance?

Anyone know of any opengl texture management articles that cover scaling back the textures in use automatically?

Sam