[Mesa-dev] How to obtain OpenGL implementation/driver information?

[Eric Anholt]

On Fri, 4 Feb 2011 08:58:31 -0800 (PST), Benoit Jacob <bjacob at mozilla.com> wrote:
> ----- Original Message -----
> > On Thu, Feb 3, 2011 at 4:37 PM, Benoit Jacob <bjacob at mozilla.com>
> > wrote:
> > > Hi,
> > >
> > > 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.
> > >  * This can take long (this affects the startup time of the
> > >  browser).
> > >  * This doesn't always give driver version information (at least the
> > >  ATI blob doesn't seem to).
> > >
> > > 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.
> > >
> > > Is there a good solution to this problem? It might even be
> > > acceptable to assume that the X server is local, although of course
> > > I would prefer a solution that works with remote X.
> > >
> > > I've been told to check xdriinfo, but this seems to only give the
> > > driver name and not a driver version. I've also been told that
> > > checking for GLX >= 1.4 would already ensure Mesa >= 7.9, is that
> > > correct?
> > >
> > > Cheers,
> > > Benoit
> > 
> > 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. glGetString is one of the most
> > tested gl functions with the open source stack as it's the foundation
> > of one of the most used gl program on linux aka glxinfo. I never did
> > see glxinfo trigger a crash on any released mesa.
> 
> 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
> 
> It seems that such crashes happen only after a X error in
> glxCreateNewContext. So it may be possible to avoid them by doing
> XSync and checking for errors. But that makes the process even slower.

> 
> It's not surprising that we'd be hitting crashes that glxinfo doesn't, since we may have done lots of X and GL calls already earlier in our application. One could say that we should check driver information once and for all upon creation of the first GL context; but I've had users experiencing these crashes already upon creation of the first GL context (mozilla bug 616416)

It would be good to get some testcases to produce these failures.  I've
spent the last 2 hours trying to come up with any way I could execute a
valid series of GLX calls that would result in a segfault in MakeCurrent
on my non-gallium driver, focusing on getting an error from
glXCreateNewContext().  I've got a couple of new piglit cases for GLX
stuff out of it, but no evidence that there's a problem.  If the gallium
drivers are failing, they should just be fixed instead of blacklisting
them so they never get fixed.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110204/90bc06aa/attachment.pgp>