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

[Jerome Glisse]

On Fri, Feb 4, 2011 at 6:50 PM, Benoit Jacob <bjacob at mozilla.com> wrote:
>
>
> ----- Original Message -----
>> 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
>
> This user comment,
> https://bugzilla.mozilla.org/show_bug.cgi?id=616416#c27
> suggests that it's related to rotating the screen.
>
> Also, this comment,
> https://bugzilla.mozilla.org/show_bug.cgi?id=616416#c1
> gives precise version information (it may well have been fixed since, but we'd still want to blacklist the old version).
>
>> 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.
>
> We have no choice but to blacklist drivers that are known to be crashy; these days mainstream newspaper web pages are creating WebGL contexts just to 'test html5 features' (whatever that means). That bug 616416 was on economist.com. If we don't blacklist drivers for WebGL, then people with crashy drivers may no longer be able to access many web pages.
>
> Benoit
>

The bottom line here is that there is no way around creating & making
current a GLX context. And i am pretty sure no one in mesa or Xorg is
willing to through some nuts new API just for one app. mesa+Xorg glx
have been around for long enough time that we can safely assume that
until now everyone was happy enough with the current querying method
and never suffered any kind of critical issues.

I think the issue you have is that you believe the mesa+GLX open
source stack is crap and doesn't work based on couple bugs that no one
in the community have been able to reproduce so far (i haven't tried
hard, i should try with rotating monitor). Be sure that we will fix
any outstanding issue (ie any issue where we crash the program while
we should just bailout and report error) but we can't fix miss use of
API by client application.

Cheers,
Jerome Glisse