To control the risk of out-of-control crashiness, we've decided that we should only enable hardware acceleration on systems using the newest drivers for their hardware. Currently, this is more or less the case for Intel GPUs; where we need to add it is for NVIDIA and ATI. This means we need to come up with a list of hardware IDs which are capable of running with our requirements (4096x4096 textures, DX9/10) and finding out the latest available drivers for them, then blocklist everything lower than that.

experience with blocklist development has show that these kind of changes benefit greatly from at least one beta cycle. recommend changing this to betaN+

Sounds good.

I'm not so sure this is true for ATI (for NVidia and Intel I completely agree). I've got an ATI machine running on 5 months old drivers running completely stable with no issues what-so-ever (I've had 2 display driver crashes in 7 months, 1 of those while experimenting with things). It seems harsh to punish ATI just because other vendors are shipping problematic drivers.

So, in GFX meeting today, we had a conversation along those lines: * this is only about limiting our risks * the cut-off date for drivers can only be arbitrary (drivers get better all the time, there's not single magic date) * there's no real point in absolutely requiring drivers from January 2011 --- the cut-off date could be a little further back in the past. So I propose to introduce a cut-off date around september 2010 / october 2010. That is 3-4 months old. Will give us most of the risk mitigation while still giving hardware acceleration to the "power users" who keep their systems fairly up to date and will be reviewing/blogging about Firefox 4.

> So I propose to introduce a cut-off date around september 2010 / october 2010. I don't agree because you can have a old GPU with an up-to-date driver and a old driver date. For instance: * Intel Q965 up-to-date driver version on Windows 7 is 8.15.10.1930 and its date is 10/2/2009. * GeForce 8100 up-to-date driver version on Windows 7 is 15.49 and its date is 2009.10.01. If you want to control risk, you need to blocklist some ATI and NVIDIA drivers for D2D/D3D features the same way it has been done for Intel, which means a lot of driver IDs and versions to collect and a compliance matrix to implement.

The compliance matrix implementation is more risky than the risk to control. I recommend a "Won't fix" status for this bug.

(In reply to comment #5) > > So I propose to introduce a cut-off date around september 2010 / october 2010. > I don't agree because you can have a old GPU with an up-to-date driver and a > old driver date. > For instance: > * Intel Q965 up-to-date driver version on Windows 7 is 8.15.10.1930 and its > date is 10/2/2009. > * GeForce 8100 up-to-date driver version on Windows 7 is 15.49 and its date is > 2009.10.01. Sorry, I should have expressed myself more clearly. I didn't mean that we would switch to checking the driver date instead of the driver version. I just meant we would check what driver version was released around that date, and check for it. > > If you want to control risk, you need to blocklist some ATI and NVIDIA drivers > for D2D/D3D features the same way it has been done for Intel, which means a lot > of driver IDs and versions to collect and a compliance matrix to implement. Yep. Where the 'compliance matrix' is in this case just a table of driver versions that were the latest versions at the cut-off date, for each generation of graphics cards. Fortunately I think that ATI and NVIDIA drivers are less divided between generations of graphics cards, than the Intel drivers are.

> Where the 'compliance matrix' is in this case just a table of driver > versions that were the latest versions at the cut-off date, for each generation > of graphics cards. In that case, this bug depends on bug 600280 and bug 621093.

NVIDIA driver releases: 260.99 October 25, 2010 260.89 October 18, 2010 258.96 July 19, 2010 I guess 260.89 is a bad choice since 260.99 was released so shortly after. OK to require 260.99 (current latest) since it's released more than 3 months before our FF4 release. ATI driver releases: Catalyst 10.11 11/17/2010 Catalyst 10.10 10/22/2010 Catalyst 10.9 9/15/2010 I guess we can choose 10.10 since the october 22 release date is closest to NVIDIA's 260.99 release date. We'll just tell the public: to reduce our risks, we arbitrarily require whatever driver version was current on Nov. 1, 2010. For Intel, we have: 8.15.10.2226 22 Nov 2010 8.15.10.2202 16 Sep 2010 So if we stick to the Nov. 1 cut-off date, then we keep version .2202 as our required version, which is cool: less work to do (with intel it's especially hard and bug-prone since they require a different version for each graphics card family and windows version). Also, most Intel graphics bugs were OpenGL and we're going (patch under review) to completely blacklist Intel OpenGL on Windows (was used for WebGL).

In my opinion for Catalyst we can go to 10.3.

In reply to comment 1 > using the newest drivers for their hardware. The bug summary should be "block all out-of-date drivers for ATI, NVIDIA to control risk". In reply to comment 9 Actions in comment 9 are in contradiction with the goal of the bug.

(In reply to comment #9) > > ATI driver releases: > > … > > I guess we can choose 10.10 since the october 22 release date is closest to > NVIDIA's 260.99 release date. We'll just tell the public: to reduce our risks, > we arbitrarily require whatever driver version was current on Nov. 1, 2010. What about ATI drivers for legacy cards? Though I am not sure if any of these card support the required texture size. http://support.amd.com/us/gpudownload/windows/Legacy/Pages/radeonaiw_vista32.aspx

They'll be blocked; trying to support hw accel on legacy cards is not a useful proposition. If people with those cards want to experiment, they can do so by flipping prefs, but won't get anything enabled in a default configuration.

(In reply to comment #11) > In reply to comment 1 > > using the newest drivers for their hardware. > The bug summary should be "block all out-of-date drivers for ATI, NVIDIA to > control risk". > > In reply to comment 9 > Actions in comment 9 are in contradiction with the goal of the bug. The goal of the bug is to control risk. The initial suggestion of blocking everything but the very latest version could have been rephrased as: set today's date (say January 14) as the cut-off date (require whatever driver version is the latest at that date). This choice of a cut-off date is assumedly arbitrary. From there, one may discuss what arbitrary cut-off date to choose. If we had done this 3 months ago, we would have chosed a date 3 months in the past. So I maintain my suggestion to use November 1 as arbitrary cut-off date for NVIDIA and ATI drivers.

(In reply to comment #10) > In my opinion for Catalyst we can go to 10.3. On my NVIDIA machine, the 195.xx has never crashed or given be any trouble, ever. Yet, we know that it has given many crashes on other NVIDIA machines (optimus...). Just explaining why it's not worth discussing any single person's experience here.

(In reply to comment #15) > (In reply to comment #10) > > In my opinion for Catalyst we can go to 10.3. > > On my NVIDIA machine, the 195.xx has never crashed or given be any trouble, > ever. > > Yet, we know that it has given many crashes on other NVIDIA machines > (optimus...). > > Just explaining why it's not worth discussing any single person's experience > here. Right, show me an ATI driver crash on any ATI driver after 10.3 though? I've got plenty of input and all for various versions of NVidia. And I can reproduce issues on 3 out of my 4 NVidia machines, and 0 out of my 3 ATI machines. I'll admit the sample sizes aren't particularly big, but I don't see why we'd block ATI drivers we have no indications are causing trouble :). You have to realize a lot of the people with laptops don't have the -choice- of updating their drivers to something that recent (i.e. many vendors only update once every 6 months or even more rarely). We'd be locking them out for absolutely no reason at all except that it 'reduces risk' well, we can reduce risk by just turning off hardware acceleration everywhere! But that's not the point. We have NVidia crashes on recent drivers, we have an ATI crash on the 10.3 driver lying around somewhere I think (and even that seems very rare with only one report), so I think we don't need to randomly pick dates. I think it's an exceedingly bad idea to take November 1 as a cut-off date for ATI. I also repeat my argument that in my opinion it's rude to punish a company that's doing a good job creating stable drivers because another company isn't.

(In reply to comment #16) > Right, show me an ATI driver crash on any ATI driver after 10.3 though? Bug 605940 is a Direct3D initialization crash reported at least against the 10.9 driver. Bug 619773 is a crash with ATI's OpenGL driver, reported against the 10.11 driver. Bug 605780 is the tracking bug for ATI crashes. It has a crash-stats query URL, but crash-stats seems down at the moment, so I can't get statistically meaningful data. > > I've got plenty of input and all for various versions of NVidia. And I can > reproduce issues on 3 out of my 4 NVidia machines, and 0 out of my 3 ATI > machines. I'll admit the sample sizes aren't particularly big, but I don't see > why we'd block ATI drivers we have no indications are causing trouble :). > > You have to realize a lot of the people with laptops don't have the -choice- of > updating their drivers to something that recent (i.e. many vendors only update > once every 6 months or even more rarely). We'd be locking them out for > absolutely no reason at all except that it 'reduces risk' well, we can reduce > risk by just turning off hardware acceleration everywhere! But that's not the > point. We have NVidia crashes on recent drivers, we have an ATI crash on the > 10.3 driver lying around somewhere I think (and even that seems very rare with > only one report), so I think we don't need to randomly pick dates. > > I think it's an exceedingly bad idea to take November 1 as a cut-off date for > ATI. I also repeat my argument that in my opinion it's rude to punish a company > that's doing a good job creating stable drivers because another company isn't.

> You have to realize a lot of the people with laptops don't have the -choice- of > updating their drivers to something that recent (i.e. many vendors only update > once every 6 months or even more rarely). Of course, we've discussed this many times. If you want to convey the point that ATI drivers are far less crashy than NVIDIA drivers, the most convincing argument would be data straight from crash-stats. I'll dig into this when I can.

(In reply to comment #17) > (In reply to comment #16) > > Right, show me an ATI driver crash on any ATI driver after 10.3 though? > > Bug 605940 is a Direct3D initialization crash reported at least against the > 10.9 driver. Yeah, still haven't really looked at that one, 't was very rare though iirc. > > Bug 619773 is a crash with ATI's OpenGL driver, reported against the 10.11 > driver. Right, but that's not going to affect content acceleration or accelerated layers, and using ANGLE we could do it on the D3D9 driver if we wanted to and avoid this altogether. But yes, statistics are good, I have a feeling, but no proof, that if we block ATI driver 10.6 we might as well block the latest NVidia driver since I think they're actually crashier :). The one statistic we really can't get is how often people's experience 'device hangs' though (i.e. the screen flicker and all). We should probably start gathering that somehow in the future though.

The crash breakdown by GPUs and driver versions is treated in bug 623317.

Here's a breakdown per vendor, using bug 623317's attachment 501535 [details]: $ cat adaptor-vendor-device-inventory | sed 's/^[\ ]*//' | awk '{ SUM += $1} END { print SUM }' 177989 $ cat adaptor-vendor-device-inventory | grep 'AdapterVendorID: 1002' | sed 's/^[\ ]*//' | awk '{ SUM += $1} END { print SUM }' 36205 $ cat adaptor-vendor-device-inventory | grep 'AdapterVendorID: 8086' | sed 's/^[\ ]*//' | awk '{ SUM += $1} END { print SUM }' 57975 $ cat adaptor-vendor-device-inventory | grep 'AdapterVendorID: 10de' | sed 's/^[\ ]*//' | awk '{ SUM += $1} END { print SUM }' 61444 $ cat adaptor-vendor-device-inventory | grep 'AdapterVendorID: 1106' | sed 's/^[\ ]*//' | awk '{ SUM += $1} END { print SUM }' 7561 $ cat adaptor-vendor-device-inventory | grep 'AdapterVendorID: 1039' | sed 's/^[\ ]*//' | awk '{ SUM += $1} END { print SUM }' 5754 $ cat adaptor-vendor-device-inventory | grep 'AdapterVendorID: 5333' | sed 's/^[\ ]*//' | awk '{ SUM += $1} END { print SUM }' 1364 This means that our graphics crashes break down into: 20.3% ATI 32.6% Intel 34.5% NVIDIA 4.2% VIA 3.2% SiS 0.8% S3 I don't know how this represents crashiness of these drivers since I don't know their respective market shares. But if ATI and NVIDIA have equal market share, then this indeed suggests that NVIDIA's driver is crashier.

Note: roughly 4% of crashes reported 0x0000 for vendor ID, I think there's already a bug filed about that.

> This means that our graphics crashes break down into: ... No. It is an overall breakdown. It is not restricted to graphic crashes. Assuming that each user has the same crash rate, it is Fx4 users' GPU market share.

(In reply to comment #23) > > This means that our graphics crashes break down into: ... > No. It is an overall breakdown. It is not restricted to graphic crashes. > Assuming that each user has the same crash rate, it is Fx4 users' GPU market > share. Yup, we should also check if the crash is in the DirectX driver for D2D blocklist considerations.

Ah! OK.

OK, I confirm from crash-stats that we seem to have a roughly 3x more Direct3D crashes with NVIDIA than with ATI; however comment 21 suggests that NVIDIA's market share is roughly 1.7x ATI's among our users (at least among our crashers overall). So yes NVIDIA seems a little crashier than ATI with D3D, but not really markedly enough to not treat them on an equal footing... We had another chat in the Toronto office and we think that actually a cut-off date a bit farther ago is acceptable and won't expose us much more. Maybe something around the early summer, which is when NVIDIA 2xx drivers were introduced.

My nvidia driver from July crashed every 20 Minutes. I would have changed my browser if that would be a final Release and if I would be only a user. Hardware acceleration is a great feature but not that important at the moment.Our users should not deal with crashes and display problems all over the place just because the driver is broken. How much users will find the option to disable the hardware acceleration if they get problems ?

Matthias, do you have a bug number or a link from about:crashes ?

Also, what version of the NVIDIA driver fixed it?

(In reply to comment #28) > Matthias, do you have a bug number or a link from about:crashes ? I think he means his display driver hanging, not his browser crashing. (i.e. black flickering and everything freezing for a second, and then returning to working) I think this is the main area where NVidia (still) is much crashier than ATI, at least in my (admittedly small) sample of 7 machines.

The display driver got killed by win7 after it froze. I don't know if Gecko now recovers from such a crash but the 10s interruption in the workflow is for many people enough to select another browser. This is the first driver that fixed the problem on my system and it's very stable. Adapter DescriptionNVIDIA GeForce 310M Driver Version8.17.12.6089 Driver Date 10-8-2010 There are several examples with driver problems in bugzilla, bug 625877 is one example from the last few days (very old driver). I think we should be very careful with this or we get negative reactions from our users. Maybe we could show a warning if the drivers are too old and in a better place than about:support.

(In reply to comment #31) > The display driver got killed by win7 after it froze. > I don't know if Gecko now recovers from such a crash but the 10s interruption > in the workflow is for many people enough to select another browser. > This is the first driver that fixed the problem on my system and it's very > stable. > > Adapter DescriptionNVIDIA GeForce 310M > Driver Version8.17.12.6089 > Driver Date 10-8-2010 > > There are several examples with driver problems in bugzilla, bug 625877 is one > example from the last few days (very old driver). I think we should be very > careful with this or we get negative reactions from our users. Maybe we could > show a warning if the drivers are too old and in a better place than > about:support. We do recover from this now, I should also add that we -do- have the ability to remotely blacklist additional cards without shipping a new binary.

OK, taking a different approach here. I'm iterating over the top NVIDIA/ATI crash signatures over the past week, that are NOT already fixed as bugs on our side. And I'm collecting the corresponding driver version. Assuming here that a given signature (including address) happens with only one driver version, which is usually the case. Here are the results for NVIDIA: # | signature | version ----+------------------------+-------- 307 | nvwgf2um.dll@0x9de82 | 189.58 287 | nvwgf2um.dll@0x9de22 | 189.11 280 | nvwgf2um.dll@0x9bec2 | 186.40 263 | nvwgf2um.dll@0x9bf22 | 186.88 252 | nvwgf2um.dll@0x9df92 | 188.64 232 | nvwgf2um.dll@0x96d52 | 185.93 195 | nvwgf2um.dll@0x15a9c3 | 260.99 194 | nvwgf2um.dll@0x9df02 | 189.74 163 | nvwgf2um.dll@0xc600f | 194.94 134 | nvwgf2um.dll@0xce6bf | 197.45 123 | nvwgf2um.dll@0x9def2 | 189.88 116 | nvwgf2um.dll@0x9c352 | 186.94 104 | nvwgf2um.dll@0x9dd82 | 187.82 101 | nvwgf2um.dll@0xde7df | 257.38 91 | nvwgf2um.dll@0xe1d9f | 259.36 90 | nvwgf2um.dll@0x9dfb2 | 188.29 86 | nvwgf2um.dll@0xe1c2f | 259.26 74 | nvwgf2um.dll@0xe1ee5 | 258.96 74 | nvwgf2um.dll@0x9db32 | 187.66 74 | nvwgf2um.dll@0xc380f | 195.62 73 | nvwgf2um.dll@0xe232f | 259.85 61 | nvwgf2um.dll@0xde47f | 257.21 61 | nvwgf2um.dll@0x9dfa2 | 189.11 60 | nvwgf2um.dll@0xb3112 | 191.04 58 | nvwgf2um.dll@0x9bc02 | 189.11 Conclusions: * 260.99 seems safe, only 1 signature at 200/week (and it has been the current version for 3 months now), need to file bug though about nvwgf2um.dll@0x15a9c3 * It is true that we get lots of crashes with the 25x.xx versions. This can't be explained by popularity: they have been current for only 5 months from May 24 to October 18, 2010, according to http://www.nvidia.com/Download/Find.aspx?lang=en-us So Mathias is right, we must not allow the 25x.xx versions. * Earlier versions (<200.xx) are, as we knew, the crashiest. In conclusion, for NVIDIA, we should really require 260.99.

I can live with that, we should talk about an approach to make people aware that they can update their drivers though.

> need to file bug though about nvwgf2um.dll@0x15a9c3 Done: Bug 626475 - Crash [@ nvwgf2um.dll@0x15a9c3 ] in ImageLayerD3D10::RenderLayer with latest NVIDIA driver 260.99

Nvidia desktop cards should require the latest drivers since they have no problems with updating to the latest drivers, which will be 266.xx drivers(Nvidia refers to this as 265 series drivers(265.xx - 269.xx). http://www.nvidia.com/object/win7-winvista-64bit-266.35-beta-driver.html "This is the first release from the Release 265 family of drivers (versions 265.xx to 269.xx)." Still waiting for Nvidia to release the WHQL certified 266.xx drivers so that everyone can be encouraged to update to the latest drivers. The biggest headache is of course, notebooks. Even with the latest Nvidia 266.xx drivers, they still won't install on some notebook OEM vendors' notebooks. http://www.nvidia.com/object/notebook-win7-winvista-64bit-266.35-beta-driver.html "Sony has joined the Verde program by supporting the following VAIO notebooks: Sony F Series with NVIDIA GeForce 310M and Sony F Series with NVIDIA GeForce GT 330M. Other Sony VAIO notebooks are not supported at this time (please contact Sony for driver support)."

In reply to comment 33 > I'm iterating over the top NVIDIA/ATI crash signatures over the past week, that > are NOT already fixed as bugs on our side. Bug 612103 (fixed in 20110112) summary is too short to add all these crash signatures for NVIDIA cards. The same for bug 622962 for ATI cards. If you restraint your search to the last 3 days in 4.0b10pre, I see only one crash in the NVIDIA driver (bug 612124).

Great news! *All* of the above crashes with 2xx.xx drivers seem to be duplicates of 612103, which is fixed already (no crashes with builds more recent than January 11). At least those are: 195 | nvwgf2um.dll@0x15a9c3 | 260.99 101 | nvwgf2um.dll@0xde7df | 257.38 91 | nvwgf2um.dll@0xe1d9f | 259.36 86 | nvwgf2um.dll@0xe1c2f | 259.26 74 | nvwgf2um.dll@0xe1ee5 | 258.96 So, the 2xx.xx drivers seem actually very good for us (I don't know if bug 612103 was our bug or was working around a NVIDIA bug, but it doesn't matter for the present purpose)

OK, Bas explains to me that bug 612103 is about recovering from a driver crash after a 10 second interruption in workflow, not about completely avoiding the driver crash. So it's still not all roses.

OK, talked with Bas and Roc. These driver resets are something we can handle at runtime when they happen, since we don't crash with them, so we'll be able to handle them gracefully (e.g. blacklist the driver version when they happen twice in 24 hours). Now on to ATI crashes. Again, all of the top crashers are taken care of by bug 612103. The top non-612103 ATI crasher is atidxx32.dll@0x23c4d8, 40 crashes / week, in cairo-d2d: http://crash-stats.mozilla.com/report/list?product=Firefox&branch=2.0&platform=windows&query_search=signature&query_type=startswith&query=atidxx&date=01%2F17%2F2011%2013%3A10%3A44&range_value=1&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=atidxx32.dll%400x23c4d8 This is in the 10.12 driver. Anyway... 40/week in betas, that doesn't need to block.

OK, so here's where I (and #gfx buddies) currently stand: * the bulk of D3D crashes evaporated with bug 612103, and have become graceful driver resets that interrupt workflow for a few seconds (5-10 seconds). * so this is no longer grave enough to block the release. If we have to, we can still easily disable hw acceleration (blacklist current driver version) when, say, it happens twice within 24 hours. But it's not clear to us that this is grave enough to require doing even that. * the remaining D3D crashes with not-too-old drivers are not prevalent enough to block. By not-too-old I really mean that for NVIDIA we must blacklist <200.00, for good measure blacklist ATI drivers from the same era, and call it a day. That probably means: * NVIDIA: require 257.21 from June 15, 2010. * ATI: require 10.6 from June 17, 2010.

Nvidia just released new GeForce 266.58 WHQL drivers today. Desktop drivers http://www.nvidia.com/object/win7-winvista-32bit-266.58-whql-driver.html http://www.nvidia.com/object/win7-winvista-64bit-266.58-whql-driver.html Notebook drivers http://www.nvidia.com/object/notebook-win7-winvista-266.58-whql-driver.html http://www.nvidia.com/object/notebook-win7-winvista-64bit-266.58-whql-driver.html

Here you go. nontrivial details: - in order to make a good suggestion of driver version, I had to add a new suggestedVersion string field. Indeed, the user-facing driver version may look nothing like the version number we get from the registry. - added both AMD and ATI PCI IDs, just in case they switch in the future.

Here's an additional patch blacklisting VIA, SIS, S3 chips. As shown in comment 21 they make up roughly 8% of our users. We have had crash reports with VIA chips, and can safely expect this hardware to be quite underpowered anyway compared to other desktop GPUs.

Could you rebase these patches on the patches in bug 625160? A lot of this code is going to change when that lands.

Speaking of minor GPU makers, what about Matrox and XGI? Are they that rare that they don't show up?

Rebased against bug 625160

Added Matrox and XGI to the party

Comment on attachment 505463 [details] [diff] [review] block old ATI and NVIDIA drivers, rebased, builds >+ if (status == FEATURE_BLOCKED_DRIVER_VERSION) { >+ if (info->mSuggestedVersion) >+ { >+ aSuggestedDriverVersion.AppendPrintf("%s", info->mSuggestedVersion); >+ } else if (info->mComparisonOp == DRIVER_LESS_THAN && >+ info->mDriverVersion != allDriverVersions) >+ { >+ aSuggestedDriverVersion.AppendPrintf("%lld.%lld.%lld.%lld", >+ (info->mDriverVersion & 0xffff000000000000) >> 48, >+ (info->mDriverVersion & 0x0000ffff00000000) >> 32, >+ (info->mDriverVersion & 0x00000000ffff0000) >> 16, >+ (info->mDriverVersion & 0x000000000000ffff)); >+ } if bracing needs a little work here: if (foo) { ... } else if (blah) { ... } >diff --git a/widget/src/xpwidgets/GfxDriverInfo.cpp b/widget/src/xpwidgets/GfxDriverInfo.cpp > GfxDriverInfo::GfxDriverInfo(OperatingSystem os, PRUint32 vendor, > GfxDeviceFamily devices, > PRInt32 feature, PRInt32 featureStatus, > VersionComparisonOp op, > PRUint64 driverVersion, >+ const char *suggestedVersion /* = nsnull */, > bool ownDevices /* = false */) > : mOperatingSystem(os), > mAdapterVendor(vendor), > mDevices(devices), > mDeleteDevices(ownDevices), > mFeature(feature), > mFeatureStatus(featureStatus), > mComparisonOp(op), > mDriverVersion(driverVersion), >- mDriverVersionMax(0) >+ mDriverVersionMax(0), >+ mSuggestedVersion(suggestedVersion) > {} > > GfxDriverInfo::GfxDriverInfo(const GfxDriverInfo& aOrig) > : mOperatingSystem(aOrig.mOperatingSystem), > mAdapterVendor(aOrig.mAdapterVendor), > mFeature(aOrig.mFeature), > mFeatureStatus(aOrig.mFeatureStatus), > mComparisonOp(aOrig.mComparisonOp), You definitely need to initialize mSuggestedVersion in the copy and default constructor. >diff --git a/widget/src/xpwidgets/GfxDriverInfo.h b/widget/src/xpwidgets/GfxDriverInfo.h >@@ -104,16 +105,18 @@ struct GfxDriverInfo > /* A feature status from nsIGfxInfo */ > PRInt32 mFeatureStatus; > > VersionComparisonOp mComparisonOp; > > /* versions are assumed to be A.B.C.D packed as 0xAAAABBBBCCCCDDDD */ > PRUint64 mDriverVersion; > PRUint64 mDriverVersionMax; >+ >+ const char *mSuggestedVersion; > }; I wouldn't mind this being an nsCString, but I don't feel strongly about it.

Applied your comments, but for the else if (foo) {, note that it's multiline condition, so I really think that the { goes to a new line.

Comment on attachment 505971 [details] [diff] [review] block old ATI and NVIDIA drivers, V2 Two changes I'd like: 1. Change the parameters of the constructors from type nsCString& to nsACString& so that different types don't need to be constructed when passing those arguments. 2. Remove the mSuggestedVersion() constructor in the default constructor's initializer list, since the default constructor will do that implicitly anyways. Looks good, though!

Comment on attachment 505972 [details] [diff] [review] Only whitelist Intel, NVIDIA, ATI We should be pretty explicit about the fact that we're blocking non-major card vendors, so I'm going to see about notifying the documentation folks.

I'm not sure if comment 57 deserves a relnote, but I'll let someone else make that call.

> I'm not sure if comment 57 deserves a relnote, but I'll let someone else make > that call. You can add something in bug 601079 about the min system requirement page for Fx4.

It's bad to assume that old drivers have bugs and the new ones don't have, because old drivers could as well be more stable than new ones, just keep in mind that new drivers always bring new bugs to the table. I have and old driver since ATI has discontinued supporting my graphics card since it's an old ATI Radeon 9600 PRO Directx 9 vertex&pixel shader version 2 but still rock solid don't cause any issues. It would be a shame to disable the hardware acceleration for it. Btw how can I check to see if Firefox is using the hardware acceleration on it ? and can it be turned on if it's disabled ?

(In reply to comment #60) > It's bad to assume that old drivers have bugs and the new ones don't > have, because old drivers could as well be more stable than new ones, > just keep in mind that new drivers always bring new bugs to the > table. We don't do this blindly: we have selected these driver versions from June 2010 after careful examination that older drivers do cause a significant volume of crashes (we could have allowed may 2010 or even april 2010, but not much more than that, without exposing users to crashes). See bug 605780 (and the bugs blocking it) for some ATI driver crashes. For NVIDIA, see bug 605749. > > I have and old driver since ATI has discontinued supporting my > graphics card since it's an old ATI Radeon 9600 PRO Directx 9 > vertex&pixel shader version 2 but still rock solid don't cause any > issues. It would be a shame to disable the hardware acceleration for > it. Since you know these technical details, you belong to what we'd call the 'power user' category, who are able to go to about:config and force-enable acceleration features. The relevant preferences are layers.acceleration.force-enabled gfx.direct2d.force-enabled webgl.enabled_for_all_sites (soon to become webgl.force-enabled) This allows you to bypass the driver blacklist. > > Btw how can I check to see if Firefox is using the hardware > acceleration on it ? and can it be turned on if it's disabled ? about:support tells you what is enabled; see above to turn it on bypassing the blacklist.

I did switch layers.acceleration.force-enabled to true but GPU Accelerated Windows is still showing as disabled 0/1, are there any other settings that must be switched in order to make it work ? webgl.enabled_for_all_sites is set to true by default gfx.direct2d.force-enabled is set to false and I didn't try to switch it to true since Direct2D as I know works only on Win Vista or Win 7 and DX10 not on Win XP and DX9 as my configuration is. Any other advice how to enable Hardware acceleration on my Win XP DX9 ATI Radeon 9600 PRO card ?

(In reply to comment #62) > I did switch layers.acceleration.force-enabled to true but GPU Accelerated > Windows is still showing as disabled 0/1, are there any other settings that > must be switched in order to make it work ? No; if it still doesn't work it means that it's actually failing i.e. the hardware or the driver is not supporting a required feature. For example, for WebGL, you need OpenGL 2.1 + some extensions, while wikipedia says that radeon 9600 (R300) only supports OpenGL 2.0. That could explain it. For layers, I'm not sure, but some googling suggests that r300 has a max texture size of 2048x2048, and we currently require 4096x4096. Hopefully in the future we might relax this texture size requirement, allowing you to get D3D9 layers acceleration.

Well it's kind of ironic that I can play with my video card a bunch of good video games like FarCry, NFS Most Wanted and many more but can't accelerate a browser like Firefox.

Believe it or not, but the browser actually has more advanced needs on many fronts, especially WebGL. For Layers, we are considering lowering the texture size requirement, but you would then get issues when viewing very large images, these days 2048 is not hard to beat.

The graphics drivers on Windows test slaves have been upgraded, so this is now ready to land. Currently on tryserver.

As it looks now Firefox GPU hardware acceleration seems like a loosing game because the following reasons: - it works only on new drivers as I understood, how often do you think an average user updates it's drivers ? answer: an average user might not even know what a driver is, nor care, how about updating it ? it might newer update it. The actual average user splits in two categories males and females, the females are even less tech savvy if you tell them about drivers and other technical stuff they don't wanna hear about them nor care, so no updating drivers here sorry. The solution would be for those drivers that you mark them as not reliable to let the user chose if he wants to activate the GPU acceleration, then you offer 2 choices: - Activate GPU acceleration without prior testing the GPU (not recommended) - Activate GPU acceleration by testing the video card first(recommended) Then it will test the GPU like Grafx Bot extension do and find those features which are not rendered properly by the GPU then those few features that are not rendered properly by the GPU will be processed only by the CPU and the others by the GPU, big fking deal.

(troll alert. resist the urge of replying.)

> how often do you think an average user updates it's drivers? The Windows Update feature does that on Windows Vista/7 when the GPU manufacturer makes available a new driver to Microsoft (about every 6 months according to my experience). As IE 9 uses also HW acceleration, I think it is also Microsoft's interest that all users have an up-to-date graphic driver, so this period could even be shortened in the future. > The solution would be for those drivers that you mark them as not reliable to > let the user chose if he wants to activate the GPU acceleration, then you > offer 2 choices It is an interesting idea, but may be too risky to implement so close to the final release. In addition, even with the latest graphic driver, some grafxbot tests fail (lot of grafxbot bugs not fixed).

Regarding the whitelisting of only 3 major GPU makers, notice that bug 621411 provides an excellent reason why this was a good approach: it turns out that we have to blacklist VirtualBox, which shows up as a separate vendor (Oracle). So the approach of whitelisting only the big three gets us rid of any virtual machine crashes.

http://hg.mozilla.org/mozilla-central/rev/6eb16f7e331d http://hg.mozilla.org/mozilla-central/rev/faa8b3f0c677

Notice that for this, it was necessary to land also a change force-enabling graphics features in reftests and mochitests, since WinXP test slaves do not currently have up-to-date drivers (this is being worked on, too): see bug 628403.

... sorry, I mean bug 628384.

So, this is backed out? bug 629796 comment 1 seems to indicate this is the case but nothing in here talks about that.

Backed out :-( Moreover bug 628384 had to be backed out too, and the approach itself is rejected because it affects not only test slaves.

Change of approach suggested by Dustin, which should make everyone happy: let's just whitelist the combination of driver version and device ID that the test slaves have.

(In reply to comment #76) > Change of approach suggested by Dustin, which should make everyone happy: let's > just whitelist the combination of driver version and device ID that the test > slaves have. Wouldn't that enable potentially unstable code for the users who use those cards/drivers though?

Here's the new bit of code: if (adapterVendor == vendorNVIDIA && adapterDeviceID == 0x0861 && // GeForce 9400 driverVersion == V(6,14,11,7756)) { return NS_OK; } running this on tryserver...

(In reply to comment #77) > (In reply to comment #76) > > Change of approach suggested by Dustin, which should make everyone happy: let's > > just whitelist the combination of driver version and device ID that the test > > slaves have. > > Wouldn't that enable potentially unstable code for the users who use those > cards/drivers though? No and yes: No because since this is the setting we use to run tests, we know for sure that it's quite stable. Yes because there remains the fact that such old drivers tend to be more fragile in situations such as very big shaders. In any case, that is only a temporary solution. And filtering only 1 device ID and 1 driver version limits the problem a lot (NVIDIA alone has over 200 device IDs...)

(In reply to comment #79) > (In reply to comment #77) > > (In reply to comment #76) > > > Change of approach suggested by Dustin, which should make everyone happy: let's > > > just whitelist the combination of driver version and device ID that the test > > > slaves have. > > > > Wouldn't that enable potentially unstable code for the users who use those > > cards/drivers though? > > No and yes: > > No because since this is the setting we use to run tests, we know for sure that > it's quite stable. I'm stepping on the edge of my knowledge here, but I find that assertion not necessarily true. The type of code that we run in our test suites and the type of code which gets run in graphics intensive pages is almost definitely different. I'm just extrapolating the fact that the number of crashes that we get when running our test suite from the non-gfx parts of the code has no significance as far as the stability of the browser is concerned. We grather crash data from our nightly users in lieu of that. > Yes because there remains the fact that such old drivers tend to be more > fragile in situations such as very big shaders. Which is my point! > In any case, that is only a temporary solution. And filtering only 1 device ID > and 1 driver version limits the problem a lot (NVIDIA alone has over 200 device > IDs...) I'd stop nagging about this as soon as get a hard-blocking-final+ bug to revert this for final, so that it doesn't fall through the cracks. :-)

(In reply to comment #80) > > No and yes: > > > > No because since this is the setting we use to run tests, we know for sure that > > it's quite stable. > > I'm stepping on the edge of my knowledge here, but I find that assertion not > necessarily true. The type of code that we run in our test suites and the type > of code which gets run in graphics intensive pages is almost definitely > different. > > I'm just extrapolating the fact that the number of crashes that we get when > running our test suite from the non-gfx parts of the code has no significance > as far as the stability of the browser is concerned. We grather crash data > from our nightly users in lieu of that. Well it is significant to a certain extent, but not a full guarantee as you say. It is significant because the really bad (device, driver) combinations are so crashy that they could never complete a run of the reftests and WebGL mochitest without crashing. But yes, it is definitely possible for a combination to succeed on reftests and WebGL mochitest and still crash on some page, especially with WebGL. Really, WebGL allows to hit virtually any bug that an OpenGL driver may contain. More on the consequences of that below: > > > Yes because there remains the fact that such old drivers tend to be more > > fragile in situations such as very big shaders. > > Which is my point! > > > In any case, that is only a temporary solution. And filtering only 1 device ID > > and 1 driver version limits the problem a lot (NVIDIA alone has over 200 device > > IDs...) > > I'd stop nagging about this as soon as get a hard-blocking-final+ bug to revert > this for final, so that it doesn't fall through the cracks. :-) Armen said ETA February 15 for up-to-date drivers on Windows XP test slaves. We shouldn't have blocking-final bugs that can't be solved until an unknown date around February 15: that's too tight a schedule. But yes, we should definitely remove this whitelisting as soon as possible, if not for 4.0 then for 4.0.1. Let me reiterate that this is only 1 device ID and 1 driver version. Our users are spread over at least 400 device IDs and for this vendor (NVIDIA), they are spread over at least 20 driver versions. Moreover I will also restrict this to apply only to Windows XP. So if all these factors were uniformly distributed we'd be exposing 1e-4 of our users. Even if they aren't uniformly distributed, that's still a small proportion. For the exposed users, what is the risk? We know that this (device, driver) combination is decently stable, since it succeeds at the reftests and WebGL mochitest. So the risk is that users may get crashes in some nontrivial WebGL pages. That's why I claim that this doesn't have to block 4.0 and can wait for 4.0.1 if needed.

Comment on attachment 508016 [details] [diff] [review] updated to whitelist the test slave's config File a bug to back out the temporary whitelisting of our WinXP machines.

Pushed: http://hg.mozilla.org/mozilla-central/rev/983c98ba560b http://hg.mozilla.org/mozilla-central/rev/ba84db82eed5

Filed bug 629935 about removing the temporary whitelisting of the test slaves' current config.

is this included in Beta 11 ?

Yes, this will definitely be in beta 11. It's not branched yet, so it'll get all what is currently landing.

On WinXp: NVIDIA GeForce 7800 GS NVIDIA Driver: 266.58 about:support and Windows Device Manager says: Driver Version: 6.14.12.6658 My guess is that driver is bundled in NVIDIA Forceware 266.58 WHQL XP Since this bug landed in Nightly 20110130 Firefox/4.0b11pre It has disabled D3D9 Layers and Webgl even though I'm using a driver newer than 257.21 . There was no problems with D3D9 Layers or Webgl that I have experienced on Firefox 4 beta 10 or previous betas. I just glad there is still a way to override it through about:config . Set: layers.acceleration.force-enabled; to true Set: webgl.force-enabled; to true Changing those about:config pref's made it the way it was before bug 623338 landed like Firefox 4 beta 10 with D3D9 and Webgl enabled.

(In reply to comment #87) > On WinXp: > NVIDIA GeForce 7800 GS > NVIDIA Driver: 266.58 > > about:support and Windows Device Manager says: Driver Version: 6.14.12.6658 > My guess is that driver is bundled in NVIDIA Forceware 266.58 WHQL XP Oh... ok, sorry. Will make a patch ASAP (today). The driver version numbers seem to be different between Windows versions.

(In reply to comment #87) > On WinXp: > NVIDIA GeForce 7800 GS > NVIDIA Driver: 266.58 > > about:support and Windows Device Manager says: Driver Version: 6.14.12.6658 > My guess is that driver is bundled in NVIDIA Forceware 266.58 WHQL XP > > Since this bug landed in Nightly 20110130 Firefox/4.0b11pre > > It has disabled D3D9 Layers and Webgl even though I'm using a driver newer than > 257.21 . There was no problems with D3D9 Layers or Webgl that I have > experienced on Firefox 4 beta 10 or previous betas. I just glad there is still > a way to override it through about:config . > > Set: layers.acceleration.force-enabled; to true > Set: webgl.force-enabled; to true > > Changing those about:config pref's made it the way it was before bug 623338 > landed like Firefox 4 beta 10 with D3D9 and Webgl enabled. About:support also says to update my driver to use directd2 even though I'm using windows xp and they are updated (258.96) Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110130 Firefox/4.0b11pre

Here's the fix, to account for the fact that NVIDIA drivers for WinXP have different internal version numbers (starting in 6.14). Checked that Vista seems to be like Seven (8.17.x.y)

Comment on attachment 508296 [details] [diff] [review] restore nvidia on winxp Hooray NVIDIA. Can we get some confirmation that AMD/ATI's drivers aren't this way?

Pushed: http://hg.mozilla.org/mozilla-central/rev/0aefa58c9640 Let me know if you still have issues in tomorrow's nightly build.

(In reply to comment #91) > Comment on attachment 508296 [details] [diff] [review] > restore nvidia on winxp > > Hooray NVIDIA. > > Can we get some confirmation that AMD/ATI's drivers aren't this way? A confirmation would be nice indeed, but it would seem that ATI uses a very different numbering scheme compared to what NVIDIA and Intel do. NVIDIA and Intel are like a.b.c.d where only c.d is the driver version, while a.b is about the driver model (NVIDIA) or the precise (windows version, gpu generation) in the case of Intel. ATI is more like a.b.c.d where a.b gives the driver version, and c.d is some nonsense that I couldn't figure, perhaps a build number, anyway I'm putting 0.0 there.

What about Windows Server 2003 and 2008 blocklisting?

Are these server versions of Windows XP and Vista respectively? If yes, should we just map 2003 to XP and 2008 to Vista?

> Are these server versions of Windows XP and Vista respectively? Server 2003 (5.2) -> XP (5.1) Server 2008 (6.0) -> Vista (6.0) Server 2008 R2 (6.1) -> 7 (6.1) http://en.wikipedia.org/wiki/Windows_NT#Releases > If yes, should we just map 2003 to XP and 2008 to Vista? Server 2003 should be mapped to XP. Server 2008 R1 and R2 are already mapped (no difference between version numbering).

Right now the wiki at https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers#NVIDIA_cards says that NVIDIA driver version 257.21 or newer (June 2010) is required. I guess a typical WinXP buddy who looks at the driver version for his GeForce 7600 GS and get something like «6.14.11.6218» (the example is real: that's what I get there) is going to be very confused and will have absolutely no idea about how it corresponds with «257.21». There's «257.21», but then there's no «\d{3}\.\d{2}» in «6.14.11.6218».

@ Sergey: I updated the wiki to explain that.

(In reply to comment #36) > The biggest headache is of course, notebooks. Even with the latest Nvidia > 266.xx drivers, they still won't install on some notebook OEM vendors' > notebooks. > > http://www.nvidia.com/object/notebook-win7-winvista-64bit-266.35-beta-driver.html > > "Sony has joined the Verde program by supporting the following VAIO notebooks: > Sony F Series with NVIDIA GeForce 310M and Sony F Series with NVIDIA GeForce GT > 330M. Other Sony VAIO notebooks are not supported at this time (please contact > Sony for driver support)." Is there any chance that Mozilla could contact Sony about giving the O.K. to driver updates? On my VAIO VGN notebook, with an ATI Mobility Radeon HD 4570, there have been several driver updates since I purchased the computer in September 2009, but none of them were approved by Sony. I wrote an e-mail to Sony Customer support but never heard back. Quite possibly, an official communication from Mozilla to Sony will carry a good deal more weight.

Well, rather than trying that, I've done all I could to get other browsers to use the same blacklist as we do. This seems to have worked: Chrome is now requiring the exact same versions as we do for ATI and NVIDIA drivers on Windows: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/software_rendering_list.json I hope that having both Mozilla and Google consistently aligned on that will by itself build a lot of 'pressure' on OEMs to validate newer drivers. But your email to Sony Customer Support is a great initiative too, as it adds more 'pressure' from another direction (customers).

Chrome seems to blacklist NVIDIA drivers older than 2009 under Windows 7. Can't we allineate to them? So they should support, for example, the release 179.48, from 2009.02.11.

(In reply to Marco Castelluccio (Away 8-15 Sept.) from comment #103) > So they should support, for example, the release 179.48, from 2009.02.11. Old versions of NVIDIA drivers were crashy. See comment 33.

The problem is that many notebook graphics cards are stuck with version 179, also if they are more or less the same as desktop graphics cards that instead are supported by version 280. We use ANGLE just as Chrome, so if they don't block these cards, we should do the same, at least for WebGL.

(In reply to Marco Castelluccio (Away 8-15 Sept.) from comment #105) > The problem is that many notebook graphics cards are stuck with version 179, > also if they are more or less the same as desktop graphics cards that > instead are supported by version 280. > We use ANGLE just as Chrome, so if they don't block these cards, we should > do the same, at least for WebGL. No, just because Chrome makes a certain compromise doesn't mean we should do the same. We made a conscious decision here to be conservative with these new Graphics features. Moreoever, we know very concrete reasons why we must blacklist NVIDIA drivers older than 257.21 on certain NVIDIA hardware like Optimus where older drivers were giving severe slowness (bug 596144). At least on this class of NVIDIA cards, our decision is the right one. One may wish that we had a finer blacklisting logic able to require different driver versions for different classes of GPUs within a given vendor, but that would require more manpower to maintain than we have. For that matter, Chrome's blacklist is coarser, not finer, than outs.

The problem is only with the Geforce Go 7 Series that in Windows is supported by video driver 179.48 and instead in Linux and FreeBSD by 280.13 (this is somewhat confusing, never seen NVIDIA supporting better Linux than Windows!). So I think it shouldn't be a problem for NVIDIA to update this driver (as for example 280 is used also by Geforce 6 Series...). Not supporting these graphics cards, we aren't supporting a lot of notebook users. I'll ask the NVIDIA technical support.

A user who is technical enough to know this... is also technical enough to force-enable ;-) https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers#How_to_force-enable_blocked_graphics_features

(In reply to Marco Castelluccio (Away 8-15 Sept.) from comment #107) > The problem is only with the Geforce Go 7 Series that in Windows is > supported by video driver 179.48 and instead in Linux and FreeBSD by 280.13 > (this is somewhat confusing, never seen NVIDIA supporting better Linux than > Windows!). Yes, but the newer driver itself still supports the older GPUs even on Windows, so with a modified "Setup Information file" (INF) which you can get from sites like laptopvideo2go you users of these GPUs can also use newer drivers. Still, they won't get D2D because these old GPUs don't support WDDM 1.1.