Last Comment Bug 628129 - Make GPU blacklisting logic aware of dual GPU systems
: Make GPU blacklisting logic aware of dual GPU systems
Status: NEW
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: x86 Windows 7
: -- normal with 10 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Milan Sreckovic [:milan]
Mentors:
: 718919 (view as bug list)
Depends on: 675962 724874 591057 679110
Blocks: 601079 635464 667437 668008 784645 839820 1056116 590373 596144
  Show dependency treegraph
 
Reported: 2011-01-23 07:45 PST by Scoobidiver (away)
Modified: 2015-09-13 01:31 PDT (History)
25 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
handle dual GPUs on Windows (19.16 KB, patch)
2011-07-07 13:35 PDT, Ali Juma [:ajuma]
jmuizelaar: review-
Details | Diff | Splinter Review
300zoombug.png (241.09 KB, image/png)
2015-09-13 01:28 PDT, bull500
no flags Details
nobug300.png (320.87 KB, image/png)
2015-09-13 01:31 PDT, bull500
no flags Details

Description Scoobidiver (away) 2011-01-23 07:45:50 PST
Dual video cards (ATI/Intel or NVIDIA/Intel pair) become more and more common.
The computer manufacturer builds the graphic driver using the one from ATI (or NVIDIA) and the one from Intel. But, it shows only the ATI (or NVIDIA) graphic driver version. It can be confusing when the primary video card is Intel.
See:
https://bugzilla.mozilla.org/show_bug.cgi?id=599661#c0 (ATI as primary graphics)
https://bugzilla.mozilla.org/show_bug.cgi?id=599661#c4 (Intel as primary graphics)

Bug 590373 introduced a check between the driver and igd10umd32.dll versions that blocks the HW acceleration when Intel is the primary video card at Firefox launch.

To enable the HW acceleration if there are dual video cards:
* detect if there are several video cards.
* show them all in about:support and crash reports app notes.
* use the igd10umd32.dll version (on Windows Vista, 7) to determine the driver version of Intel card instead of DriverVersion read from the registry (patch of bug 590373 will become useless)
* enable the D2D/D3D feature only if all video cards are not blocklisted for this feature.
Comment 1 Benoit Jacob [:bjacob] (mostly away) 2011-01-23 08:01:56 PST
The check introduced in bug 590373 only takes place when the VendorID is intel. So there only is a check at all when the primary GPU is Intel.

In this case, the check checks that the Intel DriverVersion from the registry is equal to the igd10umd{32,64}.dll version, i.e. it's a basic check that the Intel driver is correctly installed. Again, since that check is only performed when the VendorID is intel, I don't think that there's any risk that it would get confused by dual-GPU setups (comparing ATI driver version to Intel DLL version).

So I think that HW acceleration is still enabled with dual video cards.

Would you agree with renaming this bug from "Enable HW acceleration with dual video cards" to "Make GPU blacklisting logic aware of dual GPU systems".

