Last Comment Bug 624593 - Un-blacklist OpenGL drivers on X11 as soon as they get good enough
: Un-blacklist OpenGL drivers on X11 as soon as they get good enough
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All Linux
: -- major with 5 votes (vote)
: ---
Assigned To: Benoit Jacob [:bjacob] (mostly away)
:
: Milan Sreckovic [:milan]
Mentors:
: 632578 (view as bug list)
Depends on: 589546 612194 616416 622294 624935 639842 645407
Blocks: 624390
  Show dependency treegraph
 
Reported: 2011-01-10 16:52 PST by Bill Gianopoulos [:WG9s]
Modified: 2011-05-03 13:47 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Bill Gianopoulos [:WG9s] 2011-01-10 16:52:01 PST
The subject kind of says the whole thing I s this what we want a new Slashdot story to highlight?

The patch for bug 624390 is really not the correct solution here at all for the following reasons:

1.  This is supposed to be blacklist and NOT a whitelist.

2.  Adding a feature that only work using a proprietary driver is in direct
opposition to the entire idea of Linux.

3.  I have zero issues or crashes using the Xorg ATI drivers that are currently
available under fedora 14, so I think this is just a people are using old
kernel/driver issue.

If this is really such a huge crash issue then it should be turned off with a
pref so that users who want to test can turn it on with a pref.  The you can
turn it on with an ENV variable does not work well for the case where Firefox
is launched by clicking on a link form an external application.
Comment 1 Bill Gianopoulos [:WG9s] 2011-01-10 16:53:32 PST
If we cannot more universally support this feature, then supporting in on one proprietary driver is worse than no support at all.
Comment 2 Bill Gianopoulos [:WG9s] 2011-01-10 17:07:03 PST
This may not have been the best way to expose this issue, but I have found that often technical people (and this includes me) kind of have to be beat over the head in order to understand a political issue.
Comment 3 Benoit Jacob [:bjacob] (mostly away) 2011-01-10 17:28:43 PST
Bug titles are the *wrong* place for sensationalism.
Comment 4 Bill Gianopoulos [:WG9s] 2011-01-10 17:34:07 PST
Yes, but I take it you do understand the issue.  The current situation here is not politically good.
Comment 5 Bill Gianopoulos [:WG9s] 2011-01-10 17:39:37 PST
(In reply to comment #3)
> Bug titles are the *wrong* place for sensationalism.

Or was it your intention to say I should just post this on Slashdot?  Perhaps I misinterpreted what you were trying to say here.
Comment 6 Bill Gianopoulos [:WG9s] 2011-01-10 17:46:40 PST
I am still 100% opposed to your summary change.  This is still going along with taking what is supposed to be a blacklist and turning it into a whitelist.  Things should only be blacklisted when they have been proven to cause issues.  The they need to prove they do not cause issues makes this be a whitelist which was NEVER the origianal intention.
Comment 7 Benoit Jacob [:bjacob] (mostly away) 2011-01-10 17:49:37 PST
(In reply to comment #0)
> The subject kind of says the whole thing I s this what we want a new Slashdot
> story to highlight?

It didn't occur to me that anyone would submit such a terrible story, or that any half-decent news site would accept it.

We are doing this *for* Linux, not *against* free drivers.

The fact (see bugs mentioned in bug 624390) is that with at least the free ATI driver and the Nouveau driver, just creating a WebGL context can *easily* crash. If you have been following crash-stats in the past few weeks, you know that this has even been one of the top crashers on Linux.

Whereas a traditional application might decide that it's not their fault if drivers crash, a Web browser like Firefox is an entirely different thing. Indeed, any web page might have a script that creates a WebGL context, thus crashing the above-mentioned Free drivers on Linux. This is always considered a denial-of-service vulnerability, i.e. a security flaw.

Consequently, the choice was:
  * either do what I did, namely blacklist the crashy drivers
  * or give up altogether all hardware acceleration features on Linux
 
I hope that now you agree with me that I didn't have a choice.

Also, we will un-blacklist drivers as soon as we can i.e. as soon as we can do so without compromising with the above DOS risk.

> The patch for bug 624390 is really not the correct solution here at all for the
> following reasons:
> 
> 1.  This is supposed to be blacklist and NOT a whitelist.

Then call it a whitelist, fine. Why make all this fuss for a mere choice of words.

> 2.  Adding a feature that only work using a proprietary driver is in direct
> opposition to the entire idea of Linux.

I'll correct this for you: the very idea of proprietary drivers is in direct opposition with the GPL license of Linux, making it non-redistributable. We're not adding anything new here.

> 
> 3.  I have zero issues or crashes using the Xorg ATI drivers that are currently
> available under fedora 14, so I think this is just a people are using old
> kernel/driver issue.

Great. Given enough data, we might be able to un-blacklist this driver in certain cases (we have certainly had lots of crashes with the Xorg ATI drivers, reported by other people. So we need to figure what (a version number? of what?) determines whether it's crashy.

> If this is really such a huge crash issue then it should be turned off with a
> pref so that users who want to test can turn it on with a pref.

Right now they already can turn it back on with an environment variable, as I explained in the original bug.

We are planning to make this a pref, but right now I needed an immediate solution for beta 9.

>  The you can
> turn it on with an ENV variable does not work well for the case where Firefox
> is launched by clicking on a link form an external application.

Desktop environments have config dialogs for that.
Comment 8 Bill Gianopoulos [:WG9s] 2011-01-10 17:56:47 PST
Well, my feeling is then that people who are using the proprietary driver you have decided to wihitelist can set the environment variable just as easily as those of us using an open source drive that works just as well can.

Still seems to me that you are giving speciral treatment to a proprietary solution in a very no conformant to the Liunx mission way here.
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2011-01-10 18:05:03 PST
> that works just as well

But, see, crash-stats data says it _doesn't.  What we have so far is a claim from you that it doesn't crash for you (with no more information of the sort Benoit asked for in comment 7), and lots of hard data that it does crash for other people.  Unlike the nvidia driver.

I think we would all prefer to blacklist as little as possible.  The question is how we can determine whether we're looking at your situation (whatever it is) or at that of the people who have their drivers crashing all the time.  Some data about your exact setup might help us there...
Comment 10 Benoit Jacob [:bjacob] (mostly away) 2011-01-10 18:07:32 PST
I'm getting tired of this bug title edit war. I filed this bug, contrary to what your edit said, what my patch does *was* my intention.

Given the sorry state of graphics drivers on X11, our only option is to default to blocking and whitelist select drivers.

That I used the word 'blacklist' should not spark such a heated discussion.

As I said, I am entirely open to adding more drivers to the whitelist, actually this has always been the plan. Right now however, the only driver that I know for sure is good enough is the proprietary NVIDIA driver.

If you think that a driver is good, a useful test is to run the WebGL conformance test suite:
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html

If a driver can successfully run all tests (*), in particular without crashing, it's probably good enough.

(*) : currently we still have a couple of bugs, so it's normal that a few tests fail, this is getting fixed.
Comment 11 Bill Gianopoulos [:WG9s] 2011-01-10 18:12:14 PST
(In reply to comment #10)
> I'm getting tired of this bug title edit war. I filed this bug, contrary to
> what your edit said, what my patch does *was* my intention.
> 
> Given the sorry state of graphics drivers on X11, our only option is to default
> to blocking and whitelist select drivers.
> 
> That I used the word 'blacklist' should not spark such a heated discussion.
> 
> As I said, I am entirely open to adding more drivers to the whitelist, actually
> this has always been the plan. Right now however, the only driver that I know
> for sure is good enough is the proprietary NVIDIA driver.
> 
> If you think that a driver is good, a useful test is to run the WebGL
> conformance test suite:
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html
> 
> If a driver can successfully run all tests (*), in particular without crashing,
> it's probably good enough.
> 
> (*) : currently we still have a couple of bugs, so it's normal that a few tests
> fail, this is getting fixed.

NO i Filed this bug so why are you persisting in a summary war?
Comment 12 Bill Gianopoulos [:WG9s] 2011-01-10 18:13:05 PST
Please refer to the Reported by name in the bug.
Comment 13 Benoit Jacob [:bjacob] (mostly away) 2011-01-10 18:18:49 PST
(In reply to comment #11)
> NO i Filed this bug

I was, of course, referring to the same bug that you were referring to in this edited title, namely bug 624390.

> so why are you persisting in a summary war?

I edited the bug title the first time because it was a gratuitous insult.

I edited the bug title the second time because it was making unfounded claims about my "intention". And because I think that my bug title is more to the point of what needs to get done to improve things.
Comment 14 Bill Gianopoulos [:WG9s] 2011-01-10 18:21:38 PST
(In reply to comment #9)
> > that works just as well
> 
> But, see, crash-stats data says it _doesn't.  What we have so far is a claim
> from you that it doesn't crash for you (with no more information of the sort
> Benoit asked for in comment 7), and lots of hard data that it does crash for
> other people.  Unlike the nvidia driver.
> 
> I think we would all prefer to blacklist as little as possible.  The question
> is how we can determine whether we're looking at your situation (whatever it
> is) or at that of the people who have their drivers crashing all the time. 
> Some data about your exact setup might help us there...

What crash stats data do you have form me that shows a crash?

You see what we really have is a I am the developer, it does not crash for me so I want to whitlist my driver and blacklist everything else because it is too hard for me to actually go through the crash data to figure out what really need to be blacklisted.
Comment 15 Joe Drew (not getting mail) 2011-01-10 18:25:57 PST
Bill, Bugzilla is not the place for advocacy. Please take this elsewhere or I'll have your account disabled.
Comment 16 Bill Gianopoulos [:WG9s] 2011-01-10 18:27:17 PST
(In reply to comment #7)
> (In reply to comment #0)
> > The subject kind of says the whole thing I s this what we want a new Slashdot
> > story to highlight?
> 
> It didn't occur to me that anyone would submit such a terrible story, or that
> any half-decent news site would accept it.
> 
> We are doing this *for* Linux, not *against* free drivers.
> 
> The fact (see bugs mentioned in bug 624390) is that with at least the free ATI
> driver and the Nouveau driver, just creating a WebGL context can *easily*
> crash. If you have been following crash-stats in the past few weeks, you know
> that this has even been one of the top crashers on Linux.
> 
> Whereas a traditional application might decide that it's not their fault if
> drivers crash, a Web browser like Firefox is an entirely different thing.
> Indeed, any web page might have a script that creates a WebGL context, thus
> crashing the above-mentioned Free drivers on Linux. This is always considered a
> denial-of-service vulnerability, i.e. a security flaw.
> 
> Consequently, the choice was:
>   * either do what I did, namely blacklist the crashy drivers
>   * or give up altogether all hardware acceleration features on Linux
> 
> I hope that now you agree with me that I didn't have a choice.
> 
> Also, we will un-blacklist drivers as soon as we can i.e. as soon as we can do
> so without compromising with the above DOS risk.
> 
> > The patch for bug 624390 is really not the correct solution here at all for the
> > following reasons:
> > 
> > 1.  This is supposed to be blacklist and NOT a whitelist.
> 
> Then call it a whitelist, fine. Why make all this fuss for a mere choice of
> words.
> 
> > 2.  Adding a feature that only work using a proprietary driver is in direct
> > opposition to the entire idea of Linux.
> 
> I'll correct this for you: the very idea of proprietary drivers is in direct
> opposition with the GPL license of Linux, making it non-redistributable. We're
> not adding anything new here.
> 
> > 
> > 3.  I have zero issues or crashes using the Xorg ATI drivers that are currently
> > available under fedora 14, so I think this is just a people are using old
> > kernel/driver issue.
> 
> Great. Given enough data, we might be able to un-blacklist this driver in
> certain cases (we have certainly had lots of crashes with the Xorg ATI drivers,
> reported by other people. So we need to figure what (a version number? of
> what?) determines whether it's crashy.
> 
> > If this is really such a huge crash issue then it should be turned off with a
> > pref so that users who want to test can turn it on with a pref.
> 
> Right now they already can turn it back on with an environment variable, as I
> explained in the original bug.
> 
> We are planning to make this a pref, but right now I needed an immediate
> solution for beta 9.
> 
> >  The you can
> > turn it on with an ENV variable does not work well for the case where Firefox
> > is launched by clicking on a link form an external application.
> 
> Desktop environments have config dialogs for that.

Look, I was one of the people complaining that this was crashy.

However, I have updated the Linux kernel and ATI drivers to the latest version available under fedora 14 and ALL of my crash issues have been resolved.

(or since you have suddenly changed this to a whitelist, not be whitelisted?) 

Therefore Why would this still be blacklisted?
Comment 17 Bill Gianopoulos [:WG9s] 2011-01-10 18:27:38 PST
(In reply to comment #15)
> Bill, Bugzilla is not the place for advocacy. Please take this elsewhere or
> I'll have your account disabled.

Go ahead!
Comment 18 Joe Drew (not getting mail) 2011-01-10 18:30:53 PST
We will whitelist the relevant drivers once we get their information. Bug 624390 only whitelisted NVIDIA's proprietary drivers to limit crashiness in beta 9.
Comment 19 Bill Gianopoulos [:WG9s] 2011-01-10 18:32:47 PST
I disavow all association with this bug and am marking it INVALID.
Comment 20 Boris Zbarsky [:bz] (still a bit busy) 2011-01-10 18:39:12 PST
> What crash stats data do you have form me that shows a crash?

Crash data is anonymized, so I have no idea what crash data, if any we have from _you_.  However it _does_ include driver information nowadays, and we have crash data from users with ATI drivers.

You say your latest drivers aren't crashing.  That's great to hear.  What's the driver version of those drivers, and whatever other information Benoit needs to add them to the whitelist?  _That_ would benefit both you and other users, but I can understand if you don't want to provide that information.  That's obviously your prerogative.
Comment 21 Bill Gianopoulos [:WG9s] 2011-01-10 18:45:43 PST
(In reply to comment #20)
> > What crash stats data do you have form me that shows a crash?
> 
> Crash data is anonymized, so I have no idea what crash data, if any we have
> from _you_.  However it _does_ include driver information nowadays, and we have
> crash data from users with ATI drivers.
> 
> You say your latest drivers aren't crashing.  That's great to hear.  What's the
> driver version of those drivers, and whatever other information Benoit needs to
> add them to the whitelist?  _That_ would benefit both you and other users, but
> I can understand if you don't want to provide that information.  That's
> obviously your prerogative.

Well, you see that is kind of my issue with this whole thing.  Up until today this was blacklist thing that was blacklisting drivers that crashed, now, all of a sudden it has become a whitelist even though it is still called a blacklist.
Comment 22 Bill Gianopoulos [:WG9s] 2011-01-10 18:48:34 PST
Oh and since Joe Drew has threatened to take away my bugzilla privileges if i help in any way here I guess I really can't.
Comment 23 Bill Gianopoulos [:WG9s] 2011-01-10 19:06:08 PST
(In reply to comment #14)
> (In reply to comment #9)
> > > that works just as well
> > 
> > But, see, crash-stats data says it _doesn't.  What we have so far is a claim
> > from you that it doesn't crash for you (with no more information of the sort
> > Benoit asked for in comment 7), and lots of hard data that it does crash for
> > other people.  Unlike the nvidia driver.
> > 
> > I think we would all prefer to blacklist as little as possible.  The question
> > is how we can determine whether we're looking at your situation (whatever it
> > is) or at that of the people who have their drivers crashing all the time. 
> > Some data about your exact setup might help us there...
> 
> What crash stats data do you have form me that shows a crash?
> 
> You see what we really have is a I am the developer, it does not crash for me
> so I want to whitlist my driver and blacklist everything else because it is too
> hard for me to actually go through the crash data to figure out what really
> need to be blacklisted.

Well so why can't you just set the environment variable?  the issue is that whitelisting only one driver that is proprietary is likely to sit badly with the Linux community.  I think it would be better to put in a patch that just only enables it when you set the environment variable.  It is a political type thing that I know tech people usually have difficulty understanding the importance of.
Comment 24 Christopher Aillon (sabbatical, not receiving bugmail) 2011-01-11 10:59:57 PST
Jumping in here a little late...

It's somewhat lucky that there haven't been any reports of crashes with the proprietary nvidia driver as of yet.  From our experience in distro land, over time, it will prove to be one of the hardest to support well.

I'd like to offer support in getting the open source drivers fixed ASAP, if they haven't yet been.  My guess is that the crashes are occurring on older drivers that have since been fixed, but I haven't seen any of the crashes.  Feel free to sync up with me via direct mail here.
Comment 25 Benoit Jacob [:bjacob] (mostly away) 2011-01-11 11:21:47 PST
(In reply to comment #24)
> Jumping in here a little late...

Oh you're not late, this is only the beginning --- now we can talk about un-blacklisting stuff.

> 
> It's somewhat lucky that there haven't been any reports of crashes with the
> proprietary nvidia driver as of yet.  From our experience in distro land, over
> time, it will prove to be one of the hardest to support well.

We have large-scale statistics at
http://crash-stats.mozilla.com/products/Firefox
with a million beta testers and 20K people on nightlies. Our data says that *for what we are doing* the proprietary NVIDIA driver is stable, and has been for a while.

We're not doing the same as most other GPU-using apps in a linux distro, which may explain the difference in our experiences. Our requirements are different:
 * We don't do any nontrivial OpenGL-X interop at the moment (texture-from-pixmap...) whereas I believe that desktop compositors do a lot of that.
 * We're not relying on AIGLX or anything like that
 * All what we use is pure OpenGL
 * But that we use very extensively, so we really require a 100% complete OpenGL 2 implementation. Whereas a desktop compositor may be happy with a 90% complete implementation, that doesn't work for us (see below).

> I'd like to offer support in getting the open source drivers fixed ASAP, if
> they haven't yet been.  My guess is that the crashes are occurring on older
> drivers that have since been fixed, but I haven't seen any of the crashes. 
> Feel free to sync up with me via direct mail here.

Will do ASAP (give me 2 days, very busy atm). For now, the best way that you can reproduce the crashes and failures that we've been experiencing is to grab a Firefox 4 nightly or beta, run with the environment variable MOZ_GLX_IGNORE_BLACKLIST defined, go to about:config and set webgl.enabled_for_all_sites, and go to:
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html
Run the tests. If a driver can run them all with only few test failures and no crash, it's quite probably good enough.

Feel free to email me. I'm really glad that you wrote and was considering writing to freedesktop.org myself.
Comment 26 Benoit Jacob [:bjacob] (mostly away) 2011-01-11 11:24:24 PST
For an example of a bug report about crashes in free drivers, see Bug 621699.
Comment 27 Benoit Jacob [:bjacob] (mostly away) 2011-01-11 11:32:27 PST
(In reply to comment #25)
> Will do ASAP (give me 2 days, very busy atm). For now, the best way that you
> can reproduce the crashes and failures that we've been experiencing is to grab
> a Firefox 4 nightly or beta,

Actually you really need a nightly for this, as many webgl bugs were fixed.

http://nightly.mozilla.org/
Comment 28 alexszabo1991 2011-01-13 20:22:30 PST
How do I do the enivroment variable MOZ_GLX_IGNORE_BLACKLIST
Comment 29 Benoit Jacob [:bjacob] (mostly away) 2011-01-13 20:24:31 PST
(In reply to comment #28)
> How do I do the enivroment variable MOZ_GLX_IGNORE_BLACKLIST

You could run firefox with a command line like this:
MOZ_GLX_IGNORE_BLACKLIST=1 firefox
Comment 30 alexszabo1991 2011-01-13 20:43:46 PST
(In reply to comment #29)
> (In reply to comment #28)
> > How do I do the enivroment variable MOZ_GLX_IGNORE_BLACKLIST
> 
> You could run firefox with a command line like this:
> MOZ_GLX_IGNORE_BLACKLIST=1 firefox

is there any way not to launch this by command line I have ubuntu if thats needed
Comment 31 Benoit Jacob [:bjacob] (mostly away) 2011-01-13 20:51:34 PST
You don't have to launch this form a terminal, if that's the question. In any desktop environment, you can edit the properties of a menu entry or desktop icon  and set the command line to run an application. Just prepend MOZ_GLX_IGNORE_BLACKLIST=1 there.
Comment 32 Benoit Jacob [:bjacob] (mostly away) 2011-01-15 14:13:04 PST
We're now in touch with xorg driver developers (#gfx on IRC, and taking
this to the xorg-devel list asap) so good stuff may start happening :)
Comment 33 Christopher Aillon (sabbatical, not receiving bugmail) 2011-01-18 09:39:33 PST
Yeah, I saw the thread over on mesa-dev.  Looks like there's traction.  Thanks for starting that thread, Benoit.
Comment 34 Bryan Cassidy 2011-01-19 00:30:54 PST
(In reply to comment #25)
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html
> Run the tests. If a driver can run them all with only few test failures and no
> crash, it's quite probably good enough.

Out of curiosity, how many failures are only a "few"? I managed 5255 of 5332 passing tests (and no crashes) with a Radeon HD 6850 and the latest proprietary drivers. 77 failures seems like a lot, but it's less than 2% of the total...

Details follow. Would attaching the test output (with specific passes and failures) be helpful?

Minefield 4.0b10pre (2011-01-18) x86_64
Linux 2.6.32-27-generic #49-Ubuntu SMP Thu Dec 2 00:51:09 UTC 2010 x86_64 GNU/Linux
X.Org X Server 1.7.6 Release Date: 2010-03-17
AMD Radeon HD 6850
Catalyst 10.12 (proprietary) driver

WebGL Conformance Test Runner
Results: (5255 of 5332 passed, 3 timed out)
Comment 35 Bill Gianopoulos [:WG9s] 2011-01-19 04:26:29 PST
(In reply to comment #34)
> (In reply to comment #25)
> > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html
> > Run the tests. If a driver can run them all with only few test failures and no
> > crash, it's quite probably good enough.
> 
> Out of curiosity, how many failures are only a "few"? I managed 5255 of 5332
> passing tests (and no crashes) with a Radeon HD 6850 and the latest proprietary
> drivers. 77 failures seems like a lot, but it's less than 2% of the total...

That probably is not a lot.  I get 76 failures under Windows Vista 32-bit with the NVIDIA driver, and I don't hear a great clamor to blacklist that driver.
Comment 36 Benoit Jacob [:bjacob] (mostly away) 2011-01-19 04:47:19 PST
(In reply to comment #34)
> (In reply to comment #25)
> > https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/webgl-conformance-tests.html
> > Run the tests. If a driver can run them all with only few test failures and no
> > crash, it's quite probably good enough.
> 
> Out of curiosity, how many failures are only a "few"? I managed 5255 of 5332
> passing tests (and no crashes) with a Radeon HD 6850 and the latest proprietary
> drivers.

That's few failures. So we should consider whitelisting this driver. I'm noting down your catalyst version number and will compare to version numbers that have been known to cause trouble, so we can figure a whitelisting criterion.

Also, an update on free drivers: they have very few failures too, but they tend to crash; this is already being handled by xorg devs, and meanwhile I'm investigating if there may be things we could do to avoid triggering these crashes.
Comment 37 Thomas Ludwig 2011-02-08 02:47:19 PST
For me that site says:

Results: (5334 of 5559 passed, 4 timed out)

I'm using Ubuntu 10.10 with the Nvidia driver v. 173 and FF b12 from https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa
Comment 38 Benoit Jacob [:bjacob] (mostly away) 2011-02-08 04:44:51 PST
No need to report about the Nvidia blob -- it's already whitelisted.

Small update:
http://lists.freedesktop.org/archives/mesa-dev/2011-February/005267.html
we had a conversation on how to implement driver black/whitelists on X11, with Mesa devs and also with a Chromium dev who's trying to do the same thing.

It turns out that there is no other way to get driver info than to create a Gl context and call glGetString(). That means there's no way that's either fast or safe, let alone both. We need a way that's both fast and safe.

The solution I'm going to adopt was suggested by Brian Paul on this list: write a separate small program that does the glGetString thing, and run that as a separate process at Firefox startup.

Will do that in next Firefox version.
Comment 39 Benoit Jacob [:bjacob] (mostly away) 2011-02-08 18:47:51 PST
*** Bug 632578 has been marked as a duplicate of this bug. ***
Comment 40 Benoit Jacob [:bjacob] (mostly away) 2011-02-08 18:55:03 PST
FWIW, i'm going to push a change blacklisting version 260.19 of the NVIDIA driver this week, because crash-stats says it's a massive cause of crashes on linux. See? No favoritism, all vendors are welcome in blacklist land. At least NVIDIA is a little easier to selectively blacklist versions of, because so far just doing glXCreateNewContext/glXMakeCurrent/glGetString hasn't crashed it.
Comment 41 Tom Chiverton 2011-02-09 13:23:47 PST
Replying to closing comment on #632578 (dup of this bug).

Xorg's intel driver v2:2.13.901 on Kubutnu 10.10 (Ubuntu x-org updates PPA) crashes while running the test suite, but I think the whole intel driver is black listed anyway. Consider this a confirmation that's the right thing to do.

"I don't think that any one-sentence
statement can appropriately summarize the WebGL/linux situation at the moment."

The current state does need to be put across well, up front, as there is zero evidence in the GUI that the feature is turned off, and certainly no GUI for turning it back on. I simple change from "WebGL enabled on Linux" to "WebGL enabled on LInux for NVIDIA and some other combinations of video drivers and X servers [link to list]" covers all the bases.

Given there is "difficulty of retrieving driver information to safely whitelist" and things are "are moving quickly, just not quickly enough for the Firefox 4.0 release" this black/white list issue is going to be around for a *long* time. 

The end-user visibility *has* to be improved.
I mean, I knew enough to check about:config and it says webgl.disabled is the default setting, false i.e. WebGL is on, but *actually* WebGL is disabled and can't be except with a startup time option. Could, at the least, the preference display the actual value (i.e. if the driver is black listed, default to disabled=true) ? 
Otherwise I foresee a lot of confusion, esp. on Linux, where it seems the drivers are less stable than on other platforms (though I get a consistent crash even on WinXP with the latest ATI driver : #629623)
Comment 42 Benoit Jacob [:bjacob] (mostly away) 2011-02-09 13:36:34 PST
Tom, the problem is time. We don't have time to do perfect communication in the 4.0 timeframe. I will get in touch with release notes writers to check the 4.0 final release notes. In the next Firefox version we'll get this right.
Comment 43 Lothsahn 2011-03-01 08:18:16 PST
Not sure if you need information on the nvidia blob, because you said you were blacklisting 260.

Benoit:  Is there an appropriate place that we can run the conformance test and send the information to Mozilla?  Perhaps something that could happen with a FF user study?


My System and results:
Dell M6400 Laptop
Windows 7 SP1
NVIDIA Quadro FX 3700M 
Driver version: 258.96

WebGL Conformance Test Results
Version 1.0.0

-------------------

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
WebGL VENDOR: Mozilla
WebGL VERSION: WebGL 1.0
WebGL RENDERER: Mozilla
WebGL R/G/B/A/Depth/Stencil bits (default config): 8/8/8/8/24/0

-------------------

Test Summary (5468 total tests):
Tests PASSED: 5389
Tests FAILED: 79
Tests TIMED OUT: 1

Generated on: Tue Mar 01 2011 11:14:17 GMT-0500 (Eastern Standard Time)
Comment 44 Benoit Jacob [:bjacob] (mostly away) 2011-03-01 09:00:50 PST
It turned out that the NVIDIA drivers are fine --- the crashes we were getting with them were our fault. It's fixed now. So, they're not getting blacklisted after all.
Comment 45 Pavlos Touboulidis 2011-03-25 17:43:45 PDT
The Intel driver (2.14.0-3) doesn't crash over here.

$ uname -a
Linux xxxxx 2.6.37-ARCH #1 SMP PREEMPT Tue Mar 15 11:40:49 UTC 2011 i686 Intel(R) Celeron(R) CPU 530 @ 1.73GHz GenuineIntel GNU/Linux

$ glxinfo | egrep -i vendor\|renderer\|version
server glx vendor string: SGI
server glx version string: 1.4
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
GLX version: 1.4
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 965GME/GLE  x86/MMX/SSE2
OpenGL version string: 2.1 Mesa 7.10.1
OpenGL shading language version string: 1.20

$ pacman -Qs xf86-video-intel
local/xf86-video-intel 2.14.0-3 (xorg-drivers xorg)
    X.org Intel i810/i830/i915/945G/G965+ video drivers

[   115.048] (II) LoadModule: "intel"
[   115.090] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[   115.132] (II) Module intel: vendor="X.Org Foundation"
[   115.132]    compiled for 1.9.4, module version = 2.14.0
[   115.132]    Module class: X.Org Video Driver
[   115.132]    ABI class: X.Org Video Driver, version 8.0
[   115.147] (II) intel: Driver for Intel Integrated Graphics Chipsets: i810,
        i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G,
        E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G,
        965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45,
        4 Series, G45/G43, Q45/Q43, G41, B43, B43, Clarkdale, Arrandale,
        Sandybridge, Sandybridge, Sandybridge, Sandybridge, Sandybridge,
        Sandybridge, Sandybridge
[   115.157] (--) intel(0): Chipset: "965GME/GLE"


WebGL Conformance Test Results
Version 1.0.0

-------------------

User Agent: Mozilla/5.0 (X11; Linux i686; rv:2.2a1pre) Gecko/20110325 Firefox/4.2a1pre
WebGL VENDOR: Mozilla
WebGL VERSION: WebGL 1.0
WebGL RENDERER: Mozilla
WebGL R/G/B/A/Depth/Stencil bits (default config): 8/8/8/8/24/0

-------------------

Test Summary (5813 total tests):
Tests PASSED: 5627
Tests FAILED: 186
Tests TIMED OUT: 1

-------------------
Comment 46 Pavlos Touboulidis 2011-03-25 18:37:03 PDT
I just found out that it does, unfortunately, crash consistently and at a specific point when running the "No Comply" webgl demo on demos.mozilla.org.

https://crash-stats.mozilla.com/report/index/bp-2f25017f-808c-43de-bfdd-de3e52110325
Comment 47 Benoit Jacob [:bjacob] (mostly away) 2011-03-25 18:50:33 PDT
Hm, this looks like it could be bug 612194. Can you try its testcase:

https://bugzilla.mozilla.org/attachment.cgi?id=490499

does it crash your driver?

I was kind of hoping that checking for Mesa >= 7.10 would be enough to whitelist Intel cards, apparently that was too naive.
Comment 48 Tom Chiverton 2011-03-26 07:30:36 PDT
FWIW I don't get a crash on the conformance suite with my Intel driver any more. I'm on an upsteam X.org release (xserver-xorg-video-intel 2.14.0+git20110220.9599fde6-0ubuntu0sarvatt~maverick from xorg-edgers) but mostly Ubuntu 10.10.
However, there are many failures in the suite. The No Comply demo works fine too.
Comment 49 Bill Gianopoulos [:WG9s] 2011-03-26 07:55:08 PDT
Please supply a number instead of many.  The only permitted driver (the NVIDIA one) has many sections that fail.  I think the current idea is that the criteria for enabling is that it perform the suite without crashing the browser (of course if it fails almost every section, then a different decision might be made)
Comment 50 Benoit Jacob [:bjacob] (mostly away) 2011-03-26 08:40:36 PDT
(In reply to comment #49)
> Please supply a number instead of many.  The only permitted driver (the NVIDIA
> one) has many sections that fail.

Notice that these aren't bugs in the driver --- this is just that we are still not 100% WebGL 1.0 compliant (we're not far, though. we pass more that 98% tests on all platforms).
 
> I think the current idea is that the
> criteria for enabling is that it perform the suite without crashing the browser
> (of course if it fails almost every section, then a different decision might be
> made)

Yes, that is more or less where I am currently standing. So I am still very tempted of whitelisting Mesa >= 7.10 Intel, even with the glGenerateMipmaps crash, as long as that crash doesn't look exploitable. Since bug 612194 is a null pointer dereference, it's not exploitable.

The GLX probe (bug 639842) is ready, so we can now do this whitelisting.
Comment 51 Bill Gianopoulos [:WG9s] 2011-03-26 09:59:30 PDT
(In reply to comment #50)
> (In reply to comment #49)
> > Please supply a number instead of many.  The only permitted driver (the NVIDIA
> > one) has many sections that fail.
> 
> Notice that these aren't bugs in the driver --- this is just that we are still
> not 100% WebGL 1.0 compliant (we're not far, though. we pass more that 98%
> tests on all platforms).
> 
> > I think the current idea is that the
> > criteria for enabling is that it perform the suite without crashing the browser
> > (of course if it fails almost every section, then a different decision might be
> > made)
> 
> Yes, that is more or less where I am currently standing. So I am still very
> tempted of whitelisting Mesa >= 7.10 Intel, even with the glGenerateMipmaps
> crash, as long as that crash doesn't look exploitable. Since bug 612194 is a
> null pointer dereference, it's not exploitable.
> 
> The GLX probe (bug 639842) is ready, so we can now do this whitelisting.

Well, that is why I asked for a number.  many does not tell us much.  If it is within range of what we are accepting (which some might categorize as many) then it is acceptable.
Comment 52 Bill Gianopoulos [:WG9s] 2011-03-26 10:05:05 PDT
I would consider 50 failures to be many.  But we have no driver OpenGL configuration that I now of that really even approaches just 50 failures.

Therefore, this remains a how many tests failed and is that within the range of what has been deemed acceptable in the past as long as the test does not result in a crash.

My point was that many does not tell us anything, we need a count of failing tests.  based on total tests - tests passed.
Comment 53 Pavlos Touboulidis 2011-03-26 10:22:39 PDT
(In reply to comment #47)
> Hm, this looks like it could be bug 612194. Can you try its testcase:
> 
> https://bugzilla.mozilla.org/attachment.cgi?id=490499
> 
> does it crash your driver?
> 
Nope, it doesn't crash and it doesn't produce any alerts or errors on the error console; it just shows a blank screen.
Comment 54 Tom Chiverton 2011-03-26 12:35:29 PDT
OK, below is the detailed output (intel X driver, Mesa version appears to be 7.11.0+git20110222.7aeb610f-0ubuntu0sarvatt~maverick now you've mentioned that's important too :-) ).


WebGL Conformance Test Runner
Version 1.0.0

Results: (5626 of 5813 passed, 1 timed out)
	

WebGL Conformance Test Results
Version 1.0.0

-------------------

User Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0
WebGL VENDOR: Mozilla
WebGL VERSION: WebGL 1.0
WebGL RENDERER: Mozilla
WebGL R/G/B/A/Depth/Stencil bits (default config): 8/8/8/8/24/0

-------------------

Test Summary (5813 total tests):
Tests PASSED: 5626
Tests FAILED: 187
Tests TIMED OUT: 1

-------------------

Individual Test Results (pass / total / timeout):

conformance/array-buffer-crash.html: 2 / 2 / 0
conformance/array-buffer-view-crash.html: 2 / 2 / 0
conformance/array-unit-tests.html: 286 / 286 / 0
conformance/bad-arguments-test.html: 108 / 108 / 0
conformance/buffer-bind-test.html: 8 / 8 / 0
conformance/buffer-data-array-buffer.html: 12 / 12 / 0
conformance/buffer-preserve-test.html: 2 / 4 / 0
conformance/canvas-test.html: 15 / 16 / 0
conformance/constants.html: 2 / 2 / 0
conformance/context-attributes-alpha-depth-stencil-antialias.html: 25 / 25 / 0
conformance/context-lost-restored.html: 1 / 1 / 0
conformance/context-lost.html: 11 / 11 / 0
conformance/context-type-test.html: 5 / 5 / 0
conformance/copy-tex-image-and-sub-image-2d.html: 503 / 503 / 0
conformance/draw-arrays-out-of-bounds.html: 33 / 33 / 0
conformance/draw-elements-out-of-bounds.html: 50 / 50 / 0
conformance/error-reporting.html: 22 / 22 / 0
conformance/framebuffer-object-attachment.html: 328 / 394 / 0
conformance/framebuffer-test.html: 26 / 26 / 0
conformance/get-active-test.html: 42 / 42 / 0
conformance/gl-bind-attrib-location-test.html: 13 / 13 / 0
conformance/gl-clear.html: 8 / 8 / 0
conformance/gl-drawelements.html: 7 / 7 / 0
conformance/gl-enable-enum-test.html: 68 / 68 / 0
conformance/gl-enable-vertex-attrib.html: 3 / 3 / 0
conformance/gl-enum-tests.html: 22 / 22 / 0
conformance/gl-get-active-attribute.html: 15 / 16 / 0
conformance/gl-get-active-uniform.html: 61 / 61 / 0
conformance/gl-get-calls.html: 75 / 75 / 0
conformance/gl-getshadersource.html: 1 / 3 / 0
conformance/gl-getstring.html: 7 / 7 / 0
conformance/gl-min-attribs.html: 3 / 3 / 0
conformance/gl-min-textures.html: 3 / 3 / 0
conformance/gl-min-uniforms.html: 6 / 6 / 0
conformance/gl-object-get-calls.html: 83 / 85 / 0
conformance/gl-pixelstorei.html: 13 / 13 / 0
conformance/gl-scissor-test.html: 6 / 6 / 0
conformance/gl-shader-test.html: 3 / 3 / 0
conformance/gl-teximage.html: 95 / 95 / 0
conformance/gl-uniform-arrays.html: 79 / 79 / 0
conformance/gl-uniform-bool.html: 2 / 2 / 0
conformance/gl-uniformmatrix4fv.html: 16 / 16 / 0
conformance/gl-unknown-uniform.html: 5 / 5 / 0
conformance/gl-vertex-attrib.html: 515 / 515 / 0
conformance/gl-vertex-attrib-zero-issues.html: 14 / 14 / 0
conformance/gl-vertexattribpointer.html: 782 / 782 / 0
conformance/glsl-conformance.html: 107 / 110 / 0
conformance/incorrect-context-object-behaviour.html: 23 / 23 / 0
conformance/index-validation-copies-indices.html: 7 / 7 / 0
conformance/index-validation-crash-with-buffer-sub-data.html: 2 / 2 / 0
conformance/index-validation-verifies-too-many-indices.html: 4 / 4 / 0
conformance/index-validation-with-resized-buffer.html: 8 / 8 / 0
conformance/index-validation.html: 18 / 18 / 0
conformance/instanceof-test.html: 20 / 20 / 0
conformance/invalid-UTF-16.html: 2 / 2 / 0
conformance/invalid-passed-params.html: 50 / 74 / 0
conformance/is-object.html: 25 / 25 / 0
conformance/methods.html: 2 / 2 / 0
conformance/more-than-65536-points.html: 7 / 7 / 0
conformance/null-object-behaviour.html: 44 / 44 / 0
conformance/null-uniform-location.html: 41 / 41 / 0
conformance/object-deletion-behaviour.html: 61 / 71 / 0
conformance/oes-standard-derivatives.html: 9 / 9 / 0
conformance/oes-texture-float.html: 5 / 5 / 0
conformance/oes-vertex-array-object.html: 5 / 5 / 0
conformance/origin-clean-conformance.html: 12 / 12 / 0
conformance/point-size.html: 2 / 2 / 0
conformance/program-test.html: 62 / 62 / 0
conformance/premultiplyalpha-test.html: 21 / 25 / 0
conformance/read-pixels-pack-alignment.html: 82 / 82 / 0
conformance/read-pixels-test.html: 121 / 125 / 0
conformance/renderbuffer-initialization.html: 6 / 6 / 0
conformance/resource-sharing-test.html: 3 / 3 / 0
conformance/tex-image-and-sub-image-2d-with-array-buffer-view.html: 193 / 193 / 0
conformance/tex-image-and-sub-image-2d-with-image-data.html: 17 / 17 / 0
conformance/tex-image-and-sub-image-2d-with-image.html: 9 / 9 / 0
conformance/tex-image-and-sub-image-2d-with-video.html: 0 / 1 / 1
conformance/tex-image-and-uniform-binding-bugs.html: 6 / 6 / 0
conformance/tex-image-with-format-and-type.html: 73 / 73 / 0
conformance/tex-image-with-invalid-data.html: 8 / 8 / 0
conformance/tex-input-validation.html: 63 / 63 / 0
conformance/tex-sub-image-2d-bad-args.html: 13 / 19 / 0
conformance/tex-sub-image-2d.html: 2 / 2 / 0
conformance/texparameter-test.html: 1 / 37 / 0
conformance/texture-active-bind-2.html: 5 / 5 / 0
conformance/texture-active-bind.html: 10 / 10 / 0
conformance/texture-complete.html: 2 / 2 / 0
conformance/texture-formats-test.html: 84 / 84 / 0
conformance/texture-npot.html: 26 / 26 / 0
conformance/texture-transparent-pixels-initialized.html: 3 / 3 / 0
conformance/triangle.html: 2 / 2 / 0
conformance/type-conversion-test.html: 808 / 808 / 0
conformance/uniform-location.html: 25 / 25 / 0
conformance/uniform-samplers-test.html: 5 / 5 / 0
conformance/uninitialized-test.html: 16 / 19 / 0
conformance/viewport-unchanged-upon-resize.html: 3 / 4 / 0
conformance/webgl-specific.html: 32 / 44 / 0
conformance/more/conformance/constants.html: 1 / 1 / 0
conformance/more/conformance/getContext.html: 2 / 2 / 0
conformance/more/conformance/methods.html: 1 / 1 / 0
conformance/more/conformance/quickCheckAPI.html: 0 / 1 / 0
conformance/more/conformance/webGLArrays.html: 4 / 4 / 0
conformance/more/functions/bindBuffer.html: 2 / 2 / 0
conformance/more/functions/bindBufferBadArgs.html: 3 / 3 / 0
conformance/more/functions/bindFramebufferLeaveNonZero.html: 1 / 1 / 0
conformance/more/functions/bufferData.html: 2 / 2 / 0
conformance/more/functions/bufferDataBadArgs.html: 1 / 1 / 0
conformance/more/functions/bufferSubData.html: 2 / 2 / 0
conformance/more/functions/bufferSubDataBadArgs.html: 1 / 1 / 0
conformance/more/functions/copyTexImage2D.html: 1 / 2 / 0
conformance/more/functions/copyTexImage2DBadArgs.html: 1 / 1 / 0
conformance/more/functions/copyTexSubImage2D.html: 1 / 2 / 0
conformance/more/functions/copyTexSubImage2DBadArgs.html: 0 / 1 / 0
conformance/more/functions/deleteBufferBadArgs.html: 0 / 1 / 0
conformance/more/functions/drawArrays.html: 2 / 2 / 0
conformance/more/functions/drawArraysOutOfBounds.html: 7 / 7 / 0
conformance/more/functions/drawElements.html: 2 / 2 / 0
conformance/more/functions/drawElementsBadArgs.html: 5 / 5 / 0
conformance/more/functions/isTests.html: 1 / 1 / 0
conformance/more/functions/readPixels.html: 2 / 2 / 0
conformance/more/functions/readPixelsBadArgs.html: 3 / 3 / 0
conformance/more/functions/texImage2D.html: 2 / 2 / 0
conformance/more/functions/texImage2DBadArgs.html: 0 / 1 / 0
conformance/more/functions/texImage2DHTML.html: 2 / 2 / 0
conformance/more/functions/texImage2DHTMLBadArgs.html: 1 / 1 / 0
conformance/more/functions/texSubImage2D.html: 1 / 1 / 0
conformance/more/functions/texSubImage2DBadArgs.html: 0 / 1 / 0
conformance/more/functions/texSubImage2DHTML.html: 2 / 2 / 0
conformance/more/functions/texSubImage2DHTMLBadArgs.html: 0 / 1 / 0
conformance/more/functions/uniformf.html: 1 / 1 / 0
conformance/more/functions/uniformfBadArgs.html: 1 / 1 / 0
conformance/more/functions/uniformfArrayLen1.html: 0 / 1 / 0
conformance/more/functions/uniformi.html: 1 / 1 / 0
conformance/more/functions/uniformiBadArgs.html: 1 / 1 / 0
conformance/more/functions/uniformMatrix.html: 1 / 1 / 0
conformance/more/functions/uniformMatrixBadArgs.html: 1 / 1 / 0
conformance/more/functions/vertexAttrib.html: 2 / 2 / 0
conformance/more/functions/vertexAttribBadArgs.html: 1 / 1 / 0
conformance/more/functions/vertexAttribPointer.html: 1 / 1 / 0
conformance/more/functions/vertexAttribPointerBadArgs.html: 1 / 1 / 0
conformance/more/glsl/arrayOutOfBounds.html: 9 / 9 / 0
conformance/more/glsl/uniformOutOfBounds.html: 10 / 10 / 0

-------------------

Generated on: Sat Mar 26 2011 19:34:21 GMT+0000 (GMT)
Comment 55 Benoit Jacob [:bjacob] (mostly away) 2011-05-03 13:30:55 PDT
Today the main blocker was fixed: bug 645407. This means that we are now able to safely detect driver info on X11, have the beginnings of a fine-grained driver white/blacklist on X11, and are able to refine it incrementally.

Here is the current blacklist on X11:
 * Free (Mesa-based) drivers: old Mesa <= 7.9 and Gallium are blocked. If you have Mesa >= 7.10 and your driver is not Gallium-based, you're whitelisted. Blocking Gallium for now was recommended with xorg driver developers and will be further discussed and tracked with them. See http://marc.info/?l=mesa3d-dev&m=126525088903956&w=2 and bug 624935.
 * NVIDIA: we now require version >= 257.21 like we do on Windows.
 * FGLRX: this driver does not provide any version info, so in order to steer clear old drivers, we just require the OpenGL version to be >= 3.0. Any recent FGLRX on recent hardware should work.

I will close this bug now as it's gotten too big. I will file a new tracking bug for incrementally updating the blacklist on X11.
Comment 56 Benoit Jacob [:bjacob] (mostly away) 2011-05-03 13:32:46 PDT
Also, notice that MOZ_GLX_IGNORE_BLACKLIST is no more. All you have to do to force-enable is to go to about:config and set preferences as explained in https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers#How_to_force-enable_blocked_graphics_features

Note You need to log in before you can comment on or make changes to this bug.