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

[tom fogal]

Benoit Jacob <bjacob at mozilla.com> writes:
> 
> ----- 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.
> > >
> > > 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.

But who says they won't crash in the future?

"bugs exist".  Code changes, some bugs go away, new ones get created.
Once the glXMakeCurrent issue you're seeing is fixed, there should
(from then on) be no reason to "trust" the glXQuery code anymore than
the MakeCurrent code.

I'll admit that a glXQuery hack gets you going quicker.  I just don't
think it's the correct solution; it adds code in a library that
probably won't be called by anyone but your team and your software.
Sounds like a sure way to ensure bugs creep in unnoticed.

> > > 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.
> >
> > I don't think you need to XSync. Just do:
> >
> > glXCreateContext(...)
> > glGetString(...)
>
> After I create a GL context, don't I need to make it current? Are you
> saying that glXCreateContext makes the newly created context current?

sorry, no, you need it (of course!), I was just typing in a hurry.

-tom