I am a bit in the fuzzy still about how dual GPU systems behave. Can it be that the GPU changes under our feet at any time?
Comment 2 Scoobidiver (away) 2011-01-23 08:36:51 PST
> The check introduced in bug 590373 only takes place when the VendorID is intel.
> So there only is a check at all when the primary GPU is Intel.
The "primary" term is probably inadequate, I should use "used".
If you look at https://bugzilla.mozilla.org/show_bug.cgi?id=599661#c4, the VendorId is Intel and the DriverVersion from the registry is equal to 8.641.1.1000, which is not at all an Intel driver version numbering, because it is the ATI one.
So the check introduced by bug 590373 compares 8.641.1.1000 with 8.15.10.2202, which is not equal and, as a consequence, blocks the D2D/D3D feature.
Comment 3 Scoobidiver (away) 2011-02-07 13:30:19 PST
I consider the D2D blocklisting for all dual GPUs as blocking.
Comment 4 Benoit Jacob [:bjacob] (mostly away) 2011-02-07 13:36:36 PST
Do we have data showing that we have many graphics driver crashes on dual-GPU systems? I would only block 2.0 if that is the case.
Comment 5 Scoobidiver (away) 2011-02-08 01:57:08 PST
> Do we have data showing that we have many graphics driver crashes on dual-GPU
> systems?
From the fixing of bug 590373, all dual GPUs are blocklisted for D2D preventing around 10% of all users to use HW acceleration although they have compatible GPUs and required graphics driver versions.
I am asking to D2D-unblock dual GPUs with required graphics driver versions.
Comment 6 Benoit Jacob [:bjacob] (mostly away) 2011-02-08 04:34:36 PST
(In reply to comment #5)
> > Do we have data showing that we have many graphics driver crashes on dual-GPU
> > systems?
> From the fixing of bug 590373, all dual GPUs are blocklisted for D2D preventing
> around 10% of all users to use HW acceleration although they have compatible
> GPUs and required graphics driver versions.
> I am asking to D2D-unblock dual GPUs with required graphics driver versions.

Sorry, I forgot about the issue of _potentially_ mistakenly blocking users of dual GPU systems.

Do we have any evidence that we are really blocking _all_ of them? My understanding is that they were only potentially blocked, that is, I thought that we were at worst blocking a minority of them.

Indeed,
http://mxr.mozilla.org/mozilla-central/source/widget/src/windows/GfxInfo.cpp#360

this code basically says:

"if the driver vendor in windows registry is Intel,
 and the driver version in windows registry is different from
     the Intel DLL version,
 then block D3D10/D2D features."

So the only ways that this can block users, are:
 1. if the windows registry is broken, in that it gives the Intel vendor ID and the non-Intel DriverVersion.
 2. if the Intel driver is incorrectly installed, in that the Intel DriverVersion from the registry is different from the Intel DLL version.

In both cases, the user's system is broken, so I don't think that we do a wrong thing by blocking it?

Am I missing something? Is there a way for correctly installed dual-GPU setups to get incorrectly blacklisted here?
Comment 7 Benoit Jacob [:bjacob] (mostly away) 2011-02-08 04:39:42 PST
(In reply to comment #2)
> > The check introduced in bug 590373 only takes place when the VendorID is intel.
> > So there only is a check at all when the primary GPU is Intel.
> The "primary" term is probably inadequate, I should use "used".
> If you look at https://bugzilla.mozilla.org/show_bug.cgi?id=599661#c4, the
> VendorId is Intel and the DriverVersion from the registry is equal to
> 8.641.1.1000, which is not at all an Intel driver version numbering, because it
> is the ATI one.

Oh! ok. I should have read that again.

OK, that's what I called case 1. in comment 6.

Is that legitimate? In this case, the Windows registry is self-contradictory. It reports the Intel VendorId and the non-Intel DriverVersion. Is that really how dual GPU systems are supposed to behave, or is that just a bug? I mean, it really looks like a bug, and one that compromise basic sanity of the windows registry. Should we really go out of our way to still enable hw accel on such a system? Do we have data showing that this happens on a lot of dual GPU systems?
Comment 8 Scoobidiver (away) 2011-02-08 05:54:59 PST
> Is that really how dual GPU systems are supposed to behave, or is that just a
> bug?
I think so. There is only one driver version and the vendorID changed according to the used GPU.

> Do we have data showing that this happens on a lot of dual GPU systems?
Now we have the driver version in crash reports, I think it is easy to check in 4.0b10 crash stats the percentage of Intel GPUs that have a driver version pattern 8.abc.y.z (ATI one) or 8.17.ab.cd (NVIDIA one) wrt to all Intel GPUs on Windows Vista/7.
Comment 9 Mike Beltzner [:beltzner, not reading bugmail] 2011-02-08 13:23:36 PST
Sad, but not a blocker.
Comment 10 Scoobidiver (away) 2011-02-10 06:00:16 PST
Using the Intel attached file in bug 623317, I found that there is 0.4% (resp. 0.1%) of crash reports that has an ATI (resp. NVIDIA) driver version with an Intel GPU on Windows Vista/7.
Comment 11 Theo 2011-06-19 18:36:55 PDT
Please kindly consider raising the status of this bug.

I have a new Dell Alienware M11x-R3 - popular, not expensive Core i7 dual-gpu gaming computer. Allows me to switch to Intel gpu when on battery. Nice for longer battery life. My guess is that this type of configuration will become quite popular this year.

No matter what settings I have in about:config I cannot get Nvidia gpu to load on FF 4.0.1 or 5 beta.

Chrome uses Nvidia without issue or crashes. So I am doing all my WebGL on Chrome. But would prefer using FF...
Comment 12 Benoit Jacob [:bjacob] (mostly away) 2011-06-28 06:42:07 PDT
I agree now that we should prioritize this bug. Bug 667437 shows that failing to detect dual GPUs makes us hit bug 635044 i.e. we fail to disable layers on NVIDIA NVS 3100M as we should.
Comment 13 Benoit Jacob [:bjacob] (mostly away) 2011-06-28 06:44:19 PDT
@ Theo, you an manually enable/disable features by going to about:config
https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers#How_to_force-enable_blocked_graphics_features
Comment 14 Theo 2011-06-28 09:55:28 PDT
@ Benoit

Thank you. Yes, I have been to that page. I just did not want to bore you with all my failures.

I have tried most every permutation of settings that appear when you search on "webgl" in about:config - including: webgl.force-enabled=true

I have also in:

Nvidia Control Panel > Manage 3D Settings > set Nvidia as the preferred graphics processor for FF.

Here is the interesting new thing:

The last time I diddled with all the webgl settings (over a week ago) all I would get is a silent fail. There was no "your computer does not support webGL" message nor did the display show anything.

The new thing (with 5.0 beta) is that when I set webgl.force-enabled=true FF really does crash.

Here is what about:support says:

Adapter Description Intel(R) HD Graphics Family
Vendor ID8086
Device ID0116
Adapter RAM Unknown
Adapter Drivers igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32Driver Version 8.15.10.2342
Driver Date3-25-2011
Direct2D Enabled true
DirectWrite Enabled true (6.1.7601.17563, font cache n/a)
WebGL Renderer Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.611)
GPU Accelerated Windows 1/1 Direct3D 10

So FF still seems to be using the Intel graphics processor. 

Another thing I notice in about:config is this:

gfx.blacklist.webgl.angle is set to 3.

**

I hope this helps. Feel free to ask for more data.

Please forgive me for writing this message using Chrome - because of all the crashes verifying what I am saying in this message...
Comment 15 Benoit Jacob [:bjacob] (mostly away) 2011-06-28 12:01:14 PDT
Interesting; I have no idea how to force Firefox to use the Optimus cards instead of the Intel one, but we should look into that. Your crash is probably in the Intel OpenGL driver (a crash link would allow to confirm that). The reason why you have gfx.blacklist.webgl.angle is because ANGLE is blacklisted on Optimus and some time in the past your Optimus card was used. Caching this blacklisting decision only makes the situation more complicated, bug 653102 is about fixing that.
Comment 16 Theo 2011-06-28 19:25:26 PDT
@ Benoit

>>  I have no idea how to force Firefox to use the Optimus cards instead of the Intel one, but we should look into that.

Yes, please! Yes.

>> a crash link would allow to confirm that

I'm too new here to know if there is a preferred way of doing this. Anyway: here is a crash log pasted into a Google Doc.

http://goo.gl/eXAET
Comment 17 Joe Drew (not getting mail) 2011-06-28 19:30:57 PDT
Theo, if you go to about:crashes in your browser, you will see a bunch of links with names like bp-1f30c477-3ba3-4b38-9829-26cdb2110628. If you just copy those names into Bugzilla, it's smart enough to link them to the crash report Firefox submitted for you.
Comment 18 Theo 2011-06-28 20:20:12 PDT
@ Joe

Cool!

So here are the links from today:
    
bp-0e0d7579-2e45-46bd-8699-8ffc72110628 6/28/20118:14 PM
bp-d1a5be37-8ed4-49bf-b171-9a27e2110628 6/28/20117:30 PM
bp-d59ad722-572e-442a-98b7-5dc952110628 6/28/20119:26 AM
bp-fad78e6b-ce98-46a8-a43f-2db2c2110628 6/28/20119:17 AM
bp-bef46150-8f34-4c2d-89d8-48c0a2110628 6/28/20119:15 AM
bp-4b2f46db-baf9-4dcd-a9cf-5d13a2110628 6/28/20119:14 AM
bp-fd533ca5-8d13-412f-b49e-9ec7e2110628 6/28/20118:49 AM
bp-1d670872-028d-48b3-916b-786602110628 6/28/20118:49 AM
Comment 19 Ali Juma [:ajuma] 2011-07-07 13:35:26 PDT
Created attachment 544601 [details] [diff] [review]
handle dual GPUs on Windows

This patch checks the Windows registry for the presence of dual GPUs. If dual GPUs are present:
-D3D9 is used to determine which GPU is active
-the blacklisting logic is applied to the active GPU
-both the active and inactive GPUs are listed in about:support and in crash reports
Comment 20 Theo 2011-07-07 14:34:01 PDT
@ Ali

This is cool. 

If I am reading your patch correctly, your code is the first step in solving the problem.

It identifies dual GPU systems, and blacklists those with issues, but it does not change the way that Firefox passes data in and out of the GPUs. 

Am I right in thinking this is just the first [and necessary] step in solving the problem? 

In any case, thank you for getting the ball rolling.
Comment 21 Ali Juma [:ajuma] 2011-07-07 14:45:21 PDT
@ Theo

The code determines which GPU Firefox is really using, and then proceeds accordingly (that is, enables/disables features in the same way we would if the active GPU was the only GPU).

This is indeed a first step, in the sense that we still need to test this logic against a large number of dual GPU systems to see if there are other quirks that need to be taken into account.
Comment 22 Jeff Muizelaar [:jrmuizel] 2011-07-26 11:04:46 PDT
Comment on attachment 544601 [details] [diff] [review]
handle dual GPUs on Windows

Review of attachment 544601 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/public/nsIGfxInfo.idl
@@ +67,4 @@
>    
>    readonly attribute unsigned long adapterDeviceID;
> +  readonly attribute unsigned long adapterDeviceID2;
> +

We should eventually switch to a list of devices instead of numbering them explicitly. You should add a comment to say this.

::: widget/src/windows/GfxInfo.cpp
@@ +215,5 @@
> +  temp = aFirst;
> +  aFirst = aSecond;
> +  aSecond = temp;
> +}
> +

