600194 - D2D is disabled on Minefield 32-bit and enabled on Minefield 64-bit with Intel GMA 4500MHD

Status: VERIFIED FIXED

(Core :: Graphics, defect)

Description

[Scoobidiver (away)]

Build : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b7pre) Gecko/20100928 Firefox/4.0b7pre

Since b7pre/20100928 build, D2D is disabled on Minefield 32-bit (new profile).
It is enabled on Minefield 64-bit.

Adapter Description : Mobile Intel(R) 4 Series Express Chipset Family
Vendor ID : 8086
Device ID : 2a42
Adapter RAM : Unknown
Adapter Driver : sigdumd64 igd10umd64 igdumdx32 igd10umd32
Driver Version : 8.15.10.2202
Driver Date : 8-25-2010
Direct2D Enabled : false
DirectWrite Enabled : false
GPU Accelerated Windows : 1/1 Direct3D 9

DeviceID is not blacklisted and driver version is the latest one.

The regression range is :
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6272ce1da6f5&tochange=c257bfb8cad0
It could be caused by bug 595364 or bug 594976 fixes.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

I'll boot in windows and try to make firefox believe I have your card and will try to reproduce...

Comment 2

[Bas Schouten (:bas.schouten)]

Does about support report something different in 32-bit than in 64-bit?

Comment 3

[Scoobidiver (away)]

> Does about support report something different in 32-bit than in 64-bit?
It is identical except Direct2D and DirectWrite fields that are set to true in 64-bit.

Comment 4

[Scoobidiver (away)]

I suspected a mess up in the partial update.
So I moved 32-bit and 64-bit minefield directories in back-up directories (I did not backup the registry keys).
I made a complete installation of 32-bit and 64-bit minefield.
The comparison between the current and backup directories shows no difference except the install log file.
The 2 issues remain.

Comment 5

[Benoit Jacob [:bjacob] (mostly away)]

Actually, we were not even listing this device among Intel devices at all... so need at least to fix this. But that makes it rather surprising that your device would have been blacklisted.

Comment 6

[Benoit Jacob [:bjacob] (mostly away)]

So, I had another look at the code, and since we were not even currently listing this card, I believe that the bug is NOT in the blocklist... 

I'm rather suspecting the rest of the code in gfx/thebes/gfxWindowsPlatform.cpp.

What would help would probably to set a breakpoint at the beginning of gfxWindowsPlatform::UpdateRenderMode() in that file, and step through it. It will go over the blocklist, then eventually in VerifyD2DDevice()... if VerifyD2DDevice sets mD2DDevice to null, you'll know that the problem is there.

Comment 7

[Scoobidiver (away)]

> Actually, we were not even listing this device among Intel devices at all...
GfxInfo.cpp :
459 static const PRUint32 deviceFamilyIntelGMAX4500HD[] = {
460     0x2A42, /* IntelGMA4500MHD_1 */
461     0x2A43, /* IntelGMA4500MHD_2 */

> I'm rather suspecting the rest of the code in gfx/thebes/gfxWindowsPlatform.cpp.
In the regression range, gfxWindowsPlatform.cpp has not been modified.
It is GfxInfo.cpp that was modified by bug 595364 : http://hg.mozilla.org/mozilla-central/rev/e619706a27d7. I think these 2 changes causes the issue :
     1.7 -static const nsresult GetKeyValue(const WCHAR* keyLocation, const WCHAR* keyName, nsAString& destString, int type)
     1.8 +static nsresult GetKeyValue(const WCHAR* keyLocation, const WCHAR* keyName, nsAString& destString, int type)
    1.16 -static const void normalizeDriverId(nsString& driverid) {
    1.17 +static void normalizeDriverId(nsString& driverid) {

Comment 8

[Benoit Jacob [:bjacob] (mostly away)]

(In reply to comment #7)
> > Actually, we were not even listing this device among Intel devices at all...
> GfxInfo.cpp :
> 459 static const PRUint32 deviceFamilyIntelGMAX4500HD[] = {
> 460     0x2A42, /* IntelGMA4500MHD_1 */
> 461     0x2A43, /* IntelGMA4500MHD_2 */


Ouch! Sorry, I'm tired.

> I think these 2 changes
> causes the issue :
>      1.7 -static const nsresult GetKeyValue(const WCHAR* keyLocation, const
> WCHAR* keyName, nsAString& destString, int type)
>      1.8 +static nsresult GetKeyValue(const WCHAR* keyLocation, const WCHAR*
> keyName, nsAString& destString, int type)
>     1.16 -static const void normalizeDriverId(nsString& driverid) {
>     1.17 +static void normalizeDriverId(nsString& driverid) {

How could that possibly be? Const on (non-reference) return type is ignored anyway (LLVM even has a warning about that)

Comment 9

[Benoit Jacob [:bjacob] (mostly away)]

I had just accidentally added these const keywords, anyway.

Comment 10

[Benoit Jacob [:bjacob] (mostly away)]

Anyway thanks for noting that we do list 2A42. I'll try reproducing ASAP but that will have to be tomorrow.

Comment 11

[Benoit Jacob [:bjacob] (mostly away)]

OOHH I know. Indeed http://hg.mozilla.org/mozilla-central/rev/e619706a27d7 has a severe bug: the device list is NOT zero-terminated as it should be !! Resulting in undefined behavior. What happens next is that in this data segment where our static constants live, right after it comes the 4500/HD device list (it's right after it in the source code). So the blocklist implementation runs over the end of that array and goes on in the 4500/HD device list.

Anyway the patch that I'm about to push fixes it.

Comment 12

[Benoit Jacob [:bjacob] (mostly away)]

Pushed: http://hg.mozilla.org/mozilla-central/rev/b07c0925efe5

Please confirm if this fixes it.

Comment 13

[Scoobidiver (away)]

It is fixed in b7pre/20100928 build.