Nightly is unusable with direct2d enabled

RESOLVED FIXED in Firefox 33

Status

()

defect
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: standard8, Assigned: mattwoodrow)

Tracking

(Blocks 1 bug)

Trunk
mozilla34
All
Windows 7
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox30 unaffected, firefox31 unaffected, firefox32- unaffected, firefox33+ fixed, firefox34 fixed)

Details

Attachments

(2 attachments)

Reporter

Description

5 years ago
On my Windows machine - a Lenovo W520 ThinkPad running Windows 7, the display is totally messed up if I run the latest nightly builds - the toolbars are blank and the wrong size, and the main display is black.

As a result it is completely unusable for me.

I'll attach a screenshot in a moment.

Regression range:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/05/2014-05-20-03-02-02-mozilla-central/
to
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/05/2014-05-21-03-02-00-mozilla-central/

Which equates to:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb9f34f73ebe&tochange=9d8d16695f6a
Reporter

Comment 1

5 years ago
Posted image Broken Firefox
I'm guessing this is caused by enabling OMTC but it would be good to confirm that. Can you flip the pref (layers.offmainthreadcomposition.enabled) to see if that fixes things?
Blocks: 899785
Reporter

Comment 3

5 years ago
Here's my Graphics info from about:troubleshooting, running in the broken version (2014-05-21) in safe mode.

Graphics
--------

