[Mesa-dev] glXMakeCurrent crashes (was: Re: How to obtain OpenGL implementation/driver information?)

[Corbin Simpson]

I'm not surprised.

One of the key differences in Linux/BSD compared to other platforms is
that DRI/DRM is fundamentally dynamically discovered: You can be free
to not know at boot time which hardware drivers you will need, and
your video card will be properly autodetected and have correct drivers
loaded. This also happens when an application gains DRI capabilities:
A purely userspace driver is loaded only on demand and only for the
precise card which is going to be rendered to.

This system has a lot of advantages, but one disadvantage is that the
driver actually has to be loaded before anything can be discovered
about the driver, including all of the GL strings.

Thinking about this yesterday, I think the biggest question is the one
that Dave posed. If glXMakeCurrent() is killing the WebGL tests, then
this would imply that glxinfo also shows the same bug, since glxinfo
is almost entirely composed of getting a GL context and pulling
strings and limits from it. However, nothing so far has indicated that
glxinfo is broken on these systems. So, what are Fx and Chromium doing
differently or *besides* glXMakeCurrent, that causes these bugs to be
exposed?

~ C.

On Fri, Feb 4, 2011 at 3:29 PM, Zhenyao Mo <zmo at google.com> wrote:
> I have to agree with Benoit here.  The capability to obtain driver
> information safely in linux is important.  It's surprising that there
> is no way we can do it at the moment (at least not that I am aware of,
> and I've asked around quite a few linux experts here at Google
> already).
>
> Zhenyao
>
> On Fri, Feb 4, 2011 at 3:26 PM, Benoit Jacob <bjacob at mozilla.com> wrote:
>>
>>
>> ----- Original Message -----
>>> 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
>>> afraid. :)
>>
>> We're doing driver blacklists on all platforms, and it tends to be quite easy on other platforms. For example, on Windows, we just read all the driver information from the registry. Couldn't X drivers likewise have some metadata stored on disk, that could be queried via some new API? I proposed GLX because glXQueryServerString already knows about at least the driver vendor. But I don't mind having it exposed elsewhere than in GLX if that makes more sense :)
>>
>> Please take this request seriously: driver blacklists are useful, not limited to Firefox, and certainly not limited to X11. As I say, we blacklist drivers on all platforms, and we'd never have been able to make Firefox 4 releasable without blacklisting many Windows drivers. Zhenyao Mo, in CC, is working on similar features in Chromium.
>>
>> Cheers,
>> Benoit
>>
>>>
>>>
>>> --
>>> Earthling Michel Dänzer | http://www.vmware.com
>>> Libre software enthusiast | Debian, X and DRI developer
>>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
When the facts change, I change my mind. What do you do, sir? ~ Keynes

Corbin Simpson
<MostAwesomeDude at gmail.com>