[Mesa3d-dev] GLX_MESA_render_texture

[David Reveman]

On Wed, 2005-06-08 at 11:06 -0700, Ian Romanick wrote: 
> 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.

As you said *_render_texture is really about texturing from a drawable
and that's exactly what we like to do. GL_EXT_framebuffer_object is not
about texturing, hence having a dependency on GL_EXT_framebuffer_object
for doing this seems like a bad idea to me.

> 
> 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.

Yes, I guess that would be nice.

The big difference between GLX_MESA_render_texture and
WGL_ARB_render_texture (GLX_ATI_render_texture as well I guess) right
now is that MESA_render_texture can be used not only with pbuffers but
with any GL drawable. Having support for GLXPixmaps makes it possible to
bind redirected windows to textures and that's what we like to do.

We can have GLX_EXT_render_texture not support anything else than
pbuffers but then we'll need an additional extension for creating a
pbuffer from a redirected window or a pixmap. A new attribute for
glXCreatePbuffer would probably be enough for such an extension. If we
want a GLX_EXT_render_texture this might be a good idea, but do you
think Nvidia and ATI really care about a GLX_EXT_render_texture now that
we've got GL_EXT_framebuffer_object?

I do hope that they can have the necessary client-side support so that
their GL libraries can be used with indirect rendering clients running
on top of Xgl that like to use this functionality. 

> 
> > 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.

I agree, glXQueryDrawableMESA should go away asap.

> 
> > 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

Thanks, I'll fix this asap.

> 
> > 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.

Yes, we should probably keep that. I'll update the spec now and I'll
update the implementation as soon as we have server-side support for
fbconfigs.

-David