Re: GLX in bad state

lør, 03.04.2004 kl. 22.17 skrev Gavriel State:
>   (a) Why are we destroying pbuffers for textures that we've rendered to
>      in the past and then recreating them?

Off the top of my head, there are four known situations where we destroy
a pbuffer.

1) when the owning texture is destroyed (by the app).
2) when the context is destroyed.
3) when the pbuffer cache runs out of free entries, so that an entry
must be destroyed to make room for the new one. (Though 8 textures
shouldn't exceed the current CACHESIZE of 64)
4) when a pbuffer allocation fails (because the VRAM is full or perhaps
too fragmented), so that another cached pbuffer must be destroyed to
free up some VRAM for the new one. (But if this happens, there's a
preference to find an existing pbuffer of the desired size and evict its
existing owner, to avoid destroying and recreating pbuffers
unnecessarily.)

And of course, then there would be the bugs, where we might be
destroying them when we shouldn't...

In any case, you will see copy_aux operations whenever a pbuffer owner
is evicted, whether it's for destruction of the pbuffer or for its use
by another owner (texture), so don't worry too much about those. And
also, pbuffers, being render targets incarnated, are the whole purpose
of the "render target" reuse scheme you're referring to.