[compiz] The direct/indirect rendering stuff and compiz

[David Reveman]

On Wed, 2007-04-11 at 16:26 -0700, James Jones wrote:
> On Wednesday 11 April 2007 04:02 pm, Hanno Böck wrote:
> > Hi,
> >
> > In fact, this bugged me a long time and now I'd finally like to
> > have a solution:
> > https://bugs.freedesktop.org/show_bug.cgi?id=8160
> >
> > The issue is:
> > compiz has now some fallback code to indirect rendering if direct
> > doesn't work. But that's completely useless, because it'll fail
> > some lines later, exactly here:
> >         glxExtensions = glXQueryExtensionsString (dpy,
> > screenNum); if (!strstr (glxExtensions,
> > "GLX_EXT_texture_from_pixmap"))
> >
> > The issue is, glXQueryExtensionsString won't return
> > texture_from_pixmap on AIGLX if LIBGL_ALWAYS_INDIRECT isn't set.
> 
> 
> > Now, the hacky solution would be to do something like the patch I
> > attached to the bug 8160.
> >
> > The proper solution would probably to add an optional parameter
> > to glXQueryExtensionsString to force indirect rendering.
> > Shouldn't be that hard, some fiddling around with stdarg/va_list.
> > As this probably results in a small API-change, I wanted to have
> > the opinion of the mesa-folks how to solve this best.
> 
> This is close to a proper solution.  The problem here is, and always 
> has been, that there is no notion of an indirect-rendering or 
> direct-rendering only extension in GLX.  GLX extensions are not 
> specific to a context.  The result of glXQueryExtensionsString() 
> refers to extensions available on the display connection, not the 
> current context according to the GLX spec.

Yes, the current way compiz checks for GLX_EXT_tfp using both a direct
and indirect context is useless and I'll remove it.

> 
> I believe AIGLX reports TFP in the server extension string and not 
> the client extension string.  This implies the client has no 
> support for the extension, regardless of whether the client is 
> being used for direct or indirect rendering.  However, there is 
> currently no mechanism for the client to report that it supports 
> the protocol but not the direct rendering implementation.
> 
> I think the correct solution would be extendeding GLX to support the 
> notion of per-context GLX extension strings, and a mechanism could 
> then be added to query the GLX extensions supported by the current 
> context.
> 
> Or, just do something hacky in the short term and assume all drivers 
> will eventually support both indirect and direct rendering TFP in 
> the near future.  This one-off, hopefully temporary problem may not 
> be enough to justify a whole new extension-querying API.

I agree.

So as I understand the the client side GLX code will return TFP support
if it can be sure that a direct rendering context is not going to be
used. Defining LIBGL_ALWAYS_INDIRECT, is one way of telling it that a
direct rendering context won't be used. Another way would be to disable
support for direct rendering clients on the the server side (not sure
this is possible with AIGLX today), which would be a more appropriate
solution but I understand that people might want to avoid this.

Does anyone know if some code similar to this would work?

glxExtensions = glXQueryExtensionsString (dpy, screenNum);
if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap"))
{
    setenv ("LIBGL_ALWAYS_INDIRECT", "1", 1);
    glxExtensions = glXQueryExtensionsString (dpy, screenNum);
    if (!strstr (glxExtensions, "GLX_EXT_texture_from_pixmap"))
        indirectRendering = TRUE
}

We know pretty well what the problem is and what needs to be done to fix
it so I would be OK with including a workaround like this in head if
people insist that they want it there.

- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aiglx-workaround.diff
Type: text/x-patch
Size: 276 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/compiz/attachments/20070413/8621309d/aiglx-workaround.bin