----- 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 <z...@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 <bja...@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 > >>> > > >> <bja...@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@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 > <mostawesomed...@gmail.com> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
