On Fri, 4 Feb 2011 08:58:31 -0800 (PST), Benoit Jacob <bja...@mozilla.com> wrote: > ----- Original Message ----- > > On Thu, Feb 3, 2011 at 4:37 PM, Benoit Jacob <bja...@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 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.
pgpVTTaCYMVGp.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
