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

Mon Feb 7 08:34:05 PST 2011

----- Original Message -----
> 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.

Couldn't the driver information still be split from the rest and accessible without creating a GL context?

> 
> 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?

Actually, a Google search for 'glxinfo crash' gives lots of results:

  http://www.google.ca/search?q=glxinfo+crash

I get 143,000 results; restricting to the past year, I still get 11,500; and even if it turned out that glxinfo crashes had disappeared on current versions, I would still need a way of identifying these new versions.

It now seems to me that our best bet is to follow Brian's advice and create a tiny "glxinfo-like" app, to be run as a separate process at Firefox startup.

Cheers,
Benoit

> 
> ~ 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>