1083071 - After upgrading to Firefox 33, window is BLACK at startup with OMTC enabled

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[jerryj]

Attachment: ff33.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.104 Safari/537.36

Steps to reproduce:

Had FF32 installed.  Went into help/about and upgraded.  Upon restart, I only got the attached (FF33 does not work).  Had to uninstall and go back to FF32.

Comment 1

[Loic]

Type about:config in the location bar and set layers.offmainthreadcomposition.enabled to false then restart Firefox. Does it fix it?

Comment 2

[Jim Michaels]

- 64-bit 12-thread 64GB RAM computer with ff32.0.3 has about 300 tabs using 63 threads at 1% cpu usage (not sure why so few?)  (32.0.3).

- 32-bit 1-thread 2GB RAM 4GB Virtual Memory xp pro box with 1 tab uses 48 threads (not sure why so many?) at 92% CPU usage. ff slowed down the entire computer. I managed to do an upgrade, but doing help, about took about 10-15 minutes to get to the dialog I suppose (memory fuzzy). I waited 10-15min more for upgrade to finish and left with it unfinished. came back and browser had crashed showing the mozilla crash dialog, which I commented in and said nearly the same thing. used 153MB RAM. seems as if it's a virus or has one due to the whole-computer-slowness thing, but it doesn't have malware, it's just a bug.


I think I can assume most of these are asleep - I hope. if not, it would explain the CPU usage 92%.
but a busy-wait or polling loop with no Sleep() in a thread manager thread or main thread would do this too. it doesn't even have to sleep very long. could be 100ms. or 50ms. but at least allow some time for 1-thread procs to be nice and let the OS have some time by using the Sleep() to do the blocking when you are polling to create threads, if this is your method.

how many threads/cores is your cpu?

I did some investigating.
ff33 uses 48 threads on XP, causes 92% cpu usage on 1-thread cpu, upgrade crashes. makes me afraid to do help, about to get the browser version. I have a web page which will give you this information without danger. http://Jesusnjim.com/common/browserinfo.html
and there's also about:support

by the way, navigator property doesn't show the whole version number in 32.0.3, shows 32.0 perhaps it's a float?


http://www.cocoabuilder.com/archive/cocoa/42988-getting-the-number-of-cpus.html#49091
http://msdn.microsoft.com/en-us/library/dd470844.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms687025(v=vs.85).aspx

there is no std::threads way of querying the number of procs. I wish there were. you could do better thread management that way. especially if you could find out how many available threads there are. 
windows' jobs is a polling try-fail-try-again thing where you attempt to start a thread, and if it succeeds, great. if it doesn't you sleep for a while and try again. the sleep is so you don't chew up a proc/thread/core in the management thread, that blocks for the OS to take over and do stuff in the meantime if the that cpu thread is needed.
and there's mutexes, semaphores, and all sorts of locking semantics you can do for concurrency, with native threads, and possibly OpenMP.

but I am unsure what's all in the JS Web Workers multithreading API bcause I haven't looked at it in a while. I haven't had much personal need to use it lately, but it looked useful for one web page I had that did the rain program type of thing, but you would quickly run out of CPU threads and didn't get it to run on ff at the time since it was a new API at the time, so I changed it to a timer event thing which works much better and handles more concurrency and is more fluid.

the ff33 CPU usage is an issue at 92% on a 1-thread proc. if the manager/main thread is spinning wildly just doing a busy-wait while loop polling for access to something, this would cause the problem, it would chew up a CPU thread at 100% usage. using a Sleep() in the loop would knock that way down.

could be a someone's first foray into multithreading. if you do multithreading, you should do some reading on the subject, since there are complexities. for instance:
if 2 threads are concurrently accessing or alternately accessing a structure or variable, like the example of A and B threads doing a read-increment-write, doing this without a semaphore or mutex can lose data - it should also be noted that semaphores (locks) can cause deadlock conditions, since the other threads are blocking (waiting) to access a single resource. in C/C++, you should declare it volatile at least (I think there are new std c++ lib declarations now possibly, but this is the only one I know of offhand), so the compiler knows something might pop in an unexpectedly change the value.

but maybe I am wrong and I didn't hit the target - I am only trying to throw guesses at what's wrong.

Comment 3

[Jim Michaels]

my window was white I think. it's got an old intel 82865G video chipset using latest drivers for dell dimension b110.

Comment 4

[Loic]

The issue is about OMTC.

Comment 6

[jerryj]

(In reply to Loic from comment #1)
> Type about:config in the location bar and set
> layers.offmainthreadcomposition.enabled to false then restart Firefox. Does
> it fix it?

Yes. Thanks!  But kind of a catch-22 to tell me to do something the affects the GUI without a GUI.  But this is how I ended up doing it (blindly, with no GUI):

1. click over where 'Search or enter address' should be (tip, watch cursor change as you move over it)
2. type "about:config", and press 'enter' key
3. press 'enter' key again (if you have the "This might void you warranty" warning not turned off)
4. type (or copy/paste) "layers.offmainthreadcomposition.enabled"
5. press 'TAB' key
6. press 'enter' key
7. exit/close FF
8. restart FF and GUI appears!

My notebook is a Dell L702X (i7 2630QM 2.00Ghz; 4 cores; 8 threads) 8GB.

This is really going to turn tons of people off to FF if this OMTC issue affects a lot of people out there.

Comment 7

[Loic]

Anyway, if the users can't type anything in the location bar because the UI is broken, they can use this workaround:

1) Close Firefox
2) Open the folder of the current Firefox profile (see http://kb.mozillazine.org/Profile_folder_-_Firefox)
3) Open the file prefs.js (with any file editor)
4) Add the line user_pref("layers.offmainthreadcomposition.enabled", false); (by alphabetical order from letter "l")
5) Save and restart Firefox

Comment 9

[Loic]

5 users with the same issue on the French community board: http://forums.mozfr.org/viewtopic.php?f=5&t=120622

Comment 10

[Sören Hentzschel]

There are multiple reports in the "german speaking web" (forums, blogs) about the same issue.

Comment 11

[jerryj]

***UPDATE***

The SIMPLEST way to work around this problem (in a GUI) until the bug is fixed...

