1065212 - Stop using the Windows registry to get graphics system information

Status: NEW

(Core :: Graphics, defect)

Description

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

Our entire graphics blacklisting system (GfxInfo) on Windows relies on the Windows registry as its primary data source. That's been unreliable and a source of pain for years now. For example:

 1. Mis-detection of dual-GPU systems causing crashes, bug 1008759, e10s blocker.
 2. Mis-detection of Intel driver version causing crashes, bug 1063048, firefox 32 chemspill driver.
 3. Mis-detection of Intel driver version being the leading cause of unnecessarily blacklisting Direct3D 10 features, depriving users of perfectly capable systems from useful features such as fast WebGL compositing. Bug 984417.

Our mitigation for crashes such as 2. has been to also query the same information from a more reliable source (like getting the driver version from the version field of the driver DLL) and blacklisting if a mismatch is found. See "DriverVersionMismatch" in the appnotes field of crash reports.

That's poor, doesn't help with other types of crash such as 1., and causes excessive blacklisting as in 3.

Note that Intel users are 60% of our total users,

  http://people.mozilla.org/~bjacob/gfx_features_stats/#desktop-gpu-vendor-market-share

and note that as we studied in bug 984417, "DriverVersionMismatch" accounts for the majority of the cases where we blacklist Direct3D 10+ features there.

So there is a big problem here. This bug descriptions sticks to describing the problem. The next comment will propose a possible avenue to fixing this.

Comment 1

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

Possible way to fix this: do like we've been doing for 3 years on desktop linux: on startup, in a separate thread or process (that detail is up for discussion), go ahead and create a Direct3D device (equivalent of a OpenGL context) and query it. In this way, we would get for-real renderer information from the renderer itself. The downsides are 1) it could slow startup down (which is why we'd do it at least in a separate thread), 2) it could be crashy (which is why we could do it in a separate process like we do on linux), and 3) it is more code complexity (although the current registry-based approach is a headache too; and we already have similar logic on linux).

Comment 2

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

Another approach is to only stop using the Windows registry to get the driver version, where we know a more reliable way to get that information, as described above --- from the driver DLL directy --- while continuing to use the registry to get other information such as device/vendor ID which we might not know another way to get.

Yet another approach to this bug might be to ask if we are just using the Windows registry wrong e.g. just getting the first-returned value in a list instead of properly examining the entire list.