You should be able to use algorithm::swap here.

@@ +253,5 @@
> +    Swap(mDeviceID, mDeviceID2);
> +    Swap(mAdapterVendorID, mAdapterVendorID2);
> +    Swap(mAdapterDeviceID, mAdapterDeviceID2);
> +  } 
> +}

I worry that this information might not match what we get if we use D3D10 instead of D3D9. Are you sure using D3D9 will always give us the right information?

@@ +466,5 @@
>                  mDriverDate = value;
> +              RegCloseKey(key); 
> +
> +              //Check for second adapter.
> +              if (driverKey[driverKey.Length()-1] == '0') {

What if driverKey.Length() ends up being 0?

@@ +470,5 @@
> +              if (driverKey[driverKey.Length()-1] == '0') {
> +                driverKey.SetCharAt('1', driverKey.Length()-1);
> +              } else {
> +                driverKey.SetCharAt('0', driverKey.Length()-1);
> +              }

Can you add a higher level comment about what's happening here? Are you trying to swap a '0' and '1'?
Comment 23 Ali Juma [:ajuma] 2011-07-26 11:20:50 PDT
> I worry that this information might not match what we get if we use D3D10
> instead of D3D9. Are you sure using D3D9 will always give us the right
> information?

No, I'm not sure that D3D9 will always be right, but I'm not also not sure if there's a good way to resolve this question. Is D3D10 likely to be a better starting point for this?
Comment 24 Ali Juma [:ajuma] 2011-07-28 08:42:02 PDT
Given the uncertainty we have about the information we get from D3D9 (e.g. can we be certain that D3D9 and D3D10 will always get the same GPU), I've created a revised version of Attachment 544601 [details] [diff] that doesn't change the blacklisting logic for now -- see Attachment 549122 [details] [diff], bug 591057.
Comment 25 michaelbraithwaite 2011-11-03 05:36:10 PDT
I downloaded the source for Firefox 8.0b6 and was looking at the current dual GPU logic detection in GfxInfo.cpp and it appears to be incorrect for my system.

I was attempting to integrate the logic in to an older version of the GfxInfo.cpp file of the file but debugging through shows this to be an incorrect assumption:-

>>>
 GfxInfo::Init()
...
              // Check for second adapter:
              //
              // A second adapter will have the same driver key as the first adapter except for 
              // the last character, where '1' will be swapped for '0' or vice-versa.
              // We know driverKey.Length() > 0 since driverKeyPre is a prefix of driverKey.
              if (driverKey[driverKey.Length()-1] == '0') {
                driverKey.SetCharAt('1', driverKey.Length()-1);
              } else {
                driverKey.SetCharAt('0', driverKey.Length()-1);
              }

<<<

My Windows7 system has had various cards installed in it with various updates of drivers. At the moment it just has a single ATI 6800 in it.

The code correctly identifies this as the primary adaptor. However the reg key for it is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0003

Under 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}