Adapter Description: Intel(R) HD Graphics Family
Adapter Description (GPU #2): NVIDIA Quadro 1000M
Adapter Drivers: igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32
Adapter Drivers (GPU #2): nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Adapter RAM: Unknown
Adapter RAM (GPU #2): 2048
Device ID: 0x0126
Device ID (GPU #2): 0x0dfa
DirectWrite Enabled: false (6.2.9200.16571)
Driver Date: 3-6-2011
Driver Date (GPU #2): 5-25-2011
Driver Version: 8.15.10.2321
Driver Version (GPU #2): 8.17.12.6871
GPU #2 Active: false
GPU Accelerated Windows: 0/1 Basic (OMTC)
Vendor ID: 0x8086
Vendor ID (GPU #2): 0x10de
WebGL Renderer: Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
Reporter

Comment 4

5 years ago
(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)
> I'm guessing this is caused by enabling OMTC but it would be good to confirm
> that. Can you flip the pref (layers.offmainthreadcomposition.enabled) to see
> if that fixes things?

Yes, flipping the pref fixes it.
Version: 27 Branch → Trunk
Does just flipping layers.direct2d.disabled to true ( reverting layers.offmainthreadcomposition.enabled) fix the issue for you?
Reporter

Comment 6

5 years ago
(In reply to Bas Schouten (:bas.schouten) from comment #5)
> Does just flipping layers.direct2d.disabled to true ( reverting
> layers.offmainthreadcomposition.enabled) fix the issue for you?

Yes, toggling either of those prefs works.
How about updating your driver?
Reporter

Comment 8

5 years ago
Sorry for the delayed response.

I've just updated to NVIDIA Quadro 1000M driver 9.18.13.3311 (Dated 29 April 2014) - from their website, not available by "update driver", and still get the same issue.

There's an Intel(R) HD Graphics Family device at version 8.15.10.2321 (6th March 2011) but that says it is up to date, and I don't know where I'd find a new one of those.
Reporter

Comment 9

5 years ago
(In reply to Mark Banner (:standard8) from comment #8)
> Sorry for the delayed response.
> 
> I've just updated to NVIDIA Quadro 1000M driver 9.18.13.3311 (Dated 29 April
> 2014) - from their website, not available by "update driver", and still get
> the same issue.
> 
> There's an Intel(R) HD Graphics Family device at version 8.15.10.2321 (6th
> March 2011) but that says it is up to date, and I don't know where I'd find
> a new one of those.

Bas, is that enough info, or have I missed a different driver somewhere?
Flags: needinfo?(bas)
(In reply to Mark Banner (:standard8) from comment #9)
> (In reply to Mark Banner (:standard8) from comment #8)
> > Sorry for the delayed response.
> > 
> > I've just updated to NVIDIA Quadro 1000M driver 9.18.13.3311 (Dated 29 April
> > 2014) - from their website, not available by "update driver", and still get
> > the same issue.
> > 
> > There's an Intel(R) HD Graphics Family device at version 8.15.10.2321 (6th
> > March 2011) but that says it is up to date, and I don't know where I'd find
> > a new one of those.
> 
> Bas, is that enough info, or have I missed a different driver somewhere?

Try the drivers here, it's generally lying with Intel when it says it's up to date.

https://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Graphics&ProductLine=Laptop+graphics+drivers&ProductProduct=3rd+Generation+Intel%C2%AE+Core%E2%84%A2+Processors+with+Intel%C2%AE+HD+Graphics+4000&ProdId=3712&LineId=1101&FamilyId=39
Flags: needinfo?(bas)
We will likely turn off OMTC in Aurora by June 27th, but I'd like to track this as we can't really ship this kind of regression either way.
Reporter

Comment 12

5 years ago
I've tried updating the intel driver from the website, but it says I can't install it due to having a custom driver already installed.

So I took a look on getting an update from Lenovo, and the only graphics driver they had updated the NVIDIA driver but not the intel one :-( The relevant lines now look like:

Driver Date: 3-6-2011
Driver Date (GPU #2): 10-28-2013
Driver Version: 8.15.10.2321
Driver Version (GPU #2): 9.18.13.1269

The good news is that I can now run the nightly build and it runs fine. Whereas it didn't before I updated the driver.
(In reply to Milan Sreckovic [:milan] from comment #11)
> We will likely turn off OMTC in Aurora by June 27th, but I'd like to track
> this as we can't really ship this kind of regression either way.

With OMTC disabled on 32, is there anything left to fix on this branch? Tracking 32 and 33 until I know better.
I think we're fine on 32, though, theoretically, this problem existed before OMTC, just was very difficult to hit.  We're leaning towards the blacklisting.
Flags: needinfo?(milan)
I've been having this problem for a Long Time now (since OMTC landed I guess).  Blocks even profilemanager from running.

https://pastebin.mozilla.org/5695967
Win7 W520 up to date.

I know mreavy has the same problem
Had another report of this, need to ensure this gets fixed/blacklisted on Aurora. Matt, you have a W520 with Win7, can you work with Jesup (who's also seeing this) and/or Mark to figure out what's different about your machine and theirs?
Blocks: 1036457
Flags: needinfo?(matt.woodrow)
Assignee

Comment 17

5 years ago
Managed to get those drivers installed by downloading from dell and editing the inf file, can reproduce the issue now.

We're getting a bunch of First-chance exceptions (_com_error) deep within CreateShaderResourceView (within DrawQuad) and it then returns E_OUTOFMEMORY.

Not sure what to look at next, and it appears that the directx debug layer isn't working for me.

This seems similar bug 1003293, vlad any suggestions on how you debugged that one?
Flags: needinfo?(matt.woodrow) → needinfo?(vladimir)
A whole lot of trial and error, unfortunately.  I was poking around the Optimus and other code and found a pattern that seemed to trigger the issues.  But if it's an issue with an older driver, I'm not sure if there's anything we really should be digging into, short of blacklisting things.
Flags: needinfo?(vladimir)
Assignee

Comment 19

5 years ago
If it's the default driver for W520 machines, then we might blacklist a large proportion of our d2d users that way. bjacob, do you have the tools you use for determining this available anywhere?

If it's synchronization related, then it's possible that switching to d2d 1.1 might help.

I can try looking for other drivers versions to narrow down when this got fixed.
Flags: needinfo?(bjacob)
Assignee

Comment 20

5 years ago
15.21.7.64.2321 (8.15.10.2321) - Broken
15.21.13.64.2342 (8.15.10.2342) - Working

Guess we need to know how many users we'll exclude if we blacklist all intel drivers older than 2342.

Bas, do we have any contacts at Intel who we could ask about this? Seems like a fairly narrow range, so they might be able to figure out what fixed it and if any workarounds exist.
Flags: needinfo?(bas)
(In reply to Matt Woodrow (:mattwoodrow) from comment #20)
> 15.21.7.64.2321 (8.15.10.2321) - Broken
> 15.21.13.64.2342 (8.15.10.2342) - Working
> 
> Guess we need to know how many users we'll exclude if we blacklist all intel
> drivers older than 2342.
> 
> Bas, do we have any contacts at Intel who we could ask about this? Seems
> like a fairly narrow range, so they might be able to figure out what fixed
> it and if any workarounds exist.

Excellent work, I've sent a message to our Intel contacts. But I do share your concerns.

For the DirectX debug layer, make sure you have the latest Windows SDK installed (8.1) and be sure to pass the DEBUG CREATE_DEVICE flags to the device creation calls. It should work fine then, although I haven't used it on Win7 for a while.
Flags: needinfo?(bas)
(In reply to Matt Woodrow (:mattwoodrow) from comment #19)
> If it's the default driver for W520 machines, then we might blacklist a
> large proportion of our d2d users that way. bjacob, do you have the tools
> you use for determining this available anywhere?

It's not really tools, it's just that the data is available online as CSV files at
https://crash-analysis.mozilla.com/crash_analysis/

and those can be easily processed with bash one-liners.

So if I understand correctly, the question is how much D2D usage would drop if we blacklisted drivers older than 2342.

If I understand correctly, in a driver version like 8.15.10.2342, only the last part indicates the driver version, while the first 3 parts are characteristic of the Windows version. So for the sake of figuring how many drivers are older than 2342, we only need to look at the last part.

Let's use crash data from yesterday (July 29).

bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  | grep 'AdapterVendorID: 0x8086' | grep AdapterDriverVersion | wc -l
124211
bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  | grep 'AdapterVendorID: 0x8086' | grep AdapterDriverVersion | s 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l
42283

So overall, among Intel graphics users on windows, one third have driver < 2342

bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  | grep 'AdapterVendorID: 0x8086' | grep 'D2D[+]' | grep AdapterDriverVersion | wc -l
64582
bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  | grep 'AdapterVendorID: 0x8086' | grep 'D2D[+]' | grep AdapterDriverVersion | sed 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l
10309

So if we restrict attention to people who are getting D2D, now the proportion of people with driver<2342 falls to 16%, or about 8% of the total.

bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  | grep 'AdapterVendorID: 0x8086' | grep 'GPU #2' | grep 'D2D[+]' | grep AdapterDriverVersion | wc -l
8333
bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  | grep 'AdapterVendorID: 0x8086' | grep 'GPU #2' | grep 'D2D[+]' | grep AdapterDriverVersion | sed 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l
859

So if we further restrict to people with a 2nd GPU, then the proportion of people with driver<2342 falls to 10%, and less than 1% of the total (because relatively few people with Intel graphics have a 2nd GPU).

bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  | grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'GPU #2' | grep 'D2D[+]' | grep AdapterDriverVersion | wc -l
938
bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  | grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'GPU #2' | grep 'D2D[+]' | grep AdapterDriverVersion | sed 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l
176

So if we still further restrict to people having this exact GPU 0x0126 (and have a 2nd GPU) then the proportion of people with driver <2342 is higher (close to 20%) but that's now only 0.1% of the total, because we've restricted the population so much.

Finally, what if we restrict to device 0x0126, but dont restrict to having a 2nd GPU?

bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  | grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'D2D[+]' | grep AdapterDriverVersion | wc -l
3542
bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  | grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'D2D[+]' | grep AdapterDriverVersion | sed 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l
726

So we still have 20% of people with driver <2342, and the blacklisted population is still <1% of the total.


Conclusions:
 * A whole lot of people have driver <2342, even if we restrict to people currently getting D2D.
 * But we can limit the number of people we blacklist by restricting to some specifics of the hardware that this bug is reported against --- either restrict to this device 0x0126, or restrict to having a 2nd GPU, or both --- either way gives you a blacklisted population smaller than 1% of total windows/intel users population.
Flags: needinfo?(bjacob)
(In reply to Benoit Jacob [:bjacob] from comment #22)
> (In reply to Matt Woodrow (:mattwoodrow) from comment #19)
> > If it's the default driver for W520 machines, then we might blacklist a
> > large proportion of our d2d users that way. bjacob, do you have the tools
> > you use for determining this available anywhere?
> 
> It's not really tools, it's just that the data is available online as CSV
> files at
> https://crash-analysis.mozilla.com/crash_analysis/
> 
> and those can be easily processed with bash one-liners.
> 
> So if I understand correctly, the question is how much D2D usage would drop
> if we blacklisted drivers older than 2342.
> 
> If I understand correctly, in a driver version like 8.15.10.2342, only the
> last part indicates the driver version, while the first 3 parts are
> characteristic of the Windows version. So for the sake of figuring how many
> drivers are older than 2342, we only need to look at the last part.
> 
> Let's use crash data from yesterday (July 29).
> 
> bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  |
> grep 'AdapterVendorID: 0x8086' | grep AdapterDriverVersion | wc -l
> 124211
> bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  |
> grep 'AdapterVendorID: 0x8086' | grep AdapterDriverVersion | s
> 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk
> '$1<2342' | wc -l
> 42283
> 
> So overall, among Intel graphics users on windows, one third have driver <
> 2342
> 
> bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  |
> grep 'AdapterVendorID: 0x8086' | grep 'D2D[+]' | grep AdapterDriverVersion |
> wc -l
> 64582
> bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  |
> grep 'AdapterVendorID: 0x8086' | grep 'D2D[+]' | grep AdapterDriverVersion |
> sed 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' |
> awk '$1<2342' | wc -l
> 10309
> 
> So if we restrict attention to people who are getting D2D, now the
> proportion of people with driver<2342 falls to 16%, or about 8% of the total.
> 
> bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  |
> grep 'AdapterVendorID: 0x8086' | grep 'GPU #2' | grep 'D2D[+]' | grep
> AdapterDriverVersion | wc -l
> 8333
> bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  |
> grep 'AdapterVendorID: 0x8086' | grep 'GPU #2' | grep 'D2D[+]' | grep
> AdapterDriverVersion | sed 's/.*AdapterDriverVersion:
> [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l
> 859
> 
> So if we further restrict to people with a 2nd GPU, then the proportion of
> people with driver<2342 falls to 10%, and less than 1% of the total (because
> relatively few people with Intel graphics have a 2nd GPU).
> 
> bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  |
> grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'GPU
> #2' | grep 'D2D[+]' | grep AdapterDriverVersion | wc -l
> 938
> bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  |
> grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep 'GPU
> #2' | grep 'D2D[+]' | grep AdapterDriverVersion | sed
> 's/.*AdapterDriverVersion: [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk
> '$1<2342' | wc -l
> 176
> 
> So if we still further restrict to people having this exact GPU 0x0126 (and
> have a 2nd GPU) then the proportion of people with driver <2342 is higher
> (close to 20%) but that's now only 0.1% of the total, because we've
> restricted the population so much.
> 
> Finally, what if we restrict to device 0x0126, but dont restrict to having a
> 2nd GPU?
> 
> bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  |
> grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep
> 'D2D[+]' | grep AdapterDriverVersion | wc -l
> 3542
> bjacob@bjacob-dell:~/hack/crash-stats$ zcat 20140729-pub-crashdata.csv.gz  |
> grep 'AdapterVendorID: 0x8086' | grep 'AdapterDeviceID: 0x0126' | grep
> 'D2D[+]' | grep AdapterDriverVersion | sed 's/.*AdapterDriverVersion:
> [0-9]*\.[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/g' | awk '$1<2342' | wc -l
> 726
> 
> So we still have 20% of people with driver <2342, and the blacklisted
> population is still <1% of the total.
> 
> 
> Conclusions:
>  * A whole lot of people have driver <2342, even if we restrict to people
> currently getting D2D.
>  * But we can limit the number of people we blacklist by restricting to some
> specifics of the hardware that this bug is reported against --- either
> restrict to this device 0x0126, or restrict to having a 2nd GPU, or both ---
> either way gives you a blacklisted population smaller than 1% of total
> windows/intel users population.

Great stuff Benoit, thanks a lot for this.

Matt, as a first attempt I believe we should try to restrict to people with <2342 and a second GPU. That seems like a fair population to hit. Could you try and write the patch for that and test it on your machine? Unless you disagree with me and feel we should take another approach.
Flags: needinfo?(matt.woodrow)
Assignee

Comment 24

5 years ago
Do we have any reason to believe that this is actually dependent on having a second GPU? Since we don't have a suitable machine to test this on, and the bug appears to be entirely related to the intel driver version, then I'd think we'd be better of blacklisting this version in it's entirety.

I tried creating D3D11 textures, and using DXGI to get the D310 texture for direct2d and that still fails.

I also tried hooking up D2D 1.1 and that appears to work, except that it still has a fair few bugs (that I assume are because we haven't tried d2d 1.1 before).
Flags: needinfo?(matt.woodrow)
Assignee

Updated

5 years ago
Depends on: 1046550
Assignee

Comment 25

5 years ago
I filed bug 1046550 with the patch I used for testing direct2d 1.1
(In reply to Matt Woodrow (:mattwoodrow) from comment #24)
> Do we have any reason to believe that this is actually dependent on having a
> second GPU? Since we don't have a suitable machine to test this on, and the
> bug appears to be entirely related to the intel driver version, then I'd
> think we'd be better of blacklisting this version in it's entirety.
> 
> I tried creating D3D11 textures, and using DXGI to get the D310 texture for
> direct2d and that still fails.
> 
> I also tried hooking up D2D 1.1 and that appears to work, except that it
> still has a fair few bugs (that I assume are because we haven't tried d2d
> 1.1 before).

Almost all of these more obscure bugs appear to be related to Optimus. But sure, just for good measure we could blocklist all. Did you try while disabling your nvidia graphics from the bios? It's interesting that 1.1 works, that surprises me. I do believe, considering the -huge- about of intel users on that driver version, and the fairly low amount of complaints, we can limit the blacklisting to this device.
It would be ironic to blacklist the default drivers on the laptops we distribute to employees... but, that said, it's better than losing even 0.1% of our users.  

It's too bad we can't figure out we're rendering everything as black at startup.... and just dynamically disable it.  (Say search for a non-black pixel after the first window paints (or whatever, or on first Draw write a single white pixel and read it back) - should be a very cheap test if things work! - and disable 2d if we don't find any)
Assignee

Comment 28

5 years ago
This failure was showing up as an HRESULT error in the compositor thread. I guess we could detect that and disable direct2d somehow. Not sure if we have infrastructure for that though.
Can we hack it by setting layers.direct2d.disabled to true after detecting this error?  We will crash that time, but after that we would have auto-set the disabling of the d2d and wouldn't crash the next time?  I don't know if there is enough time between seeing this error for the pref to get changed before we actually crash, if we're on the right thread to do it, if this error only shows up just before the crash, etc., just thinking out loud...
Setting a pref would mean permanent blacklisting, which would confuse users trying to address the issue by upgrading their drivers. It seems that the regular blacklisting conversation above is already advanced enough that we dont need to think about such more painful fixes.
(In reply to Matt Woodrow (:mattwoodrow) from comment #24)
> Do we have any reason to believe that this is actually dependent on having a
> second GPU? Since we don't have a suitable machine to test this on, and the
> bug appears to be entirely related to the intel driver version, then I'd
> think we'd be better of blacklisting this version in it's entirety.

I'm sort of with Bas on this - it seems OK to blacklist either only this specific GPU or only dual-GPU systems until we get a definite bug report showing that's not enough - but don't care strongly.

We just need to make a decision on this either way - blacklist only specific setup or all old drivers - but make one, let's not conflate into this immediate bugfixing conversation the more complex and long-term conversation of how to automatically detect D2D bugs and fall back to non-D2D, instead that would be OK material for a followup bug.
Assignee

Comment 32

5 years ago
Damn, it appears direct2d 1.1 doesn't actually work. I had it setup sharing the same device between direct2d and the compositor which is racy. Using separate devices puts us back to requiring interop and fails in the same way.

Unless we hear back from intel I think we should go ahead with blacklisting.
Assignee

Comment 34

5 years ago
I also tried disabling the nvidia card/optimus using the bios, still broken.
Attachment #8465939 - Flags: review?(bjacob) → review+
Dropping tracking on 32 as OMTC has been disabled for 32.
https://hg.mozilla.org/mozilla-central/rev/1e509bd9e284
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Comment on attachment 8465939 [details] [diff] [review]
Blacklist direct2d on this device

Approval Request Comment
[Feature/regressing bug #]: Bug 899785
[User impact if declined]: No rendering for some people
[Describe test coverage new/current, TBPL]: Nightly
[Risks and why]: Extremely low, blacklisting change.
[String/UUID change made/needed]: None
Attachment #8465939 - Flags: approval-mozilla-aurora?
Attachment #8465939 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee: nobody → matt.woodrow
Target Milestone: --- → mozilla34

Comment 40

5 years ago
fyi ... I recently installed Aurora 33a2 build 20140805004001 and it repeatedly crashed on start up. Because of a previous problem (black window on startup) I had preference <layers.offmainthreadcomposition.enabled> set to false.

I edited <prefs.js> to change <layers.offmainthreadcomposition.enabled> to true and the problem was resolved. I don't have a pref named <layers.direct2d.disabled>
=====================

Mozilla/5.0 (Windows NT 6.1; rv:33.0) Gecko/20100101 Firefox/33.0
Aurora 33a2 build 20140805004001

Laptop
Lenovo T420
Windows 7

Configuration
gfx.blacklist.suggested-driver-version	10.6
gfx.canvas.azure.backends	direct2d,cg,skia,cairo
gfx.direct3d.last_used_feature_level_idx	0
layers.offmainthreadcomposition.enabled	true


Graphics
Adapter Description	Intel(R) HD Graphics Family
Adapter Description (GPU #2)	NVIDIA NVS 4200M
Adapter Drivers	igdumdx32 igd10umd32 igd10umd32
Adapter Drivers (GPU #2)	nvd3dum nvwgf2um,nvwgf2um
Adapter RAM	Unknown
Adapter RAM (GPU #2)	1024
Device ID	0x0126
Device ID (GPU #2)	0x1057
Direct2D Enabled	Blocked for your graphics driver version. Try updating your graphics driver to version 10.6 or newer.
DirectWrite Enabled	false (6.2.9200.16571)
Driver Date	3-6-2011
Driver Date (GPU #2)	10-28-2013
Driver Version	8.15.10.2321
Driver Version (GPU #2)	9.18.13.1269
GPU #2 Active	false
GPU Accelerated Windows	2/2 Direct3D 11 (OMTC)
Vendor ID	0x8086
Vendor ID (GPU #2)	0x10de
WebGL Renderer	Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote	true
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0
Flags: qe-verify-
You need to log in before you can comment on or make changes to this bug.