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

VERIFIED FIXED

Status

()

VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: scoobidiver, Unassigned)

Tracking

Trunk
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

(Reporter)

Description

8 years ago
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.
blocking2.0: --- → ?
I'll boot in windows and try to make firefox believe I have your card and will try to reproduce...
Does about support report something different in 32-bit than in 64-bit?
(Reporter)

Comment 3

8 years ago
> 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.
(Reporter)

Comment 4

8 years ago
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.
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.
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.
(Reporter)

Comment 7

8 years ago
> 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) {
(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)
I had just accidentally added these const keywords, anyway.
Anyway thanks for noting that we do list 2A42. I'll try reproducing ASAP but that will have to be tomorrow.
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.
(Reporter)

Updated

8 years ago
Depends on: 595364
(Reporter)

Comment 13

8 years ago
It is fixed in b7pre/20100928 build.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Reporter)

Updated

8 years ago
Status: RESOLVED → VERIFIED
blocking2.0: ? → -
Keywords: regression
You need to log in before you can comment on or make changes to this bug.