GLXPixmap and radeon driver

[Glynn Clements]

Michel Dänzer wrote:

> > > > 2. Is there anything which it can do to determine that it can't use a
> > > > GLXPixmap (without terminating the program)?
> > > 
> > > It could catch the error,
> > 
> > The code already checks all return values. The problem is that
> > glXMakeCurrent() doesn't just return false and generate an X error, it
> > terminates the program.
> 
> It's the default Xlib error handler that terminates the program. See the
> XSetErrorHandler manpage. I'm not sure if Xlib isn't too broken to be
> able to recover from this though...

I had forgotten that the default error handler terminates the program. 
The XSetErrorHandler manpage doesn't actually state this (this isn't
an I/O error; I know those can't be recovered from without using a
longjmp() hack).

I also didn't realise that Tk's default X error handler terminates the
program (the program is a hybrid Tcl/Tk and C application, using Togl
for its OpenGL canvas; the code in question is for rendering to a PPM
file).

I'll try installing a more forgiving error handler. If that works,
problem solved.

> > Actually, the symptoms suggest that this would have to be a
> > client-side (libGL) issue, and the specific driver is only triggering
> > the bug.
> 
> The error is generated because you're trying to render to a GLXPixmap,
> which the drivers don't support without DRI2.

Is it not possible for libGL to trap this? glXMakeCurrent returns a
boolean status; it would be nice if it would just return false without
requiring the application to deal with the error. But there may well
be issues which I'm overlooking here.

> > > or maybe check for GLX >= 1.3 or something like that.
> > 
> > AFAICT, GLX Pixmaps are GLX 1.0. They certainly work with some
> > implementations which claim GLX 1.2 (e.g. the "nv" driver and Cygwin's
> > XWin.exe), 
> 
> Because they use software rendering.

Right; although the error occurs in spite of the fact that I'm
creating an indirect rendering context. Is this a consequence of
AIGLX?

> I realize that GLX 1.3 isn't technically a requirement, just that
> rendering to GLXPixmaps should probably work with any implementation
> that claims to be 1.3 or newer.

However, I wouldn't want to limit it unnecessarily. If we have GLX
1.3, we try to use a pBuffer first. And if we don't have GLX 1.3, it's
either a GLX Pixmap or rendering to the window (which has its own
problems).

> > but other implementations (i.e. the "radeon" driver) die.
> > 
> > In any case, glXCreateGLXPixmap() is returning a valid XID. The
> > problem only occurs if you try to use it.
> 
> GLXPixmaps can be used for GLX_EXT_texture_from_pixmap, they just can't
> be rendered to without DRI2.

Ah; that explains whey glXCreateGLXPixmap() doesn't just fail (I
couldn't see the point in returning a GLXPixmap if you couldn't
actually render to it).

> Which points to another possible test for a workaround: if the context
> uses direct rendering and GLX_EXT_texture_from_pixmap is in the server
> and client extensions but not the GLX extensions, you probably can't
> render to GLXPixmaps.

The context is always created for indirect rendering:

	    ctx = glXCreateContext(dpy, vi, NULL, GL_FALSE);

-- 
Glynn Clements <glynn at gclements.plus.com>