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

[Corbin Simpson]

God, I hate flying while sick.

A bigger problem is that there is no good way to divine this info without
actually loading the DRI driver, unless we want to reduce Linux
compatibility to the same level as Win32 by only supporting the system
graphics. OTOH, there are a lot of coincidental circumstances which might
help pin down exactly which chipset and driver is in use. I guess knowing
*which* versions of drivers have bugs, and what the bugs are, is part of the
equation.

Sending from a mobile, pardon the brevity. ~ C.
On Feb 4, 2011 4:04 PM, "Jerome Glisse" <j.glisse at gmail.com> wrote:
> 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
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110204/689d794b/attachment.htm>