Re: GLX in bad state

Firstly, please add my patch to CVS.

Secondly, I am trying to avoid a convoluted discussion about nothing.
I know very little about the XBox.  I cannot recall what it even looks 
like.

Here is an excerpt from the ARB_render_texture Spec Overview:

    This extension may provide a performance boost and reduce memory
    requirements on architectures that support rendering to the same
    memory where textures reside and in the same memory format and layout
    required by texturing. The functionality is similar to CopyTexImage1D
    and CopyTexImage2D. However, some changes were made to make it easier
    to avoid copying data:

(Interpretation: Same memory format and layout.)

>From the Implementation Notes:
 
    1. In order to prevent releases of a pbuffer from the texture object
       and to deal with implicit release followed by an explicit release,
       the GL implementation can keep a reference to any texture pbuffer
       in the texture object. When the pbuffer is released, this handle
       is set to NULL. Subsequent requests for releasing the texture
       pbuffer are ignored. 

You create a texture by temporarily binding a pbuffer.  The texture 
image does not persist after you release the pbuffer.  Ergo, the texture does
not have a permanent hold on video memory.  The pbuffer may be used 
elsewhere.  You can have 1000 textures and only use one pbuffer.

Please re-read the spec.

Nadav Frum
----------

On Mon, 5 Apr 2004, Ove Kaaven wrote:

> 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'veseen) 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.