Re: GLX in bad state

man, 05.04.2004 kl. 10.36 skrev Nadav Frum:
>   Issue 11 of the ARB_render_texture spec is as follows:
> 
>   11. When the color buffer is released from the texture (back to the 
>       pbuffer) should the contents be preserved?
>  
>       No, this may prove difficult to implement on some architectures.
> 
> The color buffer remains intact upon release.  So why is the answer no?
> There could be two reasons:
> a.  The contents of the color buffer were copied to the texture memory, 
>     and thus negating the usefulness of this extension.
> b.  The depth/stencil buffer was used for something else in the interim, 
>     i.e the depth/stencil buffer is shared.

Or perhaps

c. Textures need to be in a different format than render targets, so
that BindTexImage needs to convert the image to a different format. Some
hardware (perhaps the Xbox, according to some discussions I've seen) may
use a tiled texture format. Some hardware (perhaps the S3 Savage,
according to other discussions I've seen) may use a tiled render target
format. In some such cases there may be a HW-accelerated way to convert
the rendered image to a texture (and then the original image is
destroyed after the conversion to avoid wasting VRAM), but not an
efficient way back again.

I don't think "b" is a possible interpretation, because if it was, the
spec would have mentioned that the depth/stencil buffer became undefined
too. It does not. It says "Also, the contents of the depth, stencil and
accumulation buffers are not affected by wglBindTexImageARB and
wglReleaseTexImageARB."

It does say that the depth/stencil buffer gets undefined if you render
to a different image in the pbuffer, though, such as a different mipmap
level, which implies that it's possible to have a single depth buffer on
a mipmapped/cubemapped pbuffer. That's always better than a depth buffer
per mipmap/cubemap face, but still far from the ideal of a shared depth
buffer for *every* renderable texture.