[Mesa-dev] glXMakeCurrent crashes (was: Re: How to obtain OpenGL implementation/driver information?)
michel at daenzer.net
Fri Feb 4 15:15:27 PST 2011
On Fre, 2011-02-04 at 14:21 -0800, Benoit Jacob wrote:
> ----- Original Message -----
> > Benoit Jacob wrote:
> > > ----- Original Message -----
> > >> On Thu, Feb 3, 2011 at 4:37 PM, Benoit Jacob <bjacob at mozilla.com>
> > >> wrote:
> > >>> I'm trying to see how to implement selective
> > >>> whitelisting/blacklisting of driver versions on X11 (my use case
> > >>> is
> > >>> to whitelist drivers for Firefox). The naive approach consists in
> > >>> creating an OpenGL context and calling glGetString(), however that
> > >>> is not optimal for me, for these reasons:
> > >>> * This has been enough to trigger crashes in the past.
> > >>>
> > >>> Ideally I want to be able to know the driver name, driver version,
> > >>> Mesa version, and any other thing that you think may be relevant.
> > >>> I
> > >>> need to get that information in a fast and safe way.
> > >>>
> > >> There is no other way than glGetString if you ever experienced
> > >> crash
> > >> with it, it would be because you are doing something terribly wrong
> > >> like using it without current context.
> > >
> > > It's not glGetString that's crashing, it's glXMakeCurrent.
> > >
> > > I forwarded a bug report from a user, though he's not been able to
> > > reproduce since:
> > >
> > > https://bugs.freedesktop.org/show_bug.cgi?id=32238
> > >
> > > A search in Mesa's bugzilla confirms that I'm not alone:
> > >
> > > https://bugs.freedesktop.org/show_bug.cgi?id=30557
> > This latter bug looks like an i915 driver bug, as opposed to a
> > MakeCurrent bug.
> > > Since the glGetString way will at best be slow, especially if we
> > > have
> > > to XSync and check for errors, could you consider exposing this
> > > information as new glXGetServerString / glXGetClientString strings?
> > ? I don't understand the logic here.
> > You're hitting a bug in glXCreateContext or MakeCurrent or something
> > like that. So you'd like to add an entire new way to query the same
> > information a driver already provides, just to provide an alternate
> > path
> > that hopefully doesn't exhibit the bug?
> > Just fix the bug! There's no reason for glX extensions to add new
> > functions here.
> My point is just that bugs exist.
> Since bugs exist, I am trying to implement a driver blacklist.
> My problem is that with GLX it's tricky because I can't get answer to
> the question "should I avoid creating GL contexts on this driver"
> without creating a GL context.
> I proposed to allow handling this in glXQuery(Server|Client)String
> because these functions are known to be non-crashy.
What you're asking for is not possible, because the information you need
depends on the context which is current. No shortcuts here I'm
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
More information about the mesa-dev