idr at us.ibm.com
Wed Jun 8 17:07:09 PDT 2005
David Reveman wrote:
> On Wed, 2005-06-08 at 11:06 -0700, Ian Romanick wrote:
>>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
> 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.
Currently, WGL_ARB_render_texture works by modifying wglCreatePbuffer to
accept an attribute that says you intend to bind the pbuffer to a
texture. I see no reason why glXCreateWindow and glXCreatePixmap could
not get the same treatment. The driver would just have to be careful
about the fbconfigs that it exports. So, if the driver can't map a
window to a texture, don't export an fbconfig with both
BIND_TO_TEXTURE_* set to true and DRAWABLE_TYPE with WINDOW_BIT set.
The catch to all of this is that it more and more requires GLX 1.3. :(
> 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?
If we spec it the way I described above, they could all the
GLX_EXT_render_texture string to their drivers with essentially no
changes. Whether or not they want to export fbconfigs that allow
binding of windows or pixmaps to textures will depend 100% on market
pressure and the required effort.
> 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.
Hopefully ATI will end up using the "standard" X.org libGL on the
client-side. Since they use DRI, there shouldn't be any technical
reason to prevent it (aside from missing functionality that they may
require). Nvidia, on the other, will have to add that protocol support.
More information about the xorg