[Mesa3d-dev] GLX_MESA_render_texture

[Ian Romanick]

David Reveman wrote:
> I've implemented "render texture"-like support in Xgl. I've used the
> GLX_MESA_render_texture name for now but I'm not even sure that we want
> to call it something with render_texture.

This came up tangentally in the ARB superbuffers group.  Basically,
*_render_texture is a misnomer.  You're not rendering to a texture at
all.  You're texturing from a drawable.

In any case, I don't think adding another *_render_texture extension is
the right way to go.  Even before the superbuffers group got started,
the ARB dumped the idea of doing a GLX_ARB_render_texture extension.
I'll have to think about it, but it seems like it should be possible to
layer a window-system extension on GL_EXT_framebuffer_object to achieve
this same result.

Also, I'm pretty sure that ATI ships a version of this in their drivers,
and I think Nvidia might as well.  If we are going to move forward with
this, it would be nice to have all three implementations play nice
together.  That would probably mean making this a GLX_EXT instead of
GLX_MESA.

> When we've figured out an appropriate way for supporting direct
> rendering with Xgl we might have a better solution for allowing a client
> to bind a redirected window to a texture. However, this seems to be a
> good solution, at least for now.
> 
> The server-side implementation is already in CVS. The attached patch
> will add necessary client-side code to Mesa. glXQueryDrawable is
> required but to avoid implementing GLX 1.3 support in the server just to
> get this running I've added a glXQueryDrawableMESA to the extension for
> now. This should of course be removed once we have GLX 1.3 support in
> the server.

If the function of glXQueryDrawableMESA is the same as glXQueryDrawable,
it should use the same GLX protocol.  This is a *mistake* that the ARB
used to make: changing the GLX protocol when an extension is promoted to
the core.  Since GLX 1.3 will eventually be supported, this just adds
unnecessary bloat.

> Vendor private opcodes and enumeration values are completely bogus right
> now. I should be using temporary enumeration values in the range
> [0x6000,0x7FFF] during development, right? How about vendor private
> opcodes? Are there any temporary opcodes that can be used for
> development?

There is a list of allocated opcodes.  For now, I would just pick ones
from the range 5152 - 8191.

http://oss.sgi.com/projects/ogl-sample/registry/doc/reserved.txt

> The attached patch to glxproto.h will define the vendor private opcodes
> I'm currently using.
> 
> I've created a very preliminary specification for
> GLX_MESA_render_texture, just so that we have something to start from.
> I've attached a copy of it. There's some example code in it for those of
> you who are interested in how this extensions is supposed to be used.

There is one thing missing from the spec (and implementation).  The WGL
extension and the (dead) GLX extension both added a new fbconfig
attribute that selected whether or not drawables created with that
fbconfig could be bound to textures.  In WGL, this was
WGL_BIND_TO_TEXTURE_RGB_ARB and WGL_BIND_TO_TEXTURE_RGBA_ARB.  I think
that is an important mechanism to keep.