1. Start FF in 'safe mode' by holding shift down while starting FF (from bug 1083139).
2. Type about:config in the location bar and set layers.offmainthreadcomposition.enabled to false, and restart FF (from comment #1 above).

Comment 15

[Sylvestre Ledru [:Sylvestre]]

Nicolas, Bas. I think we need your help here. It seems that many people are hitting this bug. Could you help on this? thanks!

Comment 16

[Jim Jeffery not reading bug-mail 1/2/11]

this seems like a good candidate for a 'chemspill' to turn 'off' OMTC

Comment 17

[Sylvestre Ledru [:Sylvestre]]

Switching OMTC to off is probably not a appropriate response to this bug. We did the experiment with beta 7 (Windows OMTC=off) and it caused some important regressions.

Comment 18

[[:philipp]]

the bug seems to be confined to certain graphic cards and driver versions, please see
https://bugzilla.mozilla.org/show_bug.cgi?id=1037828#c20

Comment 19

[Nicolas Silva [:nical]]

Attachment: add more driver versions to the blacklist

This patch adds the driver versions that Philip pointed out on the other bug (thanks btw, that's useful info).

At this point I think we should be even more conservative and blacklist some more recent driver versions (while still staying in the range of "old drivers"), to be on the safe side.

Comment 20

[jerryj]

Fails under:

Adapter Description	Intel(R) HD Graphics Family
Device ID	0x0116
Driver Date	3-6-2011
Driver Version	8.15.10.2321
Vendor ID	0x8086

Comment 21

[Nicolas Silva [:nical]]

(In reply to jerryj from comment #20)
> Fails under:
> 
> Adapter Description	Intel(R) HD Graphics Family
> Device ID	0x0116
> Driver Date	3-6-2011
> Driver Version	8.15.10.2321
> Vendor ID	0x8086

thanks, will update the patch

Comment 22

[[:philipp]]

before you update - i've now also seen a user reporting about this issue with a intel hd4000...

Device ID: 0x0166 
Driver Date: 9-26-2012 
Driver Version: 9.17.10.2867

https://support.mozilla.org/en-US/questions/1025544#answer-641069

Comment 23

[Bas Schouten (:bas.schouten)]

We should just be able to use the downloadable blacklist to blacklist these drivers for acceleration?

Comment 24

[Sylvestre Ledru [:Sylvestre]]

(In reply to Bas Schouten (:bas.schouten) from comment #23)
> We should just be able to use the downloadable blacklist to blacklist these
> drivers for acceleration?
I wasn't aware we had this option. If we can push this updated blacklist to our users quickly, that would be perfect. Do we have some documentation on this topic (implementation, delay, limitation, etc)?

Thanks

Comment 25

[Milan Sreckovic [:milan] (needinfo for best results)]

https://wiki.mozilla.org/Blocklisting/Graphics

Comment 26

[Liz Henry (:lizzard) (relman/hg->git project)]

Do we know from telemetry approximately how many users this would affect?

Comment 27

[Milan Sreckovic [:milan] (needinfo for best results)]

Jerry, any chance you can help us test a fix?  It involves following steps here:
https://wiki.mozilla.org/Blocklisting/Testing, but you would change those settings while in FF32 (since you can't see things in 33 :), then upgrading and running, and doing the last part of the instructions (the code snippet) in case things are still bad.

Comment 28

[jerryj]

Milan, I am no longer running the old video drivers.  I upgraded to the latest Intel drivers (https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=23764) as per 1037828, which fixed the issue for me.  FF33+OMTC with new video drivers works.

Comment 29

[Aaron Train [:aaronmt]]

I have at least two confirmations that updating their Intel Graphics Drivers did indeed work for them.

http://www.reddit.com/r/firefox/comments/2jcee9/this_is_firefox_33_for_me_since_today_already/claedcs

Comment 30

[GMA]

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24329

Ivy Bridge HD4000/HD2500 latest Intel drivers is 10.18.10.3945.

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24245

Haswell HD4200/4400/4600/5000, Iris 5100 & Iris Pro 5200 latest Intel drivers is 10.18.10.3907.

Comment 31

[Arthur K. (he/him)]

(In reply to GMA from comment #30)
> https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24329
> 
> Ivy Bridge HD4000/HD2500 latest Intel drivers is 10.18.10.3945.

I'm running 15.33.30.64.3958 on Ivy Bridge and also 15.36.7.3960 (for Haswell?) are out there BTW. Obtainable from Station Drivers


> https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24245
> 
> Haswell HD4200/4400/4600/5000, Iris 5100 & Iris Pro 5200 latest Intel
> drivers is 10.18.10.3907.

Comment 33

[Loic]

In the bug I duped, another version of Intel drivers with the same issue:

Graphics
Adapter Description	Intel(R) HD Graphics Family
Adapter Drivers	igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32
Adapter RAM	Unknown
Device ID	0x0106
DirectWrite Enabled	false (6.2.9200.16571)
Driver Date	12-16-2010
Driver Version	8.15.10.2266
GPU #2 Active	false
GPU Accelerated Windows	0/1 Basic (OMTC)
Vendor ID	0x8086
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

Comment 34

[Arthur K. (he/him)]

(In reply to Loic from comment #33)
> In the bug I duped, another version of Intel drivers with the same issue:
> 
> Graphics
> Adapter Description	Intel(R) HD Graphics Family
> Adapter Drivers	igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32
> igd10umd32
> Adapter RAM	Unknown
> Device ID	0x0106
> DirectWrite Enabled	false (6.2.9200.16571)
> Driver Date	12-16-2010
> Driver Version	8.15.10.2266
> GPU #2 Active	false
> GPU Accelerated Windows	0/1 Basic (OMTC)
> Vendor ID	0x8086
> 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

With a driver date that old, blacklisting doesn't seem to be an option. How do we get these users to update their VGA driver to something current? A lot of complaints will come due to something out of our control.

Comment 35

[jerryj]

(In reply to Arthur K. from comment #34)
> With a driver date that old, blacklisting doesn't seem to be an option. How
> do we get these users to update their VGA driver to something current? A lot
> of complaints will come due to something out of our control.

Testing to see if a feature works (or not) is definitely under the control of Mozilla.  As a programmer, I have to work around bugs in the OS, bugs in browsers, etc ALL of the time.  I NEVER perform bug workarounds based upon version number checking.  Never ever.  Instead, I perform feature success checking.  Create a very simple subroutine that probes for the bug to see if the feature I want to use actually works.  If I can verify success, I can use the feature.  If it fails, I need to use my workaround.

Is it really impossible for Mozilla to detect in software that OMTC is not working properly?  Of course it CAN.  If not 100% directly, then at the very least, indirectly.  It can be done.

Regarding updating drivers: users can not always update for a variety of reasons.  I went to Dell and installed the latest video drivers from them, which caused my system to become unstable with one critical application.  So, I had to revert back.  After this FF33/OMTC issue, I finally went around Dell and installed drivers directly from Intel (which Intel WARNS can cause problems if a vendor/Dell has made custom modifications), and so far, it appears to work just fine.  But going around what Dell says is OK for my computer is a risk (that I was willing to take).  Others may not be able to take that risk (company policy).

The bottom line: For many people (like my Dad), the computer is just a tool that 'just works'.  Everything they do on it, and everything they use on it 'just works'.  FF on it is no different.  It should always 'just work'.  The fact that this OMTC (black window) issue happened, means that some process within Mozilla has failed and needs to be reworked.

Comment 36

[Nicolas Silva [:nical]]

(In reply to jerryj from comment #35)
> Testing to see if a feature works (or not) is definitely under the control
> of Mozilla.  As a programmer, I have to work around bugs in the OS, bugs in
> browsers, etc ALL of the time.  I NEVER perform bug workarounds based upon
> version number checking.  Never ever.  Instead, I perform feature success
> checking.  Create a very simple subroutine that probes for the bug to see if
> the feature I want to use actually works.  If I can verify success, I can
> use the feature.  If it fails, I need to use my workaround.
> 
> Is it really impossible for Mozilla to detect in software that OMTC is not
> working properly?  Of course it CAN.  If not 100% directly, then at the very
> least, indirectly.  It can be done.

I wish things were that simple. Please let's not get off topic in this bug. You can spin a thread on the dev-platform mailing list or open a separate bug if you have interesting ideas about how to get buggy drivers to not fail silently or on how to test on hundreds of thousands of configuration, or even on what's wrong with mozilla's processes. Those are hard and interesting problems and I'll be happy to discuss those things in the proper place.

Comment 37

[jerryj]

(In reply to Nicolas Silva [:nical] from comment #36)
> I wish things were that simple. Please let's not get off topic in this bug.
> You can spin a thread on the dev-platform mailing list or open a separate
> bug if you have interesting ideas about how to get buggy drivers to not fail
> silently or on how to test on hundreds of thousands of configuration, or
> even on what's wrong with mozilla's processes. Those are hard and
> interesting problems and I'll be happy to discuss those things in the proper
> place.

So, let's stay ON topic.  FF32 upgraded to FF33 and I got a black window.  FF33 should have detected that (because it CAN).  That is a bug to fix.

Oh yes, it really is that simple.  A driver that silently fails is not a problem -- that can be detected.  Now that you know it can be done, maybe you can figure it out by yourself and fix FF...

Comment 38

[GMA]

https://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=24348

Intel just released 10.18.10.3960 WHQL drivers for Haswell today.

Comment 41

[Sylvestre Ledru [:Sylvestre]]

Nicolas, Bas, looking at comment #23 in bug 1083298, it seems we won't be able to use the downloadable blacklist.

Is the patch in this bug still valid? It seems that we need to update it to blacklist more drivers?

Comment 42

[Nicolas Silva [:nical]]

I am building a new patch locally.

Comment 43

[Nicolas Silva [:nical]]

Attachment: Updated patch

Comment 44

[Nicolas Silva [:nical]]

Comment on attachment 8506948 [details] [diff] [review]
Updated patch

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: Firefox unusable with some drivers on Windows (release).
[Describe test coverage new/current, TBPL]: None, Mozilla doesn't have any hardware that can reproduce the issue at the moment.
[Risks and why]: Low. Simple patch.
[String/UUID change made/needed]:

Comment 45

[Loic]

Some Intel driver versions I collected with the issue:

Accélération graphique
Date du pilote 3-6-2011
Description de la carte Intel(R) HD Graphics Family
Direct2D activé true
DirectWrite activé true (6.1.7601.17789)
Fenêtres avec accélération graphique 2/2 Direct3D 10
GPU #2 active false
ID du périphérique 0x0116
ID du vendeur 0x8086
Pilotes de la carte igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32
RAM de la carte Unknown
Rendu WebGL Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D9Ex vs_3_0 ps_3_0)
Version du pilote 8.15.10.2321
windowLayerManagerRemote false
AzureCanvasBackend direct2d
AzureContentBackend direct2d
AzureFallbackCanvasBackend cairo
AzureSkiaAccelerated 0

*****************************************************

Accélération graphique
Date du pilote 1-16-2013
Date du pilote (GPU #2) 12-4-2013
Description de la carte Intel(R) HD Graphics 4000
Description de la carte (GPU #2) Air Display (Microsoft Corporation - WDDM v1.1)
Direct2D activé true
DirectWrite activé true (6.2.9200.16571)
Fenêtres avec accélération graphique 1/1 Direct3D 10
GPU #2 active false
ID du périphérique 0x0166
ID du périphérique (GPU #2) 0xbeef
ID du vendeur 0x8086
ID du vendeur (GPU #2) 0x1337
Pilote de la carte (GPU #2) AirDisplayWDDM
Pilotes de la carte igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32
RAM de la carte Unknown
RAM de la carte (GPU #2) 64
Rendu WebGL Google Inc. -- ANGLE (Intel(R) HD Graphics 4000 Direct3D9Ex vs_3_0 ps_3_0)
Version du pilote 9.17.10.2963
Version du pilote (GPU #2) 2.0.3.440
windowLayerManagerRemote false
AzureCanvasBackend direct2d
AzureContentBackend direct2d
AzureFallbackCanvasBackend cairo
AzureSkiaAccelerated 0

*****************************************************

Accélération graphique
Date du pilote 11-28-2010
Date du pilote (GPU #2) 10-23-2013
Description de la carte Intel(R) HD Graphics Family
Description de la carte (GPU #2) NVIDIA GeForce GT 525M
Direct2D activé true
DirectWrite activé true (6.2.9200.16571)
Fenêtres avec accélération graphique 1/1 Direct3D 10
GPU #2 active false
ID du périphérique 0x0116
ID du périphérique (GPU #2) 0x0df5
ID du vendeur 0x8086
ID du vendeur (GPU #2) 0x10de
Paramètres ClearType Gamma: 1800 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50
Pilote de la carte (GPU #2) nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Pilotes de la carte igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32
RAM de la carte Unknown
RAM de la carte (GPU #2) 1024
Rendu WebGL Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D9Ex vs_3_0 ps_3_0)
Version du pilote 8.15.10.2253
Version du pilote (GPU #2) 9.18.13.3165
windowLayerManagerRemote false
AzureCanvasBackend direct2d
AzureContentBackend direct2d
AzureFallbackCanvasBackend cairo
AzureSkiaAccelerated 0

*****************************************************

Date du pilote 1-7-2011
Description de la carte Intel(R) HD Graphics Family
DirectWrite activé false (6.2.9200.16571)
Fenêtres avec accélération graphique 0/1 Basic (OMTC)
GPU #2 active false
ID du périphérique 0x0116
ID du vendeur 0x8086
Pilotes de la carte igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32
RAM de la carte Unknown
Rendu WebGL Google Inc. -- ANGLE (Intel(R) HD Graphics Family Direct3D9Ex vs_3_0 ps_3_0)
Version du pilote 8.15.10.2279
windowLayerManagerRemote true
AzureCanvasBackend skia
AzureContentBackend cairo
AzureFallbackCanvasBackend cairo
AzureSkiaAccelerated 0

Comment 46

[Carsten Book [:Tomcat]]

landed in release per request from Sylvestre in 

remote:   https://hg.mozilla.org/releases/mozilla-release/rev/d96967b7f22a

Comment 47

[Carsten Book [:Tomcat]]

and https://hg.mozilla.org/releases/mozilla-release/rev/af3e9893c579 for the relbranch

Comment 48

[[:philipp]]

This patch may not cover all buggy GPUs/driver combinations - please also incorporate my feedback from Comment 22 and Loic's from Comment 45.

Intel HD4000 cards (Device ID: 0x0166) with at least the following drivers are reported to cause the black screens as well:
9.17.10.2867 (Driver Date: 9-26-2012)
9.17.10.2963 (Driver Date: 1-16-2013)

Comment 53

[Nicolas Silva [:nical]]

Attachment: bump the IntelGMAX4500HD blacklist to drivers older than 7/20/2011

Approval Request Comment
[Feature/regressing bug #]:
[User impact if declined]: firefox unusable with some drivers
[Describe test coverage new/current, TBPL]: None, unfortunately.
[Risks and why]: getting more and more people to not have hardware acceleration, though we don't have much choice right now.
[String/UUID change made/needed]:

Comment 54

[Nicolas Silva [:nical]]

Attachment: Hand-pick some HD4000 drivers and add them to the blacklist

Thanks to Philip's reports.
Unfortunately, these two drivers are fairly recent (in comparison with most of the other failing drivers), so I added them one by one to the blacklist instead of going "all hd4000 drivers prior to early 2013 will have no acceleration" This means that we may run into more faulty drivers, and may reconsider this approach. I don't know how big the population of HD4000 users with drivers older than 2013 is.

This patch needs the one in bug 1085364.

Comment 55

[Arthur K. (he/him)]

Someone reported this issue in mozilla.support.firefox. He is using a 4500M with driver 8.15.10.2869 and those are from 11/16/2012. Intel has ceased updating drivers for this series.

Comment 56

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8506948 [details] [diff] [review]
Updated patch

https://hg.mozilla.org/integration/mozilla-inbound/rev/0970007a8468
https://hg.mozilla.org/releases/mozilla-aurora/rev/29c18591d6df
https://hg.mozilla.org/releases/mozilla-beta/rev/53b97e435f10

Comment 57

[Jeff Muizelaar [:jrmuizel]]

I have a HD4000 and downgraded it to the 9.17.10.2867 driver and it seems to work fine. I expect there's something else going on here other than device and driver version.

Comment 58

[Nicolas Silva [:nical]]

Comment on attachment 8507953 [details] [diff] [review]
bump the IntelGMAX4500HD blacklist to drivers older than 7/20/2011

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

Bas not here right now

Comment 59

[Nicolas Silva [:nical]]

Comment on attachment 8507960 [details] [diff] [review]
Hand-pick some HD4000 drivers and add them to the blacklist

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

Bas not here right now

Comment 61

[Bas Schouten (:bas.schouten)]

Comment on attachment 8507960 [details] [diff] [review]
Hand-pick some HD4000 drivers and add them to the blacklist

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

I dunno if this is a great idea, but hell, why not.

Comment 62

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #57)
> I have a HD4000 and downgraded it to the 9.17.10.2867 driver and it seems to
> work fine. I expect there's something else going on here other than device
> and driver version.

I have a 0x0162 so I suppose it's possible that only the 0x0166 is affected.

Comment 63

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8507953 [details] [diff] [review]
bump the IntelGMAX4500HD blacklist to drivers older than 7/20/2011

Like for bug 1083071, I would like this patch in both mozilla-release and mozilla-release branch GECKO330_2014101104_RELBRANCH

Comment 64

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

(In reply to Bas Schouten (:bas.schouten) from comment #61)
> Comment on attachment 8507960 [details] [diff] [review]
> Hand-pick some HD4000 drivers and add them to the blacklist
> 
> Review of attachment 8507960 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I dunno if this is a great idea, but hell, why not.

I am not sure at all that this patch is a good idea. First, as comment 62 says, it might not be the right blacklisting criterion. Second, it is blacklisting all features for a large range of Intel driver versions, and that's a big deal because Intel is 60% of our userbase.

I would like to understand better how the badness here compares to the badness of just disabling OMTC, even if the latter comes with some regressions.

Comment 65

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8507953 [details] [diff] [review]
bump the IntelGMAX4500HD blacklist to drivers older than 7/20/2011

https://hg.mozilla.org/integration/mozilla-inbound/rev/fba30348f0c6
https://hg.mozilla.org/releases/mozilla-aurora/rev/745747d29111
https://hg.mozilla.org/releases/mozilla-beta/rev/b5d97c1c71b7
https://hg.mozilla.org/releases/mozilla-release/rev/b4f691bf543e
https://hg.mozilla.org/releases/mozilla-release/rev/ecad78d1b49a

Comment 66

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8507953 [details] [diff] [review]
bump the IntelGMAX4500HD blacklist to drivers older than 7/20/2011

And a bustage fix:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f6df3bc60946
https://hg.mozilla.org/releases/mozilla-aurora/rev/15e99df2660c
https://hg.mozilla.org/releases/mozilla-beta/rev/8cc403ad710b
https://hg.mozilla.org/releases/mozilla-release/rev/fc031fd29ac3
https://hg.mozilla.org/releases/mozilla-release/rev/323728fc51c2

Comment 67

[Jeff Muizelaar [:jrmuizel]]

I can also not reproduce the problem on an Intel G41 (0x2e32) with driver version 8.15.10.1749

Comment 68

[Frank Worrell]

I hit what looks like the same bug at work on an Old Dell Latitude D800
running Windows XP pro SP3 with all Micosoft updates upgraded to Firefox 32.0.2.
It is not as severe as my home machine (bug 1085169 Firefox 33, declared identical)
the window is only black or mostly black half the time but Firefox is still unusable.

Comment 69

[Arthur K. (he/him)]

And does it resolve when you do layers.offmainthreadcomposition.enabled = false?

Comment 70

[Jeff Muizelaar [:jrmuizel]]

I can also not reproduce the problem on an Intel HD3000 (0x116) with driver version 8.15.10.2455

Comment 71

[Jeff Muizelaar [:jrmuizel]]

But I was able to reproduce it with version 8.15.10.2321

Comment 72

[Jeff Muizelaar [:jrmuizel]]

It seems like disabling Direct2D on this machine fixes the problem. My current guess is that something is going wrong with surface sharing (OpenShareHandle...)

Comment 73

[Jeff Muizelaar [:jrmuizel]]

WebGL is still broken with D2D disabled and OMTC enabled. This points another finger at surface sharing.

Comment 74

[Jeff Muizelaar [:jrmuizel]]

Turning on force-readback with WebGL fixes the problem which points yet another finger at surface sharing.

Comment 75

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/0970007a8468
https://hg.mozilla.org/mozilla-central/rev/fba30348f0c6
https://hg.mozilla.org/mozilla-central/rev/f6df3bc60946

Comment 76

[Jeff Muizelaar [:jrmuizel]]

I put together a simple test case that uses shared surfaces with D3D11 and it looks to work. 

https://github.com/jrmuizel/d3d-tests/blob/master/shared-surface.cc

This suggests that it's not shared surfaces related or we're doing something special to cause it to break.

Comment 77

[Milan Sreckovic [:milan] (needinfo for best results)]

Comment on attachment 8507960 [details] [diff] [review]
Hand-pick some HD4000 drivers and add them to the blacklist

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

::: widget/windows/GfxInfo.cpp
@@ +976,5 @@
> +    APPEND_TO_DRIVER_BLOCKLIST2( DRIVER_OS_ALL,
> +      (nsAString&) GfxDriverInfo::GetDeviceVendor(VendorIntel),
> +      (GfxDeviceFamily*) GfxDriverInfo::GetDeviceFamily(IntelHD4000),
> +      nsIGfxInfo::allFeatures, nsIGfxInfo::FEATURE_BLOCKED_DRIVER_VERSION,
> +      DRIVER_EQUAL, V(9.17.10.2963));

Is this supposed to be V(9,17,10,2963) instead?

Comment 78

[Milan Sreckovic [:milan] (needinfo for best results)]

Nical, see comment 77.

Comment 79

[Jeff Muizelaar [:jrmuizel]]

It looks like my initial test with readback the shared surface in firefox from the compositor had a bug. With that bug fixed it looks like we can successfully read back useful data on the compositor side. This suggests that it is the drawing of shared surfaces that could be broken.

Comment 80

[Nicolas Silva [:nical]]

(In reply to Milan Sreckovic [:milan] (PTO 10/16-10/17) from comment #78)
> Nical, see comment 77.

Was a mistake, RyanVM fixed it and relanded.

Comment 82

[Jeff Muizelaar [:jrmuizel]]

It looks like we get 

D3D11 ERROR: ID3D11Device::CreateShaderResourceView: Returning E_OUTOFMEMORY, meaning memory was exhausted. [ STATE_CREATION ERROR #132: CREATESHADERRESOURCEVIEW_OUTOFMEMORY_RETURN]

When trying to create a ShaderResourceView around our shared texture.

I'm able to reproduce this same problem with a standalone test case. The suggests were not doing anything too special which means this might be hard to work around.

Comment 83

[Arthur K. (he/him)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #82)
> It looks like we get 
> 
> D3D11 ERROR: ID3D11Device::CreateShaderResourceView: Returning
> E_OUTOFMEMORY, meaning memory was exhausted. [ STATE_CREATION ERROR #132:
> CREATESHADERRESOURCEVIEW_OUTOFMEMORY_RETURN]
> 
> When trying to create a ShaderResourceView around our shared texture.
> 
> I'm able to reproduce this same problem with a standalone test case. The
> suggests were not doing anything too special which means this might be hard
> to work around.

Hm, I'm curious what XP and Vista would spit back?

Comment 84

[Jeff Muizelaar [:jrmuizel]]

(In reply to Arthur K. from comment #83)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #82)
> > It looks like we get 
> > 
> > D3D11 ERROR: ID3D11Device::CreateShaderResourceView: Returning
> > E_OUTOFMEMORY, meaning memory was exhausted. [ STATE_CREATION ERROR #132:
> > CREATESHADERRESOURCEVIEW_OUTOFMEMORY_RETURN]
> > 
> > When trying to create a ShaderResourceView around our shared texture.
> > 
> > I'm able to reproduce this same problem with a standalone test case. The
> > suggests were not doing anything too special which means this might be hard
> > to work around.
> 
> Hm, I'm curious what XP and Vista would spit back?

A more interesting question is whether it works with D3D10 and why.

Comment 85

[Jeff Muizelaar [:jrmuizel]]

The source code for the reduced test case is at http://people.mozilla.org/~jmuizelaar/tmp/shared-texture.zip in tutorial7

Comment 86

[Jeff Muizelaar [:jrmuizel]]

It looks like windowless flash (http://www.popup-killer-review.com/windowless-swf.htm) is also broken on these machines in IE11.

I would be very interested in hearing if those on the bug that can reproduce the issue also see brokenness on the page above in IE11. (When drawn correctly the page should have large black text that fades in and out)

Comment 87

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #86)
> It looks like windowless flash
> (http://www.popup-killer-review.com/windowless-swf.htm) is also broken on
> these machines in IE11.
> 
> I would be very interested in hearing if those on the bug that can reproduce
> the issue also see brokenness on the page above in IE11. (When drawn
> correctly the page should have large black text that fades in and out)

I think I'm wrong here. Flash may work fine.

Comment 88

[Jeff Muizelaar [:jrmuizel]]

Flash seems to work. This is a good sign because it should be using shared surfaces which suggests that we might be able to get it to work.

Comment 89

[Jeff Muizelaar [:jrmuizel]]

Looking at the apitrace of IE's usage of shared surfaces it looks like they only copy from the plugin surface and don't sample it from a shader and thus won't hit the same problem.

Comment 90

[Ryan VanderMeulen [:RyanVM]]

(In reply to Nicolas Silva [:nical] from comment #80)
> Was a mistake, RyanVM fixed it and relanded.

That's on the patch that hasn't landed yet. I fixed the same issue on a different one.

Comment 91

[Jeff Muizelaar [:jrmuizel]]

A minimal test case that shows this problem is now here:
https://github.com/jrmuizel/d3d-tests/blob/master/shared-surface.cc

Benoit is going to look into porting it to d3d10 to see if we get the same problem.

Comment 92

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

Attachment: Jeff's shared-surface.cc, ported to D3D10.1 and DXGI 1.1

Had to use D3D10.1 and DXGI1.1 to get the SHARED_KEYEDMUTEX thing to work.

On the affected laptop, this succeeds, no E_OUTOFMEMORY error (whereas the original D3D11-using program above did generated E_OUTOFMEMORY).

This confirms Jeff's intuition that the bug at hand here is specific to D3D11 and does not affect D3D10[.1].

Comment 93

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Since we've added some additional blocklisting in Firefox 33.0.1, I've verified if it works by spoofing video card data on Windows 7 x64, covering HD Graphics 4500HD on all Windows platforms, and all other Intel devices specified in bug 1083298 on Windows 7. Note that we could not actually reproduce the issue, so we cannot verify if blocklisting fixes it.

All devices have D2D, OMTC, and WebGL disabled for driver versions up to 8.15.10.2455, and have them enabled for 8.15.10.2455 version or newer, with the exception of one device: 0x0166 (HD Graphics 4000/2500) seems to have D2D, OMTC, and WebGL enabled for all driver versions. Since 0x0166 was specified in the list from bug 1083298 I'm not sure whether it was left out intentionally or there is some problem with it.

Otherwise, blocklisting works as expected even when using the same profile.

Testing scenario:
1. Created "spoofed-firefox.bat" file with following content:
SET MOZ_GFX_SPOOF_WINDOWS_VERSION=60001
SET MOZ_GFX_SPOOF_VENDOR_ID=0x8086
SET MOZ_GFX_SPOOF_DEVICE_ID=0x0166
SET MOZ_GFX_SPOOF_DRIVER_VERSION=8.15.10.2201
"C:\Mozilla\Firefox\firefox.exe" -p -no-remote
2. Saved the file, opened it to launch Firefox, created a new profile, started Firefox, and verified "about:support" -> Graphics. ---> features were disabled as expected.
3. Closed Firefox, edited "spoofed-firefox.bat" with other values, then restarted Firefox by running "spoofed-firefox.bat", and verified "about:support" each time.

Results:
All driver versions up to 8.15.10.2455 are correctly blocked for D2D, OMTC and WebGL, for all devices, with the exception of 0x0166 (HD Graphics 4000/2500).

Specific results for each device can be found in the following gdoc (lines 109-136): https://docs.google.com/spreadsheets/d/12yEBqNZqaR6_2XbqFrVwRVxt_URjNN3iMmu-GX60Z0Q/edit#gid=0.

Comment 95

[Nicolas Silva [:nical]]

Attachment: Backout the added blacklist entries (if this bug can be detected at runtime)

jrmuizel and bjacob have a solution that would let us fallback to D3D9 at run-time instead of blacklisting, which is better because our current blacklist is conservative and potentially blocks users that could run D3D11. If we go for this solution we'll have to revert the blacklist changes so here is the patch that does that.

Comment 96

[Sylvestre Ledru [:Sylvestre]]

(In reply to Nicolas Silva [:nical] from comment #95)
> jrmuizel and bjacob have a solution that would let us fallback to D3D9 at
> run-time instead of blacklisting, which is better because our current
> blacklist is conservative and potentially blocks users that could run D3D11.
Great, do you have a bug number for this yet?

Comment 97

[Nicolas Silva [:nical]]

(In reply to Sylvestre Ledru [:sylvestre] from comment #96)
> Great, do you have a bug number for this yet?

I expect this will happen in this bug.

Comment 98

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

Attachment: Check if D3D11 works before using it

This works --- this test succeeds on a machine that doesn't suffer from the present bug, and fails on a machine with this driver bug.

Correspondingly, this causes D3D11 to be marked as not available, correctly causing us to use neither D3D11 layers (we then fall back to D3D9 if available), nor D2D (we then fall back to skia/cairo drawing backends).

Comment 99

[Loic]

What's the solution for users who have already switched layers.offmainthreadcomposition.enabled to false to "fix" this bug? (it's was the easiest workaround instead of upgrading drivers when it was possible)

These users are not going to benefit from OMTC in the future.

Comment 100

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8509820 [details] [diff] [review]
Check if D3D11 works before using it

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

::: gfx/thebes/gfxWindowsPlatform.cpp
@@ +311,4 @@
>  #endif
>      RegisterStrongMemoryReporter(new GfxD2DVramReporter());
>  
> +    InitD3D11Devices();

I think this can go away if we call GetDevice() where needed.

@@ +388,4 @@
>          tryD2D = false;
>      }
>  
> +    if (isVistaOrHigher && !safeMode && tryD2D && mD3D11Device) {

I'd like it better if mD3D11Device was wrapped in a function that was called CanUseD3D11Compositor()

Perhaps have that call the other function that call InitD3D11Devices() (GetDevice())

@@ +1498,5 @@
>  }
>  
> +// See bug 1083071. On some drivers, Direct3D 11 CreateShaderResourceView fails
> +// with E_OUTOFMEMORY.
> +static bool DoesD3D11DeviceSupportResourceSharing(ID3D11Device *device, ID3D11DeviceContext *context)

This parameter can go away.

@@ +1586,4 @@
>    }
>  
>    HRESULT hr;
> +  RefPtr<ID3D11DeviceContext> d3d11DeviceContext;

You don't need this anymore.

Comment 101

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

Loic: indeed, for the time being they're not going to be using OMTC, indeed. But eventually, this option (to not use OMTC) will go away, as it is no longer needed (and no longer tested --- which is why we couldn't just fix this bug by disabling OMTC in Firefox 33!). People will then implicitly be moved to OMTC.

Comment 102

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

Attachment: Check if D3D11 works before using it

Comment 103

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

Attachment: Check if D3D11 works before using it

Comment 104

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8509573 [details] [diff] [review]
Backout the added blacklist entries (if this bug can be detected at runtime)

This backs out the previous black listing patch. The hope is that the detection patch will work better.

Comment 105

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

Attachment: Check if D3D11 works before using it (backported to mozilla-release)

Comment 106

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

Try pushes:

mozilla-central patch:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=3b729bcef424

mozilla-release patch:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=2138a2abf034

(Quite curious about the latter because I haven't tested it locally --- cloning mozilla-release on Windows would have taken forever, so I only wrote that patch on Linux).

Comment 107

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8509898 [details] [diff] [review]
Check if D3D11 works before using it (backported to mozilla-release)

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

We're going to take a different approach of not falling back to d3d9 here

Comment 108

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

Attachment: WIP patch falling back to basic in this particular error condition (Unfinished - need to go home - thanks Jeff!)

Comment 109

[Jeff Muizelaar [:jrmuizel]]

Attachment: disable-broken.patch

Comment 110

[Jeff Muizelaar [:jrmuizel]]

https://tbpl.mozilla.org/?tree=Try&rev=7851d90e8a59

Comment 111

[Jeff Muizelaar [:jrmuizel]]

The release version:
https://tbpl.mozilla.org/?tree=Try&rev=4142b4e2044c

Comment 112

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8509573 [details] [diff] [review]
Backout the added blacklist entries (if this bug can be detected at runtime)

Please also backout this change in the branch GECKO330_2014101104_RELBRANCH

For information, 34 beta 2 shipped with this blacklist.

Comment 114

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8509573 [details] [diff] [review]
Backout the added blacklist entries (if this bug can be detected at runtime)

https://hg.mozilla.org/integration/mozilla-inbound/rev/6b733d690a38
https://hg.mozilla.org/releases/mozilla-aurora/rev/e20f28833078
https://hg.mozilla.org/releases/mozilla-beta/rev/31acf5dc33fc
https://hg.mozilla.org/releases/mozilla-release/rev/2d155c792455
https://hg.mozilla.org/releases/mozilla-release/rev/e890ed642ccc

Comment 115

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8507960 [details] [diff] [review]
Hand-pick some HD4000 drivers and add them to the blacklist

This is obsolete now, right? Otherwise, it still needs the version strings fixed.

Comment 116

[Sylvestre Ledru [:Sylvestre]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #111)
> The release version:
> https://tbpl.mozilla.org/?tree=Try&rev=4142b4e2044c
I see some red here (Wr, etc). Are they caused by your changes? Thanks

Comment 117

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

Sylvestre: these tryserver failures seem all to be on jobs that are hidden on TBPL on mozilla-release. My understanding, then, is that they are just permafail on release and we just dont care. That's my best understanding anyway, and explains why we get these failures, which all seem totally unrelated to this patch.

Comment 118

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

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #115)
> Comment on attachment 8507960 [details] [diff] [review]
> Hand-pick some HD4000 drivers and add them to the blacklist
> 
> This is obsolete now, right? Otherwise, it still needs the version strings
> fixed.

Yes, obsolete.

Comment 119

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8509864 [details] [diff] [review]
Check if D3D11 works before using it

OK. thanks guys.

taking it in release and in the GECKO330_2014101104_RELBRANCH branch; Thanks!

Comment 120

[Ryan VanderMeulen [:RyanVM]]

(In reply to Benoit Jacob [:bjacob] from comment #117)
> Sylvestre: these tryserver failures seem all to be on jobs that are hidden
> on TBPL on mozilla-release. My understanding, then, is that they are just
> permafail on release and we just dont care. That's my best understanding
> anyway, and explains why we get these failures, which all seem totally
> unrelated to this patch.

Only the Win7 M1 failures look concerning to me. The rest isn't relevant to mozilla-release (for various reasons).

Comment 121

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

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #120)
> 
> Only the Win7 M1 failures look concerning to me. The rest isn't relevant to
> mozilla-release (for various reasons).

Hmm, this one is audio-related, it's very hard to think of a way that this patch could affect it. It also seems like there is a known intermittent in this test, just with a different error message. I've retriggered a few times...

Comment 122

[Ryan VanderMeulen [:RyanVM]]

(In reply to Benoit Jacob [:bjacob] from comment #121)
> Hmm, this one is audio-related, it's very hard to think of a way that this
> patch could affect it. It also seems like there is a known intermittent in
> this test, just with a different error message. I've retriggered a few
> times...

It's a different failure mode and hit both opt and debug. Seems like a lot of smoke to me.

Comment 123

[Ryan VanderMeulen [:RyanVM]]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #122)
> It's a different failure mode and hit both opt and debug. Seems like a lot
> of smoke to me.

Oh, and bug 1010425 is an Android bug that last hit over a month ago.

Comment 124

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8509997 [details] [diff] [review]
disable-broken.patch

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

::: widget/windows/nsWindow.cpp
@@ +6734,5 @@
>        aHints.AppendElement(LayersBackend::LAYERS_OPENGL);
>      }
> +
> +    ID3D11Device* device = gfxWindowsPlatform::GetPlatform()->GetD3D11Device();
> +    if (device && !DoesD3D11DeviceSupportResourceSharing(device))

I just realized that DoesD3D11DeviceSupportResourceSharing may run every time we create a new window. That isn't really the intent of this patch, so maybe we should do something about it.

Comment 125

[Jeff Muizelaar [:jrmuizel]]

Here's an experiment to avoid changing our minds:
https://tbpl.mozilla.org/?tree=Try&rev=050cf691ebd5

Comment 126

[Jeff Muizelaar [:jrmuizel]]

Sort of pushed to release. https://hg.mozilla.org/releases/mozilla-release/rev/1b2b105a4c54

I should've figured out the failures first...

Comment 127

[Ryan VanderMeulen [:RyanVM]]

Also inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2b05d4e71d11

Comment 128

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

Attachment: NS_ERROR on d3d11 failure, so we would know if that happened on test slaves

The original patch had this NS_ERROR and this got lost in the second version.

In addition to being some that we want in general, this might help us reason about the audio failures, by telling us what code path is being taken there.

Comment 129

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 8510365 [details] [diff] [review]
NS_ERROR on d3d11 failure, so we would know if that happened on test slaves

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

It might be wise to do something stronger than NS_ERORR here so that it ends up in crash reports. But we only want it to show up once.

Would it be better to move this NS_ERROR into the callee so that we get it for both sides?

Comment 130

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

Comment on attachment 8510365 [details] [diff] [review]
NS_ERROR on d3d11 failure, so we would know if that happened on test slaves

Approval Request Comment

Ryan/Sylvestre: this is a trivial patch that might help us reason about the win7 m1 oranges, and that we would want in general.

Comment 131

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

(In reply to Jeff Muizelaar [:jrmuizel] from comment #129)
> Comment on attachment 8510365 [details] [diff] [review]
> NS_ERROR on d3d11 failure, so we would know if that happened on test slaves
> 
> Review of attachment 8510365 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> It might be wise to do something stronger than NS_ERORR here so that it ends
> up in crash reports. But we only want it to show up once.

Agree, would be very useful to annotate crash reports with.

> 
> Would it be better to move this NS_ERROR into the callee so that we get it
> for both sides?

I thought about putting it in the callee, but that was less convenient because there are multiple places where it returns false, although only one of them is known to happen in practice.

Comment 132

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

We are definitely leaking stuff in DoesD3D11DeviceSupportResourceSharing():

DXGI WARNING: Process is terminating. Using simple reporting. Please call ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live Producer at 0x0049B970, Refcount: 2. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: 	Live Object at 0x004D8FE8, Refcount: 2. [ STATE_CREATION WARNING #0: ]
DXGI WARNING: Live                         Object :      1 [ STATE_CREATION WARNING #0: ]

Comment 133

[Bas Schouten (:bas.schouten)]

(In reply to Benoit Jacob [:bjacob] from comment #132)
> We are definitely leaking stuff in DoesD3D11DeviceSupportResourceSharing():
> 
> DXGI WARNING: Process is terminating. Using simple reporting. Please call
> ReportLiveObjects() at runtime for standard reporting. [ STATE_CREATION
> WARNING #0: ]
> DXGI WARNING: Live Producer at 0x0049B970, Refcount: 2. [ STATE_CREATION
> WARNING #0: ]
> DXGI WARNING: 	Live Object at 0x004D8FE8, Refcount: 2. [ STATE_CREATION
> WARNING #0: ]
> DXGI WARNING: Live                         Object :      1 [ STATE_CREATION
> WARNING #0: ]

Are you sure we didn't always get this?

Comment 134

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8509864 [details] [diff] [review]
Check if D3D11 works before using it

Backed out for the previously-noted Win7 mochitest-1 leaks.

https://hg.mozilla.org/integration/mozilla-inbound/rev/3ab73d1619b9
https://hg.mozilla.org/releases/mozilla-release/rev/77e045dd0f7c

Comment 135

[Nicolas Silva [:nical]]

(In reply to Bas Schouten (:bas.schouten) from comment #133)
> Are you sure we didn't always get this?

Does the leak correspond to this? http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.cpp#1498

Comment 136

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

Nical: oh yes, that is definitely it. Jeff also confirmed that the leak occurs without our patch so we were always leaking and the code you're pointing to, intentionally leaking the d3d11 module, is certainly it.

Comment 137

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

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #134)
> Comment on attachment 8509864 [details] [diff] [review]
> Check if D3D11 works before using it
> 
> Backed out for the previously-noted Win7 mochitest-1 leaks.

^ leaks are unconfirmed at this point.

Comment 138

[Jeff Muizelaar [:jrmuizel]]

(In reply to Nicolas Silva [:nical] from comment #135)
> (In reply to Bas Schouten (:bas.schouten) from comment #133)
> > Are you sure we didn't always get this?
> 
> Does the leak correspond to this?
> http://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.
> cpp#1498

That seems likely. We seem to have the leak whether this patch is applied or not.

Comment 139

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/6b733d690a38

Comment 140

[Jeff Muizelaar [:jrmuizel]]

Attachment: Disable D3D11 and D3D9 layers on broken drivers

Comment 141

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

Took Jeff's try build for a test drive on the laptop reproducing the issue. Works as expected. Falls back to Basic layers, skia/cairo drawing backends. WebGL is available (but slow).

Comment 142

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8510497 [details] [diff] [review]
Disable D3D11 and D3D9 layers on broken drivers

https://hg.mozilla.org/integration/mozilla-inbound/rev/6e4cb51583f6
https://hg.mozilla.org/releases/mozilla-aurora/rev/613c2dceebb0
https://hg.mozilla.org/releases/mozilla-beta/rev/618a12c410bb
https://hg.mozilla.org/releases/mozilla-release/rev/bf6c1a1aa45b
https://hg.mozilla.org/releases/mozilla-release/rev/3fdbf5e789d0

Comment 143

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6e4cb51583f6

Comment 145

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Did a quick check on the blocklisting changes backout on Win 7 x64, with 33.0.1 build 2 (BuildID=20141023194920) and everything looks good, as old blocklisting is applied for Intel graphics.

Comment 146

[Lawrence Mandel [:lmandel] (use needinfo)]

Add the following release note for 33.0.1: "Firefox displays a black screen at start-up with certain graphics drivers"

Comment 148

[Sylvestre Ledru [:Sylvestre]]

We don't use the keyword any more but the tracking flags but there is a bug (33 is not available). Reported as bug 1089219

Comment 149

[GMA]

https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24329

Intel has released 10.18.10.3958 WHQL drivers for Ivy Bridge.

Comment 150

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

Attachment: Avoid touching D3D11 at all, even to test if it works, if D3D11 layers are blacklisted

I noticed a little issue in the patch to detect if D3D11 actually works: this is calling into D3D11 (just to check if it works) even if it is already blacklisted. That's taking a needless risk; it would normally be considered a very small risk, but we have apparently some users reporting strange behavior with the earlier patch, and this is the only way that I can think of, that that patch would cause any trouble.

Comment 151

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

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=12f6a2928fa2

Comment 152

[Bas Schouten (:bas.schouten)]

Comment on attachment 8511641 [details] [diff] [review]
Avoid touching D3D11 at all, even to test if it works, if D3D11 layers are blacklisted

I was thinking of the same option so I'm very much in favor of this. And the fact we independently arrived at this idea is promising.

Comment 153

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

Comment on attachment 8511641 [details] [diff] [review]
Avoid touching D3D11 at all, even to test if it works, if D3D11 layers are blacklisted

Approval Request Comment
[Feature/regressing bug #]: See release-drivers thread. The above patch works for some users but causes trouble for other users. We think that the most likely (and perhaps the only) reason why trouble would be caused, is by calling into D3D11 even when it is blacklisted. This patch addresses that.
[User impact if declined]: Bad bugs for some users with old drivers.
[Describe test coverage new/current, TBPL]: n/a
[Risks and why]: no risk, very simple patch, and code mostly copied from elsewhere in this file.
[String/UUID change made/needed]: none

Comment 154

[Robert Kaiser]

(In reply to Benoit Jacob [:bjacob] from comment #150)
> Created attachment 8511641 [details] [diff] [review]
> Avoid touching D3D11 at all, even to test if it works, if D3D11 layers are
> blacklisted

Does this fix the crash in https://crash-stats.mozilla.com/report/list?signature=%400x0%20%7C%20AllocateCB%28void%2A%2C%20_D3DDDICB_ALLOCATE%2A%29 as well? I fear that one is quite huge in 33.0.1 build #2 now (we do see it in Nightly 36 and Aurora 35 as well, FWIW).

Comment 155

[Sylvestre Ledru [:Sylvestre]]

(In reply to Benoit Jacob [:bjacob] from comment #151)
> https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=12f6a2928fa2

I see 22 failed on this url, is that normal? merci

Comment 156

[Ryan VanderMeulen [:RyanVM]]

(In reply to Sylvestre Ledru [:sylvestre] from comment #155)
> (In reply to Benoit Jacob [:bjacob] from comment #151)
> > https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=12f6a2928fa2
> 
> I see 22 failed on this url, is that normal? merci

I went through and classified them. The vast majority were expected fails since this was mozilla-release trying to run tests it was never intended to.

Comment 157

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8511641 [details] [diff] [review]
Avoid touching D3D11 at all, even to test if it works, if D3D11 layers are blacklisted

Both branches on m-r I assume? Also, can we just approve this for Aurora/Beta while we're at it so we can more easily keep track of which patches have landed where?

Comment 158

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8511641 [details] [diff] [review]
Avoid touching D3D11 at all, even to test if it works, if D3D11 layers are blacklisted

Sure. I was doing the most urgent stuff first. it should also land in m-c.

Comment 159

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

(In reply to Robert Kaiser (:[e-mail]) from comment #154)
> (In reply to Benoit Jacob [:bjacob] from comment #150)
> > Created attachment 8511641 [details] [diff] [review]
> > Avoid touching D3D11 at all, even to test if it works, if D3D11 layers are
> > blacklisted
> 
> Does this fix the crash in
> https://crash-stats.mozilla.com/report/
> list?signature=%400x0%20%7C%20AllocateCB%28void%2A%2C%20_D3DDDICB_ALLOCATE%2A
> %29 as well? I fear that one is quite huge in 33.0.1 build #2 now (we do see
> it in Nightly 36 and Aurora 35 as well, FWIW).

These crashes have DoesD3D11DeviceSupportResourceSharing in the stack, which is the "do some D3D11 work to check if it works" function. The new patch in comment 150 prevents this from being run on systems where D3D11 is blacklisted. So if these systems have D3D11 blacklisted, then they will be saved by this patch. If they don't have D3D11 blacklisted, then they should have, because this function really shouldn't crash - it just performs a basic operation that the D3D11 OMTC compositor has to perform all the time.

Comment 160

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

Hmm, I see, the overwhelming majority of these crashes is with old NVIDIA driver versions. What makes me nervous here is that there are a lot of crashes with NVIDIA driver version *1.8593 which corresponds to the commercial version number 185.93, which is old but just recent enough that we don't blacklist it --- our current cutoff is at version 182.65, which is just below it.

 http://hg.mozilla.org/releases/mozilla-release/file/tip/widget/windows/GfxInfo.cpp#l856

This means that we should probably raise the minimum NVIDIA driver version requirement by a notch for D3D11 layers. Patch coming over the next hour, hopefully in time for the next build.

Comment 161

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8511641 [details] [diff] [review]
Avoid touching D3D11 at all, even to test if it works, if D3D11 layers are blacklisted

https://hg.mozilla.org/integration/mozilla-inbound/rev/4d4abe4bee7f
https://hg.mozilla.org/releases/mozilla-aurora/rev/65f38304cc6e
https://hg.mozilla.org/releases/mozilla-beta/rev/6268e33e8351
https://hg.mozilla.org/releases/mozilla-release/rev/c771ec2d6302
https://hg.mozilla.org/releases/mozilla-release/rev/e4f020cdef25

Comment 162

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8511641 [details] [diff] [review]
Avoid touching D3D11 at all, even to test if it works, if D3D11 layers are blacklisted

gfxWindowsPlatform::InitD3D11Devices() is void on trunk/aurora, so returning a nullptr makes the compiler unhappy :). Backed out and relanded with a plain return instead.

https://hg.mozilla.org/integration/mozilla-inbound/rev/095cbdd41f21
https://hg.mozilla.org/releases/mozilla-aurora/rev/38ef8541c3fc

Comment 163

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

Oh, I think trunk/aurora are quite different in that they have a separate InitD3D11Device function, so I wasn't intending for this patch to land there before I could look at porting it.

I am looking closely at the driver versions in Robert's crash-stats link above, it's taking me time to figure what would be the correct blacklisting rule, not sure I'll have something in time for a build tonight, still trying.

Comment 164

[Ryan VanderMeulen [:RyanVM]]

Treeherder seems to be OK with what landed on Trunk/Aurora. Do you want me to backout or just let it go at this point?

Comment 165

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

OK, given treeherder is OK with this patch, you can let it go for now, we'll probably take a look at forward-porting a few patches this week, so we'll double check this then.

Comment 166

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

The crash reported in comment 154 has been filed as bug 1089413 and is now being investigated there.

Comment 167

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/095cbdd41f21

Comment 169

[Arthur K. (he/him)]

Intel 15.36.8.64.3977 drivers are now floating around.

Comment 170

[Ben]

After updating from 33.0.1 to 33.0.2, Direct2D/DirectWrite/OMTC11 are disabled and firefox falls back to OMTC9 without Direct2D. I can't even force Direct2D like before.

It is working on 33.0.1 without any problems by using this settings:

gfx.direct2d.force-enabled	        true
gfx.font_rendering.directwrite.enabled	true
layers.acceleration.force-enabled	true

User-Agent 	Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0

Direct2D aktiviert	true
DirectWrite aktiviert	true (6.3.9600.17111)
Geräte-ID	0x2a02
GPU #2 aktiv	false
GPU-beschleunigte Fenster	1/1 Direct3D 11 (OMTC)
Karten-Beschreibung	Mobile Intel(R) 965 Express Chipset Family (Microsoft Corporation - WDDM 1.1)
Karten-RAM	Unknown
Karten-Treiber	igdumd64 igd10umd64 igdumd32 igd10umd32
Treiber-Datum	10-1-2012
Treiber-Version	8.15.10.2697
Vendor-ID	0x8086
WebGL-Renderer	Google Inc. -- ANGLE (Mobile Intel(R) 965 Express Chipset Family (Microsoft Corporation - WDDM 1.1) Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote	true
AzureCanvasBackend	direct2d
AzureContentBackend	direct2d
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

I'm using the newest graphic driver version I can get from Intel/WindowsUpdate.

Comment 171

[Arthur K. (he/him)]

(In reply to Ben from comment #170)
> After updating from 33.0.1 to 33.0.2, Direct2D/DirectWrite/OMTC11 are
> disabled and firefox falls back to OMTC9 without Direct2D. I can't even
> force Direct2D like before.
> 
> It is working on 33.0.1 without any problems by using this settings:
> 
> gfx.direct2d.force-enabled	        true
> gfx.font_rendering.directwrite.enabled	true
> layers.acceleration.force-enabled	true
> 
> User-Agent 	Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101
> Firefox/33.0
> 
> Direct2D aktiviert	true
> DirectWrite aktiviert	true (6.3.9600.17111)
> Geräte-ID	0x2a02
> GPU #2 aktiv	false
> GPU-beschleunigte Fenster	1/1 Direct3D 11 (OMTC)
> Karten-Beschreibung	Mobile Intel(R) 965 Express Chipset Family (Microsoft
> Corporation - WDDM 1.1)
> Karten-RAM	Unknown
> Karten-Treiber	igdumd64 igd10umd64 igdumd32 igd10umd32
> Treiber-Datum	10-1-2012
> Treiber-Version	8.15.10.2697
> Vendor-ID	0x8086
> WebGL-Renderer	Google Inc. -- ANGLE (Mobile Intel(R) 965 Express Chipset
> Family (Microsoft Corporation - WDDM 1.1) Direct3D9Ex vs_3_0 ps_3_0)
> windowLayerManagerRemote	true
> AzureCanvasBackend	direct2d
> AzureContentBackend	direct2d
> AzureFallbackCanvasBackend	cairo
> AzureSkiaAccelerated	0
> 
> I'm using the newest graphic driver version I can get from
> Intel/WindowsUpdate.

I did not think Win8.1 even worked on the i965 chipset. That is way too old (2006 era) and no surprise Firefox is not working with those WDDM1.1 drivers. The most current drivers for that series (15.12.75.4.64.1930) Win7 date back to 2009 and are for Win7. No on can realistically expect it to be working right.

Comment 172

[Ben]

It's okay that firefox isn't working out of the box by using default settings. It's working on 33.0.1 by using the force-commands, but in the 33.0.2 update something changed (blacklist?) so firefox seems to ignore these commands.

Comment 173

[Joell Lapitan]

will this guide work?

http://techdows.com/2014/05/fix-firefox-nightly-shows-black-screen-after-installing-the-update.html

Comment 174

[Sylvestre Ledru [:Sylvestre]]

(In reply to Joell Lapitan from comment #173)
> http://techdows.com/2014/05/fix-firefox-nightly-shows-black-screen-after-
> installing-the-update.html
It should but it is not recommended. Instead, update to 33.0.2.

Comment 175

[Nicolas Silva [:nical]]

(In reply to Ben from comment #172)
> It's okay that firefox isn't working out of the box by using default
> settings. It's working on 33.0.1 by using the force-commands, but in the
> 33.0.2 update something changed (blacklist?) so firefox seems to ignore
> these commands.

I am not sure I understand your situation: Are you experiencing the black screen issue on 33.0.2 (or some other rendering problem) with the default settings?
Or is the problem that you can't enable D3D11 and D2D any more? If it is the latter it means that the initialization code detected a problem with the driver on D3D11 so you really don't want D3D11 compositing in this case (it'd be too broken in its current form).

Comment 176

[Arthur K. (he/him)]

(In reply to Nicolas Silva [:nical] from comment #175)
> (In reply to Ben from comment #172)
> > It's okay that firefox isn't working out of the box by using default
> > settings. It's working on 33.0.1 by using the force-commands, but in the
> > 33.0.2 update something changed (blacklist?) so firefox seems to ignore
> > these commands.
> 
> I am not sure I understand your situation: Are you experiencing the black
> screen issue on 33.0.2 (or some other rendering problem) with the default
> settings?
> Or is the problem that you can't enable D3D11 and D2D any more? If it is the
> latter it means that the initialization code detected a problem with the
> driver on D3D11 so you really don't want D3D11 compositing in this case
> (it'd be too broken in its current form).

This user's driver is WDDM 1.1 which means it is generic/failsafe and isn't supporting, quite frankly, anything much less the device (i965) or its features. He's using too high a version of Windows for this hardware. You're chasing your tail on this particular one.

Comment 177

[Ben]

I have no blackscreen/rendering issues. But after updating from 33.0.1 to 33.0.2 I can't enable/force D3D11 and D2D anymore. I now use "SET MOZ_GFX_SPOOF_DRIVER_VERSION=0" and D3D11/D2D is working again without any problems. I think by using this workaround my problem is solved.

Comment 178

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

This morning Firefox updated on a laptop at home to 33.0.2 and now the Black window shows at startup. Apparently it has a dual GPU setup: Intel 4000 + some Radeon card. I didn't spend much time to check out exactly what cards they are and what drivers are used, but I will not update the drivers so I can provide additional details and help with this.

Let me know here or on IRC (if I'm available) if you need anything from me. Note that I'll likely be very slow to respond over the weekend.

Comment 180

[fijam7]

I also have a laptop with dual graphics (Intel + AMD HD 8570M) and after updating Firefox from 32 to 33.0.2 I get the solid black window when the device uses the AMD GPU. I will post the driver details in a few hours.

Unfortunately, dual graphics laptops can rarely use upstream drivers directly from Intel/AMD, this kind of setup usually requires a special 2-in-1 driver rolled by the OEM and in my case no newer version is available (Samsung).

Comment 181

[Loic]

(In reply to opod from comment #180)
> Unfortunately, dual graphics laptops can rarely use upstream drivers
> directly from Intel/AMD, this kind of setup usually requires a special
> 2-in-1 driver rolled by the OEM and in my case no newer version is available
> (Samsung).

I have an Asus laptop with dual graphics (Intel/Nvidia) and I have no issue to update each driver separately. It's only an issue with some OEMs, like Samsung or Toshiba e.g., who provide custom drivers, leaving their customers with outdated drivers when the support has been interrupted, even if the graphics card manufacturers are still providing recent drivers.

My advice is to avoid these OEMs when you buy a laptop. ;)

Comment 182

[Arthur K. (he/him)]

(In reply to opod from comment #180)
> I also have a laptop with dual graphics (Intel + AMD HD 8570M) and after
> updating Firefox from 32 to 33.0.2 I get the solid black window when the
> device uses the AMD GPU. I will post the driver details in a few hours.
> 
> Unfortunately, dual graphics laptops can rarely use upstream drivers
> directly from Intel/AMD, this kind of setup usually requires a special
> 2-in-1 driver rolled by the OEM and in my case no newer version is available
> (Samsung).

I've worked on laptops with these dual VGA setups and I've not had issues installing each driver separately. They are, after all, mutually exclusive silicon no different than having an HD3000 with a Geforce 210 installed. In this case, I wonder if it is detecting the ATI first but the Intel VGA has one of the older blacklisted drivers or some vice versa?

Comment 183

[fijam7]

>My advice is to avoid these OEMs when you buy a laptop. ;)

Thanks a bunch.

> In this case, I wonder if it is detecting the ATI first but the Intel VGA has
> one of the older blacklisted drivers or some vice versa?

I suspect the AMD driver is causing troubles, as it seems to work on battery power (Intel GPU): about:support https://bug1092091.bugzilla.mozilla.org/attachment.cgi?id=8514886

Comment 184

[Arthur K. (he/him)]

(In reply to opod from comment #183)
> >My advice is to avoid these OEMs when you buy a laptop. ;)
> 
> Thanks a bunch.
> 
> > In this case, I wonder if it is detecting the ATI first but the Intel VGA has
> > one of the older blacklisted drivers or some vice versa?
> 
> I suspect the AMD driver is causing troubles, as it seems to work on battery
> power (Intel GPU): about:support
> https://bug1092091.bugzilla.mozilla.org/attachment.cgi?id=8514886

I wonder if you can sneak past Samsung's driver kludge with these: http://goo.gl/mlJcnR

Comment 185

[Arthur K. (he/him)]

(In reply to opod from comment #183)
> >My advice is to avoid these OEMs when you buy a laptop. ;)
> 
> Thanks a bunch.
> 
> > In this case, I wonder if it is detecting the ATI first but the Intel VGA has
> > one of the older blacklisted drivers or some vice versa?
> 
> I suspect the AMD driver is causing troubles, as it seems to work on battery
> power (Intel GPU): about:support
> https://bug1092091.bugzilla.mozilla.org/attachment.cgi?id=8514886

Could post the Graphics section in about:support so we can see your driver versions?

Comment 186

[fijam7]

(In reply to Arthur K. from comment #185)
> (In reply to opod from comment #183)
> > >My advice is to avoid these OEMs when you buy a laptop. ;)
> > 
> > Thanks a bunch.
> > 
> > > In this case, I wonder if it is detecting the ATI first but the Intel VGA has
> > > one of the older blacklisted drivers or some vice versa?
> > 
> > I suspect the AMD driver is causing troubles, as it seems to work on battery
> > power (Intel GPU): about:support
> > https://bug1092091.bugzilla.mozilla.org/attachment.cgi?id=8514886
> 
> Could post the Graphics section in about:support so we can see your driver
> versions?

I'll post the AMD driver version once I return home.

Comment 187

[jerryj]

Well, congratulations Mozilla -- you guys just shot yourself in the foot, again, badly!!

My Firefox just upgraded to 33.0.2 and now <canvas> performance for me is very bad -- because apparently, you blacklisted my video driver (for the OMTC issue), and the GPU is no longer used for <canvas>.  Under 33.0, <canvas> was GPU accelerated, but now under 33.0.2, slow as ever.

So rather than disable *only* OMTC based upon video driver problems, you take the sledgehammer approach, and disable the GPU for *everything*, including <canvas>, making Firefox unusable for me.  Time to move on...

-1

Comment 188

[Arthur K. (he/him)]

(In reply to jerryj from comment #187)
> Well, congratulations Mozilla -- you guys just shot yourself in the foot,
> again, badly!!
> 
> My Firefox just upgraded to 33.0.2 and now <canvas> performance for me is
> very bad -- because apparently, you blacklisted my video driver (for the
> OMTC issue), and the GPU is no longer used for <canvas>.  Under 33.0,
> <canvas> was GPU accelerated, but now under 33.0.2, slow as ever.
> 
> So rather than disable *only* OMTC based upon video driver problems, you
> take the sledgehammer approach, and disable the GPU for *everything*,
> including <canvas>, making Firefox unusable for me.  Time to move on...
> 
> -1

Are you able to post your driver details from about:config?

Comment 189

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #178)
> This morning Firefox updated on a laptop at home to 33.0.2 and now the Black
> window shows at startup. Apparently it has a dual GPU setup: Intel 4000 +
> some Radeon card. I didn't spend much time to check out exactly what cards
> they are and what drivers are used, but I will not update the drivers so I
> can provide additional details and help with this.
> 
> Let me know here or on IRC (if I'm available) if you need anything from me.
> Note that I'll likely be very slow to respond over the weekend.

This is a Lenovo running Win 7 x86 with switchable graphics:
- Intel HD Graphics 4000 - driver v9.17.10.3114
- AMD Radeon HD 8570M - driver v12.100.14.0

Graphics (info picked from Firefox 32)
Adapter Description	Intel(R) HD Graphics 4000
Adapter Drivers	igdumd32 igd10umd32 igd10umd32
Adapter RAM	Unknown
Device ID	0x0166
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.16492)
Driver Date	4-17-2013
Driver Version	9.17.10.3114
GPU #2 Active	false
GPU Accelerated Windows	1/1 Direct3D 10
Vendor ID	0x8086
WebGL Renderer	Google Inc. -- ANGLE (Intel(R) HD Graphics 4000 Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote	false
AzureCanvasBackend	direct2d
AzureContentBackend	direct2d
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

Important Modified Preferences
Name 	Value 
accessibility.typeaheadfind.flashBar	0
browser.cache.disk.capacity	358400
browser.cache.disk.smart_size_cached_value	358400
browser.cache.disk.smart_size.first_run	false
browser.cache.disk.smart_size.use_old_max	false
browser.cache.frecency_experiment	2
browser.newtab.url	chrome://quick_start/content/index.html
browser.places.smartBookmarksVersion	7
browser.search.useDBForOrder	false
browser.sessionstore.upgradeBackup.latestBuildID	20140825202822
browser.startup.homepage	http://www.google.ro/
browser.startup.homepage_override.buildID	20140825202822
browser.startup.homepage_override.mstone	32.0
browser.tabs.closeWindowWithLastTab	false
browser.tabs.warnOnClose	false
dom.mozApps.used	true
extensions.lastAppVersion	32.0
font.internaluseonly.changed	false
gfx.direct3d.last_used_feature_level_idx	0
keyword.URL	
media.gmp-gmpopenh264.lastUpdate	1414735681
media.gmp-gmpopenh264.version	1.1
media.gmp-manager.lastCheck	1414735680
network.cookie.prefsMigrated	true
places.database.lastMaintenance	1414736792
places.history.expiration.transient_current_max_pages	78194
plugin.disable_full_page_plugin_for_types	application/pdf
plugin.importedState	true
plugin.state.java	2
privacy.sanitize.migrateFx3Prefs	true
storage.vacuum.last.index	1
storage.vacuum.last.places.sqlite	1412352352

Comment 190

[Arthur K. (he/him)]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #189)
> (In reply to Florin Mezei, QA (:FlorinMezei) from comment #178)
> > This morning Firefox updated on a laptop at home to 33.0.2 and now the Black
> > window shows at startup. Apparently it has a dual GPU setup: Intel 4000 +
> > some Radeon card. I didn't spend much time to check out exactly what cards
> > they are and what drivers are used, but I will not update the drivers so I
> > can provide additional details and help with this.
> > 
> > Let me know here or on IRC (if I'm available) if you need anything from me.
> > Note that I'll likely be very slow to respond over the weekend.
> 
> This is a Lenovo running Win 7 x86 with switchable graphics:
> - Intel HD Graphics 4000 - driver v9.17.10.3114
> - AMD Radeon HD 8570M - driver v12.100.14.0
> 
> Graphics (info picked from Firefox 32)
> Adapter Description	Intel(R) HD Graphics 4000
> Adapter Drivers	igdumd32 igd10umd32 igd10umd32
> Adapter RAM	Unknown
> Device ID	0x0166
> Direct2D Enabled	true
> DirectWrite Enabled	true (6.2.9200.16492)
> Driver Date	4-17-2013
> Driver Version	9.17.10.3114
> GPU #2 Active	false
> GPU Accelerated Windows	1/1 Direct3D 10
> Vendor ID	0x8086
> WebGL Renderer	Google Inc. -- ANGLE (Intel(R) HD Graphics 4000 Direct3D9Ex
> vs_3_0 ps_3_0)
> windowLayerManagerRemote	false
> AzureCanvasBackend	direct2d
> AzureContentBackend	direct2d
> AzureFallbackCanvasBackend	cairo
> AzureSkiaAccelerated	0
> 
> Important Modified Preferences
> Name 	Value 
> accessibility.typeaheadfind.flashBar	0
> browser.cache.disk.capacity	358400
> browser.cache.disk.smart_size_cached_value	358400
> browser.cache.disk.smart_size.first_run	false
> browser.cache.disk.smart_size.use_old_max	false
> browser.cache.frecency_experiment	2
> browser.newtab.url	chrome://quick_start/content/index.html
> browser.places.smartBookmarksVersion	7
> browser.search.useDBForOrder	false
> browser.sessionstore.upgradeBackup.latestBuildID	20140825202822
> browser.startup.homepage	http://www.google.ro/
> browser.startup.homepage_override.buildID	20140825202822
> browser.startup.homepage_override.mstone	32.0
> browser.tabs.closeWindowWithLastTab	false
> browser.tabs.warnOnClose	false
> dom.mozApps.used	true
> extensions.lastAppVersion	32.0
> font.internaluseonly.changed	false
> gfx.direct3d.last_used_feature_level_idx	0
> keyword.URL	
> media.gmp-gmpopenh264.lastUpdate	1414735681
> media.gmp-gmpopenh264.version	1.1
> media.gmp-manager.lastCheck	1414735680
> network.cookie.prefsMigrated	true
> places.database.lastMaintenance	1414736792
> places.history.expiration.transient_current_max_pages	78194
> plugin.disable_full_page_plugin_for_types	application/pdf
> plugin.importedState	true
> plugin.state.java	2
> privacy.sanitize.migrateFx3Prefs	true
> storage.vacuum.last.index	1
> storage.vacuum.last.places.sqlite	1412352352

Likely the ATI card. 12.102.1.8000 is available for that 8570M: http://goo.gl/mlJcnR and also Intel HD 4000 is now up to 10.18.10.3958. See if updating one or both helps.

Comment 191

[Francesco Lodolo [:flod]]

Reporting from one of our users (local support forum in Italian): black screen only after update to 33.0.2, before it worked fine.

HP ProBook 4740s. Based on Google it should have a dual graphic card, but about:support Graphics only shows the Intel one (text is in Italian but should be easy to read).

Data aggiornamento driver   5-16-2014
Descrizione scheda grafica   Intel(R) HD Graphics 4000
DirectWrite attivo   false (6.3.9600.17111)
Driver scheda grafica   igdumdim64 igd10iumd64 igd10iumd64 igdumdim32 igd10iumd32 igd10iumd32
Finestre con accelerazione GPU   0/1 Basic (OMTC)
GPU #2 attiva   false
ID dispositivo   0x0166
ID produttore   0x8086
RAM scheda grafica   Unknown
Rendering WebGL   Google Inc. -- ANGLE (Intel(R) HD Graphics 4000 Direct3D9Ex vs_3_0 ps_3_0)
Versione driver   10.18.10.3621
windowLayerManagerRemote   true
AzureCanvasBackend   skia
AzureContentBackend   cairo
AzureFallbackCanvasBackend   cairo
AzureSkiaAccelerated   0

Comment 193

[fijam7]

(In reply to opod from comment #186)
> (In reply to Arthur K. from comment #185)
> > Could post the Graphics section in about:support so we can see your driver
> > versions?
> 
> I'll post the AMD driver version once I return home.

AMD driver version 13.152.0.0 from 8/30/2013

Comment 194

[Arthur K. (he/him)]

(In reply to opod from comment #193)
> (In reply to opod from comment #186)
> > (In reply to Arthur K. from comment #185)
> > > Could post the Graphics section in about:support so we can see your driver
> > > versions?
> > 
> > I'll post the AMD driver version once I return home.
> 
> AMD driver version 13.152.0.0 from 8/30/2013

2013 isn't too old of a driver version to be honest but to rule out it being the cause, updating it, if possible, would be advisable. I don't know if it'll help you but I saw an interesting tool released by AMD called "AMD Driver Autodetect" and you can get it from AMD's site here: http://goo.gl/C56AP7
Give it a shot and see what it says about your setup.

Comment 195

[kaz]

I see this issue on a Windows 7 (32 bit) Sony VAIO Laptop with Intel graphic chips.

It is not on startup, but shows up after some time. The UI goes black (the interior of every Firefox window, including the title bar with the minimize, maximize and close buttons). If you know where the UI elements are such as Cancel buttons, you can still interact with the UI.

The computer is localized to Japanese, so the about:support info is Japanese.

Note that hardware acceleration is set to OFF in tools->options->advanced.

Using about:config I also tried disabling layers acceleration.

Also, the "layers.offmainthreadcomposition.enable = false" doesn't work. I found that flag already to be false.

Here is the about:support text dump:


アプリケーション基本情報
------------

名前: Firefox
バージョン: 32.0.3
ユーザエージェント: Mozilla/5.0 (Windows NT 6.1; rv:32.0) Gecko/20100101 Firefox/32.0

過去 3 日分のクラッシュレポート
-----------------

レポート ID: bp-43f1fa23-f5ca-4b9f-8af9-a74a82141011
送信日時: 1 日前

すべてのクラッシュレポート (10 件の未送信のクラッシュを含む)

拡張機能
----

名前: Adblock Plus
バージョン: 2.6.4
有効: true
ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

名前: Brief
バージョン: 1.7.3
有効: true
ID: [e-mail]

名前: Moji
バージョン: 1.0.3
有効: true
ID: {ea9be299-129b-4c3c-8876-d98c18c2fd39}

名前: Moji-En
バージョン: 1.1.20110109
有効: true
ID: {C4A808D2-254E-4039-832A-C75B72FBA2DA}

名前: Moji-JpNam
バージョン: 1.1.20110109
有効: true
ID: {C631EB1C-4A6D-490e-A226-0D6FAD02C01C}

名前: Moji-Kanji-En
バージョン: 0.6.20071013
有効: true
ID: {9E1A1CD4-8916-4951-AAB4-2D4497FDFD90}

名前: NoScript
バージョン: 2.6.9
有効: true
ID: {73a6fe31-595d-460b-a920-fcc0f8843232}

名前: Restart
バージョン: 1.2.1
有効: true
ID: [e-mail]

名前: Skype Click to Call
バージョン: 7.3.16540.9015
有効: true
ID: {82AF8DCA-6DE9-405D-BD5E-43525BDAD38A}

グラフィックス
-------

Direct2D 有効: true
DirectWrite 有効: true (6.2.9200.16571)
GPU #2 の使用: false
GPU 描画支援のウィンドウ: 1/1 Direct3D 10
WebGL レンダラ: Google Inc. -- ANGLE (Mobile Intel(R) 4 Series Express Chipset Family Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: false
アダプタ RAM: Unknown
アダプタドライバ: igdumdx32 igd10umd32
アダプタ名: Mobile Intel(R) 4 Series Express Chipset Family
デバイス ID: 0x2a42
ドライバのバージョン: 8.15.10.2869
ドライバの日付: 10-4-2012
ベンダ ID: 0x8086
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

変更された重要な設定
----------

accessibility.typeaheadfind.casesensitive: 1
accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 358400
browser.cache.disk.smart_size_cached_value: 358400
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 1
browser.display.background_color: #C0C0C0
browser.display.use_system_colors: true
browser.places.smartBookmarksVersion: 7
browser.sessionstore.upgradeBackup.latestBuildID: 20140923175406
browser.startup.homepage: http://jp.msn.com/?pc=UP97&ocid=UP97DHP
browser.startup.homepage_override.buildID: 20140923175406
browser.startup.homepage_override.mstone: 32.0.3
dom.max_chrome_script_run_time: 40
dom.max_script_run_time: 40
dom.mozApps.used: true
dom.w3c_touch_events.expose: false
extensions.lastAppVersion: 32.0.3
gfx.direct2d.disabled: true
gfx.direct3d.last_used_feature_level_idx: 1
keyword.URL: http://www.bing.com/search?FORM=UP97DF&PC=UP97&q=
layers.acceleration.disabled: true
network.cookie.prefsMigrated: true
places.database.lastMaintenance: 1413079480
places.history.expiration.transient_current_max_pages: 50202
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
plugin.state.java: 0
plugin.state.npbtdna: 0
plugin.state.npdeployjava: 0
plugin.state.npwpf: 0
privacy.sanitize.migrateFx3Prefs: true
security.enable_ssl2: true
security.warn_viewing_mixed: false
storage.vacuum.last.brief.sqlite: 1411276041
storage.vacuum.last.index: 2
storage.vacuum.last.places.sqlite: 1411495459

JavaScript
----------

インクリメンタル GC: true

アクセシビリティ
--------

有効: false
アクセシビリティを無効にする: 0

ライブラリのバージョン
-----------

NSPR
想定される最低バージョン: 4.10.6
使用中のバージョン: 4.10.6

NSS
想定される最低バージョン: 3.16.5 Basic ECC
使用中のバージョン: 3.16.5 Basic ECC

NSSSMIME
想定される最低バージョン: 3.16.5 Basic ECC
使用中のバージョン: 3.16.5 Basic ECC

NSSSSL
想定される最低バージョン: 3.16.5 Basic ECC
使用中のバージョン: 3.16.5 Basic ECC

NSSUTIL
想定される最低バージョン: 3.16.5
使用中のバージョン: 3.16.5

実験的な機能
------

Comment 196

[Fernando Hartmann]

A dump question...
There is a way to detect the black screen, include the driver dynamically in the black list, and warning the user about a needed driver upgrade ?

Comment 197

[Nicolas Silva [:nical]]

(In reply to Fernando Hartmann from comment #196)
> A dump question...
> There is a way to detect the black screen, include the driver dynamically in
> the black list, and warning the user about a needed driver upgrade ?

We already have a way to detect some of the symptoms of the black screen issues (apparently not all of them yet). We don't have a way to warn users about their drivers being out of date although we'll discuss that soon enough. Right now we are focusing on fixing the bugs and we can add warnings later.

Comment 198

[Jeff Muizelaar [:jrmuizel]]

Florin,

Can you check if Nightly also gives a black screen? It would be interesting to know if any updates or changes to the drivers cause any changes.

Comment 199

[Jeff Muizelaar [:jrmuizel]]

Here's a debugging build that should help us get more information about the problem:

https://tbpl.mozilla.org/?tree=Try&rev=294561e67f20

If you could run this and give the output of stdout.

Also if you get DebugView (http://technet.microsoft.com/en-ca/sysinternals/bb896647.aspx)

Run that as Administrator and turn on Global logging and see if you get any d3d related messages.

Comment 200

[fijam7]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #199)
> Here's a debugging build that should help us get more information about the
> problem:
> 
> https://tbpl.mozilla.org/?tree=Try&rev=294561e67f20
> 
> If you could run this and give the output of stdout.
> 
> Also if you get DebugView
> (http://technet.microsoft.com/en-ca/sysinternals/bb896647.aspx)
> 
> Run that as Administrator and turn on Global logging and see if you get any
> d3d related messages.

I'm the guy with dual graphics setup and AMD drivers version 13.152.0.0 from 8/30/2013 running W8.1 x64. 

I just tried the nightly build and it works both on AC and battery power! Thank you for fixing this.

The DebugView only spits out:

[5184] D3D11CreateDevice: Flags (0x2) were specified which require the D3D11 SDK Layers for Windows 8.1, but they are not present on the system.
[5184] These flags must be removed, or the Windows 8.1 SDK must be installed.
[1120] Flags include: D3D11_CREATE_DEVICE_DEBUG

I have a separate problem with Firefox hogging 100% GPU (http://i.imgur.com/xnBzrIS.png) but that would happen before (at least in 32.0) so I will file a separate bug report for that.

Comment 201

[fijam7]

I figured I probably need the SDK thing for the debug flags to work (sorry, just a biologist here) so I will try to install that and check the DebugView again.

Comment 202

[Jeff Muizelaar [:jrmuizel]]

(In reply to opod from comment #200)
> I'm the guy with dual graphics setup and AMD drivers version 13.152.0.0 from
> 8/30/2013 running W8.1 x64. 
> 
> I just tried the nightly build and it works both on AC and battery power!
> Thank you for fixing this.

Did you try a regular nightly build or the build I linked to?

If it was a regular nightly can you try setting the gfx.direct2d.use1_1 to false in about:config and restarting to see if the black comes back?

Comment 203

[fijam7]

Looks like I opened the champagne a bit too early. Before and now I used the build you linked to. However, with the SDK installed, Nightly hangs the same way as FF33.0.2. I have uploaded the log from DebugView here: http://pastebin.mozilla.org/7093469  Hope that will be helpful.

Comment 204

[Jeff Muizelaar [:jrmuizel]]

It feels like this is probably the reason for the black:

00000003        1.89907873      [192] D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets: Resource being set to OM RenderTarget slot 0 is inaccessible because of a previous call to ReleaseSync or GetDC. [ STATE_SETTING WARNING #9: DEVICE_OMSETRENDERTARGETS_HAZARD]

Comment 205

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #204)
> It feels like this is probably the reason for the black:
> 
> 00000003        1.89907873      [192] D3D11 WARNING:
> ID3D11DeviceContext::OMSetRenderTargets: Resource being set to OM
> RenderTarget slot 0 is inaccessible because of a previous call to
> ReleaseSync or GetDC. [ STATE_SETTING WARNING #9:
> DEVICE_OMSETRENDERTARGETS_HAZARD]

If you try Nightly firefox from here: https://nightly.mozilla.org/ what do you see?

Comment 206

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #205)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #204)
> > It feels like this is probably the reason for the black:
> > 
> > 00000003        1.89907873      [192] D3D11 WARNING:
> > ID3D11DeviceContext::OMSetRenderTargets: Resource being set to OM
> > RenderTarget slot 0 is inaccessible because of a previous call to
> > ReleaseSync or GetDC. [ STATE_SETTING WARNING #9:
> > DEVICE_OMSETRENDERTARGETS_HAZARD]
> 
> If you try Nightly firefox from here: https://nightly.mozilla.org/ what do
> you see?

Also worth playing with the gfx.direct2d.disabled pref to see if it makes a difference.

Comment 207

[fijam7]

I downloaded the Nightly 36.0a1. I am no longer getting errors in debug view, I assume that is expected as that build has no debug flags?

Anyway
default settings:
 36.0a1 on battery power - black window
 36.0a1 on AC power - works

gfx.direct2d.use1_1 = false
 36.0a1 on battery power - black window
 36.0a1 on AC power - works

Regarding "[192] D3D11 WARNING: ID3D11DeviceContext::OMSetRenderTargets: Resource being set to OM RenderTarget slot 0 is inaccessible" I also launched the build you provided on battery power (which works) and got the following log (which also includes those warnings): http://pastebin.mozilla.org/7093588

It's already midnight here, I will pick up tomorrow.

http://pastebin.mozilla.org/7093588

gfx.direct2d.disabled = true
 36.0a1 on battery power - works
 36.0a1 on AC power - works

Comment 208

[Ryan VanderMeulen [:RyanVM]]

Thanks for all your help so far!

Comment 209

[fijam7]

Sorry, the comment got mangled. I should really go to sleep. What it should say is: (battery and AC is switched around, on AC it's AMD graphics)

Anyway
default settings:
 36.0a1 on battery power - works
 36.0a1 on AC power - black window

gfx.direct2d.use1_1 = false
 36.0a1 on battery power - works
 36.0a1 on AC power - black window

gfx.direct2d.disabled = true
 36.0a1 on battery power - works
 36.0a1 on AC power - works

Comment 210

[Arthur K. (he/him)]

(In reply to opod from comment #200)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #199)
> > Here's a debugging build that should help us get more information about the
> > problem:
> > 
> > https://tbpl.mozilla.org/?tree=Try&rev=294561e67f20
> > 
> > If you could run this and give the output of stdout.
> > 
> > Also if you get DebugView
> > (http://technet.microsoft.com/en-ca/sysinternals/bb896647.aspx)
> > 
> > Run that as Administrator and turn on Global logging and see if you get any
> > d3d related messages.
> 
> I'm the guy with dual graphics setup and AMD drivers version 13.152.0.0 from
> 8/30/2013 running W8.1 x64. 
> 
> I just tried the nightly build and it works both on AC and battery power!
> Thank you for fixing this.
> 
> The DebugView only spits out:
> 
> [5184] D3D11CreateDevice: Flags (0x2) were specified which require the D3D11
> SDK Layers for Windows 8.1, but they are not present on the system.
> [5184] These flags must be removed, or the Windows 8.1 SDK must be installed.
> [1120] Flags include: D3D11_CREATE_DEVICE_DEBUG
> 
> I have a separate problem with Firefox hogging 100% GPU
> (http://i.imgur.com/xnBzrIS.png) but that would happen before (at least in
> 32.0) so I will file a separate bug report for that.

From comment 194, see if AMD's Autodetect Tool can help you. Maybe a newer driver can fix the GPU hogging.

Comment 211

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #198)
> Florin,
> 
> Can you check if Nightly also gives a black screen? It would be interesting
> to know if any updates or changes to the drivers cause any changes.

I managed to test this at home this morning, and Nightly from November 3rd was still showing the black window. I tried just the default settings with AC power. I don't know if it's a good idea to update the drivers, as it may be more useful to keep the current configuration so I can validate any potential fixes here. 

From what I understand the problem here is that the switchable graphics system uses the Intel GPU for low performance applications (like browsing), but uses the AMD GPU for more intense jobs, like gaming. I guess I could also play with these settings a bit and see how it affects us.

When I get back home I'll try to get some debug data as well. Sorry for the late response but I'm on the Europe timezone and don't always get the time to work on this at home.

Comment 212

[fijam7]

(In reply to Arthur K. from comment #210)
> (In reply to opod from comment #200)
> > (In reply to Jeff Muizelaar [:jrmuizel] from comment #199)
> > > Here's a debugging build that should help us get more information about the
> > > problem:
> > > 
> > > https://tbpl.mozilla.org/?tree=Try&rev=294561e67f20
> > > 
> > > If you could run this and give the output of stdout.
> > > 
> > > Also if you get DebugView
> > > (http://technet.microsoft.com/en-ca/sysinternals/bb896647.aspx)
> > > 
> > > Run that as Administrator and turn on Global logging and see if you get any
> > > d3d related messages.
> > 
> > I'm the guy with dual graphics setup and AMD drivers version 13.152.0.0 from
> > 8/30/2013 running W8.1 x64. 
> > 
> > I just tried the nightly build and it works both on AC and battery power!
> > Thank you for fixing this.
> > 
> > The DebugView only spits out:
> > 
> > [5184] D3D11CreateDevice: Flags (0x2) were specified which require the D3D11
> > SDK Layers for Windows 8.1, but they are not present on the system.
> > [5184] These flags must be removed, or the Windows 8.1 SDK must be installed.
> > [1120] Flags include: D3D11_CREATE_DEVICE_DEBUG
> > 
> > I have a separate problem with Firefox hogging 100% GPU
> > (http://i.imgur.com/xnBzrIS.png) but that would happen before (at least in
> > 32.0) so I will file a separate bug report for that.
> 
> From comment 194, see if AMD's Autodetect Tool can help you. Maybe a newer
> driver can fix the GPU hogging.

I have (somewhat reluctantly) used the Autodetect tool to install the most current upstream AMD drivers (Catalyst 14.9). The driver update actually worked, however, the 33.1 debug nightly from comment 199 still hangs with black window on AC power just like before.

Perhaps (I can only speculate here) the problem has something to do with the specifics of the dual graphics setup? E.g. Firefox detects the capabilities of one GPU but uses the other? If I run Firefox 32 or 36a1 nightly with gfx.direct2d.disabled = true on AC power (both of which work), the about:support page only lists the Intel GPU (as also mentioned in comment 191). 

I'd be happy to test any other debug builds you can provide.

Comment 213

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #199)
> Here's a debugging build that should help us get more information about the
> problem:
> 
> https://tbpl.mozilla.org/?tree=Try&rev=294561e67f20
> 
> If you could run this and give the output of stdout.
> 
> Also if you get DebugView
> (http://technet.microsoft.com/en-ca/sysinternals/bb896647.aspx)
> 
> Run that as Administrator and turn on Global logging and see if you get any
> d3d related messages.

Jeff, before trying the debugging build at home I've tried it here at work, but I don't get any output when running it from the terminal. What exactly should I do to get the output of stdout? I got the build from http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-294561e67f20/try-win32/.

DebugView also does not give me any logs, but maybe that will happen on the laptop at home.

Comment 214

[Jeff Muizelaar [:jrmuizel]]

(In reply to Florin Mezei, QA (:FlorinMezei) from comment #213)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #199)
> > Here's a debugging build that should help us get more information about the
> > problem:
> > 
> > https://tbpl.mozilla.org/?tree=Try&rev=294561e67f20
> > 
> > If you could run this and give the output of stdout.
> > 
> > Also if you get DebugView
> > (http://technet.microsoft.com/en-ca/sysinternals/bb896647.aspx)
> > 
> > Run that as Administrator and turn on Global logging and see if you get any
> > d3d related messages.
> 
> Jeff, before trying the debugging build at home I've tried it here at work,
> but I don't get any output when running it from the terminal. What exactly
> should I do to get the output of stdout? I got the build from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.
> com-294561e67f20/try-win32/.
> 
> DebugView also does not give me any logs, but maybe that will happen on the
> laptop at home.

You'll need to run it like 

C:\ firefox.exe | more

Comment 215

[Jeff Muizelaar [:jrmuizel]]

I've filed a new bug to track this issue separately. If you're experiencing the symptoms please add the make & model of the computer showing the issue along with a link to the crash report from about:crashes from running http://people.mozilla.org/~jmuizelaar/crash-firefox.exe when the black screen is happening.

Also note whether the problem happened with 33.0.0 vs 33.0.2

Comment 216

[Lukas Blakk [:lsblakk] use ?needinfo]

This landing appears to have busted Android Talos - https://tbpl.mozilla.org/?tree=Mozilla-Release&rev=e4f020cdef25

Comment 217

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

This push has 2 changesets which only touched gfxWindowsPlatform.cpp that is only compiled on Windows.

Comment 218

[Nicolas Silva [:nical]]

(In reply to Lukas Blakk [:lsblakk] use ?needinfo from comment #216)
> This landing appears to have busted Android Talos -
> https://tbpl.mozilla.org/?tree=Mozilla-Release&rev=e4f020cdef25

As Benoit said I don't think it's related (and the error itself looks more like an issue with the harness than with gecko).

Comment 219

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #215)
> I've filed a new bug to track this issue separately...

Is this bug 1093863 we're talking about?

Comment 220

[Jeff Muizelaar [:jrmuizel]]

(In reply to Milan Sreckovic [:milan] from comment #219)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #215)
> > I've filed a new bug to track this issue separately...
> 
> Is this bug 1093863 we're talking about?

Yes. Sorry that was a critical omission from my earlier comment.

Comment 221

[Milan Sreckovic [:milan] (needinfo for best results)]

Let's close this and track the rest in bug 1093863.

Comment 222

[Ryan VanderMeulen [:RyanVM]]

Target milestone tracks trunk landing. Please don't play with bug flags.

Comment 224

[sjw]

This issue should be removed from the Beta notes: https://www.mozilla.org/en-US/firefox/34.0beta/releasenotes/#known-issues

Comment 227

[Sylvestre Ledru [:Sylvestre]]

Rentok, please open a new bug for this.
and it seems unrelated to this bug moreover.

Thanks