there are two other keys \0000 for an ATI HD 5800 and \0001 for an HD 5700, neither of which are in installed.

So the code picks \0000 and thinks it has two ATI cards in.


I downloaded FF Aurora 9.0a2 (2011-11-02) and about:support also incorrectly list two cards:
>>>
Graphics

        Adapter Description
        AMD Radeon HD 6800 Series

        Vendor ID
        1002

        Device ID
        6739

        Adapter RAM
        1024

        Adapter Drivers
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Driver Version
        8.892.0.0

        Driver Date
        9-8-2011

        Adapter Description (GPU #2)
        ATI Radeon HD 5800 Series

        Vendor ID (GPU #2)
        1002

        Device ID (GPU #2)
        6899

        Adapter RAM (GPU #2)
        1024

        Adapter Drivers (GPU #2)
        aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64

        Driver Version (GPU #2)
        8.892.0.0

        Driver Date (GPU #2)
        9-8-2011

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17563)

        ClearType Parameters
        ClearType parameters not found

        WebGL Renderer
        Google Inc. -- ANGLE (AMD Radeon HD 6800 Series) -- OpenGL ES 2.0 (ANGLE 0.0.0.740)

        GPU Accelerated Windows
        1/1 Direct3D 10
<<<
Comment 26 Ali Juma [:ajuma] 2011-11-03 14:32:25 PDT
(In reply to michaelbraithwaite from comment #25)
> I downloaded the source for Firefox 8.0b6 and was looking at the current
> dual GPU logic detection in GfxInfo.cpp and it appears to be incorrect for
> my system.

Thanks for the report. As you demonstrate, the approach of swapping '0' for '1' in the driver key is indeed flawed. Bug 679110, Attachment 571775 [details] [diff] replaces this approach with enumerating devices in the display adapter device interface class.
Comment 27 Theodore 2012-01-18 07:48:03 PST
*** Bug 718919 has been marked as a duplicate of this bug. ***
Comment 28 gader 2012-02-01 14:57:16 PST
Also integrated single GPU intel card (2a02&2a03) looks like dual GPU on about:support.
Comment 29 Scoobidiver (away) 2012-02-01 15:00:51 PST
(In reply to gader from comment #28)
> Also integrated single GPU intel card (2a02&2a03) looks like dual GPU on
> about:support.
Not in Aurora and Nightly.
Comment 30 bull500 2015-09-13 01:28:29 PDT
Created attachment 8660406 [details]
300zoombug.png

I encountered a font rendering problem on both Firefox 41.0b9 and Nightly 43.0a1 (2015-09-12) on this webpage - http://www.xda-developers.com/hello-moto-what-are-you-doing-an-opinion-on-motorolas-transformations/  

Apparently the issue seems to caused because DirectWrite isn't enabled on both these Firefox versions.
about:support Graphics Section says:
Direct2D Enabled	Blocked for your graphics driver version.
DirectWrite Enabled	false (6.2.9200.17461)


It was fixed by enabling these two option in about:config on Firefox 41.0b9
gfx.direct2d.force-enabled - true
gfx.font_rendering.directwrite.enabled - true (Nightly 43 doesn't have this option but works by enabling the other)

about:support Graphics Section now says:
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.17461)


Dual GPU Details:
Adapter Description	        Intel(R) HD Graphics Family
Adapter Description (GPU #2)	NVIDIA GeForce GT 525M 
Driver Date	                4-10-2011
Driver Date (GPU #2)	        7-22-2015
Driver Version	                8.15.10.2361
Driver Version (GPU #2)	        10.18.13.5362

Was lucky to have stumbled upon this page where i got the solution to the problem -https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers

I feel DirectWrite needs to be enabled for Dual-GPU systems because almost all new laptops come on a Dual GPU model.  
Lots of users could potentially miss out on good font rendering and be served with inferior quality font rendering.

Until i visited the xda page I had no clue that this was happening. But after figuring out this issue with the about:config settings, i disabled them and when back to my commonly used site and was surprised this wasn't visible because most webpages used small fonts on their pages. Zooming into the page clearly reveals the flaws on popular sites like reddit.com etc.  

Attachment is zoomed in to 300% to show the flaws. Happens on standard zoom as well. Left is Firefox.
Comment 31 bull500 2015-09-13 01:31:08 PDT
Created attachment 8660407 [details]
nobug300.png

This is after force-enabling the two settings. Both the browser look the same and with much improved font rendering all round.

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