Closed
Bug 1097321
Opened 10 years ago
Closed 9 years ago
Reduce the amount of dual AMD/intel blacklisting
Categories
(Core :: Graphics: Layers, defect)
Core
Graphics: Layers
Tracking
()
RESOLVED
FIXED
mozilla44
People
(Reporter: jrmuizel, Assigned: BenWa)
References
(Blocks 2 open bugs)
Details
(Keywords: qawanted)
Attachments
(3 files, 6 obsolete files)
Bug 1093863 caused us to blacklist more than we'd like to. We need to figure out some criteria to reduce this.
Comment 3•10 years ago
|
||
yes, please fix this. The fonts are looking horrible so that I get headache after a few minutes. I'm back now to 34b6 until this is fixed. Here my output from about:support Direct2D aktiviert true DirectWrite aktiviert true (6.2.9200.16581) Geräte-ID 0x0166 GPU #2 aktiv false GPU-beschleunigte Fenster 1/1 Direct3D 11 (OMTC) Karten-Beschreibung Intel(R) HD Graphics 4000 Karten-RAM Unknown Karten-Treiber igdumdim64 igd10iumd64 igd10iumd64 igdumdim32 igd10iumd32 igd10iumd32 Subsys-ID 05721028 Treiber-Datum 9-30-2014 Treiber-Version 10.18.10.3958 Vendor-ID 0x8086 WebGL-Renderer Google Inc. -- ANGLE (Intel(R) HD Graphics 4000 Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote true AzureCanvasBackend direct2d AzureContentBackend direct2d AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0 10.18.10.3958 is the latest driver for the Intel HD 4000 and I don't use the HD 77xxM in my Dell Inspiron 7520 (15R SE) at all for Firefox. The Intel HD is fast enough for me.
I always used Firefox without any problems until 32.0.3. After 33.0 update, I got a few UI freezes (but not crashes), that were easily recovered by closing and reopening FF. After 33.0.3, the browser became laggy and the results in any benchmark were ridiculously low. Checking about:support, I noticed all graphics acceleration options were turned off, despite being selected in settings. Searching Bugzilla, I discover my configuration got blacklisted ("Unexpected Intel/AMD dual-GPU setup" error). I don't know why I got blacklisted. I have a Samsung Series 7 i7 Sandy Bridge notebook (3 years old) with dual Intel/AMD GPUs running Win8.1. FF is assigned only to the Intel HD3000 GPU. AMD 6490M is not active for Firefox in any circumstance so FF should simply ignore it. Drivers are installed correctly and updated (AMD to 14.4 because of the known instabilities of 14.9 version). It amazes me that FF finds my configuration "unexpected". I reverted to 32.0.3 and it's all good again (except for not having the latest security patches). If you need any further information to help to fix this issue, let me know. Thanks for the hard work. Data do driver 3-20-2014 Descrição do adaptador Intel(R) HD Graphics 3000 Direct2D ativo true DirectWrite ativo true (6.3.9600.17111) Drivers do adaptador igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32 GPU #2 ativa false ID do dispositivo 0x0116 ID do fornecedor 0x8086 Janelas aceleradas pela GPU 1/1 Direct3D 10 Parâmetros ClearType D [ Gamma: 2400 Pixel Structure: R ClearType Level: 50 Enhanced Contrast: 300 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 50 ] RAM do adaptador Unknown Renderização WebGL Google Inc. -- ANGLE (Intel(R) HD Graphics 3000 Direct3D9Ex vs_3_0 ps_3_0) Versão do driver 9.17.10.3517 windowLayerManagerRemote false AzureCanvasBackend direct2d AzureContentBackend direct2d AzureFallbackCanvasBackend cairo AzureSkiaAccelerated 0
Comment 5•10 years ago
|
||
(In reply to Marcelo from comment #4) > ... > I reverted to 32.0.3 and it's all good again (except for not having the > latest security patches). If you need any further information to help to fix > this issue, let me know. Thanks for the hard work. Bug 1095575 should allow to override the blacklisting using a preference. The current patch which should land soon and hopefully makes it into Firefox 34 looks at either gfx.direct2d.force-enabled or layers.acceleration.force-enabled to bypass the blacklisting. This bug (1097321) is about blacklisting less systems, and hopefully the actual issue which requires the blacklisting will also get handled.
Avi, thanks for the update! I hope that D3D10 GPU's, like the HD3000, are kept supported natively in FF. D3D9 fallback is not a good alternative because of D2D support.
Thanks for the update Avi! Hopefully Firefox 34 will bring back D3D and beautiful font rendering as Firefox 33.0.2 below.
Reporter | ||
Comment 8•10 years ago
|
||
Another update: We're having a machine shipped from Romania that should reproduce the original problem. With that machine in hand we should be able to figure out what's special about it and reduce the blacklisting to that configuration.
Comment 9•10 years ago
|
||
thanks for the update Jeff. Is it possible to have https://bugzilla.mozilla.org/show_bug.cgi?id=1095575 included in Firefox 34 and not only in nightly?
Reporter | ||
Comment 10•10 years ago
|
||
The laptop is supposed to arrive in Toronto in 19 Nov 2014
Reporter | ||
Comment 11•9 years ago
|
||
I have the laptop and can reproduce the problem. Avi, or anyone else, can you see if you can reproduce the black screen in 33.0.2 if you force firefox to use the 'High performance' graphics setting.
Comment 12•9 years ago
|
||
I only tried with nightly 2014-11-26 so far on i7-4500u (+HD4400) + AMD 8850m. By default Firefox uses only the Intel iGPU, and nightly currently blacklists all HW acceleration. In order to force high performance (use the AMD GPU), I needed to rename it because "Firefox.exe" is blacklisted on the Catalyst 14.4 driver to disallow high performance. After renaming it and forcing high performance, it works well and still HW accel is blacklisted. After setting layers.acceleration.force-enabled=true and forcing high performance - I see the black window bug.
Comment 13•9 years ago
|
||
And if I only set layers.acceleration.force-enabled=true but don't force high performance, then I don't get the black window bug.
Reporter | ||
Comment 14•9 years ago
|
||
Reporter | ||
Comment 15•9 years ago
|
||
Attachment #8529888 -
Attachment is obsolete: true
Reporter | ||
Comment 16•9 years ago
|
||
Attachment #8529895 -
Attachment is obsolete: true
Attachment #8530385 -
Flags: review?(bas)
Updated•9 years ago
|
Attachment #8530385 -
Flags: review?(bas) → review+
Comment 17•9 years ago
|
||
After FF 34 my Intel/AMD combo is still blacklisted. But now if I enable gfx.direct2d.force-enabled I get full hw acceleration and no problem at all. Thanks! Curiously, I also got OMTC enabled on Direct3D 11 (as per about:support) even if layers.acceleration.force-enabled is disabled and my HD3000 only supports D3D10...
Comment 18•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/4c22e58f4398
Assignee: nobody → jmuizelaar
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Reporter | ||
Comment 19•9 years ago
|
||
Comment on attachment 8530385 [details] [diff] [review] detect-broke.patch Approval Request Comment [Feature/regressing bug #]: Bug 1093863 [User impact if declined]: Unnecessary black listing of AMD hardware [Describe test coverage new/current, TBPL]: Has been on mozilla-central for a couple of days. I also tested this locally against a machine that has the problem [Risks and why]: This changes a rough heuristic for detecting black screens to code that actually detects the problem. This means that we'll only black list on machines that truly have the problem. I'd like to get this in beta to get the widest testing possible. If this ends up causing crashes it should be easy to localize to this code and back out the patch from beta.
Attachment #8530385 -
Flags: approval-mozilla-beta?
Attachment #8530385 -
Flags: approval-mozilla-aurora?
Updated•9 years ago
|
Updated•9 years ago
|
Attachment #8530385 -
Flags: approval-mozilla-beta?
Attachment #8530385 -
Flags: approval-mozilla-beta+
Attachment #8530385 -
Flags: approval-mozilla-aurora?
Attachment #8530385 -
Flags: approval-mozilla-aurora+
Comment 20•9 years ago
|
||
I hope we will be able to get some confirmation on this before we release :)
Comment 21•9 years ago
|
||
I'll test the next 35 Beta version which includes this patch and set gfx.direct2d.force-enabled to false and look if I'm still blocked or not (Dell Inspirion laptop with Intel HD4000 + AMD 7730M).
Comment 22•9 years ago
|
||
(In reply to André Ziegler from comment #21) > I'll test the next 35 Beta version which includes this patch and set > gfx.direct2d.force-enabled to false and look if I'm still blocked or not > (Dell Inspirion laptop with Intel HD4000 + AMD 7730M). I tested this with nightly on a Dell 3537 with HD4400 + AMD 8850m. Before this patch and without forcing acceleration via prefs, this system was blacklisted. With this patch and default prefs I now get Direct3D 11 (OMTC) and direct2d 1.1 for Azure{Canvas|Content}Backend. So success on this system.
Comment 23•9 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/9003c05353cc https://hg.mozilla.org/releases/mozilla-beta/rev/56df12474ac2
Comment 24•9 years ago
|
||
I tested the candidate of 35b3 and it works fine. With gfx.direct2d.force-enabled = false I still have HW accelerated graphic.
Comment 25•9 years ago
|
||
(In reply to André Ziegler from comment #24) > I tested the candidate of 35b3 and it works fine. With > gfx.direct2d.force-enabled = false I still have HW accelerated graphic. Marking as Verified for Firefox 35.
Comment 26•9 years ago
|
||
Actually, I think we should back this out fast from both Aurora and Beta. The signatures of bug 1098597 and bug 1074378 (re)appeared on Aurora starting with the 12/12 build, the first that has this patch, and on 35 beta 3, which is the first beta containing it, the 3 signatures of those two bugs together are 75% of all crashes.
Comment 27•9 years ago
|
||
Jeff- can you prep a backout for Beta before this Thursday's go to build?
Flags: needinfo?(jmuizelaar)
Comment 28•9 years ago
|
||
Cancel that request - if Ryan can cleanly back this out, we can gtb with a 35.0b4 build #2 later today.
Flags: needinfo?(jmuizelaar) → needinfo?(ryanvm)
Comment 29•9 years ago
|
||
which issues do you see? For me everything is fine my an Intel Hd 4000/AMD 7730M
Comment 30•9 years ago
|
||
Backed out from beta while the crash spike is investigated. https://hg.mozilla.org/releases/mozilla-beta/rev/c364b0e2691f
Flags: needinfo?(ryanvm)
Comment 31•9 years ago
|
||
(In reply to André Ziegler from comment #29) > which issues do you see? For me everything is fine my an Intel Hd 4000/AMD > 7730M For you it might, but we have a lot of people crashing on startup on Aurora and Beta (seen in crash reports/stats). We need to figure those cases out before trying this unblocking again.
Reporter | ||
Comment 32•9 years ago
|
||
So none of the crashes that I looked at would have been blacklisted by the code path the patch on this bug removed. However, it may be that this broke some of the detection code that we had. I'll investigate further.
Reporter | ||
Comment 33•9 years ago
|
||
I looked into this further on an intel machine that should be blacklisted. It currently appears as though it is not, and I have no idea why.
Comment 34•9 years ago
|
||
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #31) > For you it might, but we have a lot of people crashing on startup on Aurora > and Beta (seen in crash reports/stats). We need to figure those cases out > before trying this unblocking again. ok. You should tell the users to update their drivers if you detect old ones.
Comment 35•9 years ago
|
||
(In reply to André Ziegler from comment #34) > ok. You should tell the users to update their drivers if you detect old ones. We found out that updating drivers is a so intricate thing to do in any cases that a non-technical user will never do it. If we tell those people to update their driver, they will rather switch to a different browser than actually do that too complicated and risky action. All that said, Jeff and the graphics team will continue to work on unblocking those machines that do not actually have issues, but something went wrong with the patch this time. Jeff, given that you could verify yourself that the patch doesn't work as intended and unblacklists machines it shouldn't, would it be good to back it out from Dev Edition and Nightly as well or will you get to a fix very soon?
Flags: needinfo?(jmuizelaar)
Reporter | ||
Comment 36•9 years ago
|
||
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #35) > > Jeff, given that you could verify yourself that the patch doesn't work as > intended and unblacklists machines it shouldn't, would it be good to back it > out from Dev Edition and Nightly as well or will you get to a fix very soon? I figured out what was going wrong and it appears to be unrelated to this bug. The machine I had was being blocked properly. Did backing this out from beta make the crashes go away?
Flags: needinfo?(jmuizelaar) → needinfo?(kairo)
Comment 37•9 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #36) > I figured out what was going wrong and it appears to be unrelated to this > bug. The machine I had was being blocked properly. Oh, hrm, I hoped you would have a case you can investigate and find the problem with. :( > Did backing this out from beta make the crashes go away? Yes, the crash spike is gone from beta, so we can confirm that it was related to this patch. We still have those crashes go on at least on Dev Edition, though (I haven't explicitly checked Nightly but guess it's the same there) - even though fewer people use those affected machines there (and those still there probably will go away given they still have ongoing startup crashes). FWIW, if I have read some stats I've seen correctly, we probably have effectively purged the Nightly and Aurora channels from people with broken drivers by all the previous issues we sent their way - we saw significant decline of users on those channels when OMTC hit them first.
Flags: needinfo?(kairo)
Reporter | ||
Comment 38•9 years ago
|
||
I've landed this on aurora for Bas. https://hg.mozilla.org/releases/mozilla-aurora/rev/ff14356d2024
Updated•9 years ago
|
Updated•9 years ago
|
Comment 39•9 years ago
|
||
So to recap, this is currently backed out from Fx35/Fx36 but remains in Fx37. Jeff, do we have any further plans for this bug?
Flags: needinfo?(jmuizelaar)
Reporter | ||
Comment 40•9 years ago
|
||
Yes we should back this out of everywhere else. I'll try to write a new patch that fixes the problem.
Status: RESOLVED → REOPENED
Flags: needinfo?(jmuizelaar)
Resolution: FIXED → ---
Updated•9 years ago
|
status-firefox38:
--- → fixed
Target Milestone: mozilla37 → ---
Comment 41•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/9862bab2c301 Queued to push to Aurora37 with the next round of uplifts.
Updated•9 years ago
|
Attachment #8530385 -
Attachment is obsolete: true
Attachment #8530385 -
Flags: approval-mozilla-beta+
Attachment #8530385 -
Flags: approval-mozilla-aurora+
Comment 43•9 years ago
|
||
I am affected by this bug on a dual-gpu system with Intel HD Graphics 4000 and AMD Radeon HD 8570, Windows 8.1 x64. Drivers for both GPUs are updated to latest versions (Intel 10.18.10.4061 from 12/18/2014 and AMD 14.501.1003.0 from 11/20/2014). I had to force the Intel driver update as it is not "manufacturer-validated" (thanks Samsung). I am testing the hardware acceleration with the WebGL animation at acko.net and MSI Afterburner to see which GPU is doing the work. On the screenshots, GPU1 is Intel, GPU2 is AMD. Case #1, Firefox 36.0.1: about:support https://pastebin.mozilla.org/8825658 acko.net http://i.imgur.com/XenO7J7 Direct2D is disabled, neither GPU seems to be doing much, performance is terrible at 13fps. Forcing gfx.direct2d.force-enabled results in the black window bug. Case #2, Nightly 39.0a1 about:support https://pastebin.mozilla.org/8825662 acko.net http://i.imgur.com/5Zz9VDu.jpg Direct2D is still disabled, both GPUs seem to do something, with Intel GPU doing the bulk of the work. Performance is choppy at ~40fps with tearing. Forcing gfx.direct2d.force-enabled results in the black window bug. Case #3, Nightly 39.0a1 I arrived at this by accident. If I manually force the update of the Intel driver (by pointing to the folder and choosing the driver from the list in device manager), but *do not restart the system*, it seems to work! about:support https://pastebin.mozilla.org/8825663 acko.net http://i.imgur.com/HwTZpog.jpg Direct2D is enabled, and the bulk of work is done by the AMD GPU as it's supposed to. Acko.net is buttery smooth at 60fps. Rebooting the laptop brings me back to Case #2. Google Chrome behaves correctly (like in case #3) all the time (without driver-forcing not-rebooting shenanigans) so it doesn't seem to be a hardware limitation. I'd be happy to provide additional information if required.
Do you still see the same behaviour (in case #3 in particular) with the latest nightly?
Flags: needinfo?(fijam7)
Comment 45•9 years ago
|
||
Yes, unchanged with Nightly 39.0a1 / 20150327030212
Flags: needinfo?(fijam7)
Strange that we don't see the second GPU in the about:support you posted. I only see the first card, Intel, and never see the description of the AMD GPU, driver versions, etc.
Comment 47•9 years ago
|
||
Regarding 1148088, it appears that my AMD/Intel (AMD Radeon HD 6770M/Intel HD Graphics 3000) combo is blacklisted. If I enable gfx.direct2d.force-enabled I get a black screen when launching Firefox just like fijam7@gmail.com is reporting. Is any type of work being done to fix this or is this a permanent issue with Direct2D and AMD/Intel setups?
Comment 48•9 years ago
|
||
Any update on this? My friend has Intel HD Graphics 4600 + AMD Radeon HD 89670M + Win 10 x64, his Firefox works flawlessly. Mine (HD Graphics 3000 + AMD Radeon HD 7400M + Win 10 x64) got that (#0) Error Unexpected Intel/AMD dual-GPU setup (#1) Error Unexpected Intel/AMD dual-GPU setup
Reporter | ||
Comment 49•9 years ago
|
||
Please review carefully
Attachment #8671501 -
Flags: review?(bgirard)
Assignee | ||
Comment 50•9 years ago
|
||
jeff's patch. I just fixed it up.
Attachment #8671501 -
Attachment is obsolete: true
Attachment #8671501 -
Flags: review?(bgirard)
Attachment #8671639 -
Flags: review?(bgirard)
Assignee | ||
Comment 51•9 years ago
|
||
Comment on attachment 8671639 [details] [diff] [review] patch Review of attachment 8671639 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/thebes/gfxWindowsPlatform.cpp @@ +1919,5 @@ > + desc.CPUAccessFlags = D3D11_CPU_ACCESS_READ; > + desc.MiscFlags = 0; > + desc.BindFlags = 0; > + if (FAILED(device->CreateTexture2D(&desc, nullptr, byRef(cpuTexture)))) { > + return false; We should have a graphics critical error for this maybe? @@ +1927,5 @@ > + nsRefPtr<ID3D11DeviceContext> deviceContext; > + sharedResource->QueryInterface(__uuidof(IDXGIKeyedMutex), (void**)getter_AddRefs(sharedMutex)); > + device->GetImmediateContext(getter_AddRefs(deviceContext)); > + if (FAILED(sharedMutex->AcquireSync(0, 30*1000))) { > + gfxCriticalError() << "DoesD3D11TextureSharingWorkAcquireSyncTimeout"; perhaps this would be better: DoesD3D11TextureSharingWorkAcquire_SyncTimeout @@ +1941,5 @@ > + if (SUCCEEDED(deviceContext->Map(cpuTexture, 0, D3D11_MAP_READ, 0, &mapped))) { > + // read the texture > + resultColor = *(int*)mapped.pData; > + } else { > + gfxCriticalError() << "DoesD3D11TextureSharingWorkMapFailed"; DoesD3D11TextureSharingWork_MapFailed
Attachment #8671639 -
Flags: review?(bgirard)
Attachment #8671639 -
Flags: review?(bas)
Attachment #8671639 -
Flags: review+
Comment 52•9 years ago
|
||
Comment on attachment 8671639 [details] [diff] [review] patch Review of attachment 8671639 [details] [diff] [review]: ----------------------------------------------------------------- ::: gfx/thebes/gfxWindowsPlatform.cpp @@ +1852,5 @@ > nsString vendorID, vendorID2; > gfxInfo->GetAdapterVendorID(vendorID); > gfxInfo->GetAdapterVendorID2(vendorID2); > if (vendorID.EqualsLiteral("0x8086") && vendorID2.IsEmpty()) { > + gfxCriticalError(CriticalLog::DefaultOptions(false)) << "PossiblyBrokenSurfaceSharingUnexpectedAMDGPU"; Can we just put spaces in here? This is a string literal... @@ +1872,5 @@ > desc.CPUAccessFlags = 0; > desc.MiscFlags = D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX; > desc.BindFlags = bindflags; > + > + int color[texture_size * texture_size]; nit: uint32_t @@ +1878,5 @@ > + color[i] = 0xff00ffff; > + } > + // We're going to check that sharing actually works with this format > + D3D11_SUBRESOURCE_DATA data; > + data.pSysMem = color; Does this compile? Shouldn't this require a reinterpret cast? @@ +1927,5 @@ > + nsRefPtr<ID3D11DeviceContext> deviceContext; > + sharedResource->QueryInterface(__uuidof(IDXGIKeyedMutex), (void**)getter_AddRefs(sharedMutex)); > + device->GetImmediateContext(getter_AddRefs(deviceContext)); > + if (FAILED(sharedMutex->AcquireSync(0, 30*1000))) { > + gfxCriticalError() << "DoesD3D11TextureSharingWorkAcquireSyncTimeout"; Again.. no spaces? @@ +1941,5 @@ > + if (SUCCEEDED(deviceContext->Map(cpuTexture, 0, D3D11_MAP_READ, 0, &mapped))) { > + // read the texture > + resultColor = *(int*)mapped.pData; > + } else { > + gfxCriticalError() << "DoesD3D11TextureSharingWorkMapFailed"; Wait.. why do we hate spaces? @@ +1944,5 @@ > + } else { > + gfxCriticalError() << "DoesD3D11TextureSharingWorkMapFailed"; > + return false; > + } > + deviceContext->Unmap(cpuTexture, 0); Move unmap into the if SUCCEEDED @@ +1952,5 @@ > + // check that the color we put in is the color we get out > + if (resultColor != color[0]) { > + // Shared surfaces seem to be broken on dual AMD & Intel HW when using the > + // AMD GPU > + gfxCriticalNote << "SharedSurfaceArentShared"; And apostrophes too?
Attachment #8671639 -
Flags: review?(bas) → review-
Assignee | ||
Comment 53•9 years ago
|
||
It compiles and the hate for spaces is because it's hard to search in crashstats I think.
Comment 54•9 years ago
|
||
(In reply to Benoit Girard (:BenWa) from comment #53) > It compiles and the hate for spaces is because it's hard to search in > crashstats I think. Yeah, it's LPVOID I guess. Why would a unique string with spaces be harder than a unique string without spaces?
Reporter | ||
Comment 55•9 years ago
|
||
(In reply to Bas Schouten (:bas.schouten) from comment #54) > (In reply to Benoit Girard (:BenWa) from comment #53) > > It compiles and the hate for spaces is because it's hard to search in > > crashstats I think. > > Yeah, it's LPVOID I guess. > > Why would a unique string with spaces be harder than a unique string without > spaces? SuperSearch on CrashStats tokenizes by spaces so omitting spaces makes faceting by "Graphics Critical Error" much nicer.
By the way - gfxCriticalError(CriticalLog::DefaultOptions(false)) can be replaced with gfxCriticalNote for brevity.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #55) > > SuperSearch on CrashStats tokenizes by spaces so omitting spaces makes > faceting by "Graphics Critical Error" much nicer. True, but it's enough to have one unique string in there, and make the rest read better. On a side note, if this is part of startup testing, David should comment on it. There may be additional flags/prefs/telemetry/whatever to make it consistent.
Flags: needinfo?(dvander)
Comment 58•9 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #55) > SuperSearch on CrashStats tokenizes by spaces so omitting spaces makes > faceting by "Graphics Critical Error" much nicer. Not sure if that's true for every field type. For App Notes, it is, but for other field, the ES indexing might be possible to be set differently.
Seems reasonable, we already send the result of DoesD3D11TextureSharingWork to Telemetry so we should be able to see if that or D3D11 uptake changes.
Flags: needinfo?(dvander)
Assignee | ||
Comment 60•9 years ago
|
||
I switched to using underscore. I'd rather not run our chances at having tokenizer problems and make sure we have an easier time searching. Not sure what you mean by apostrophe. They are are hex 0x22 which is double quotes.
Assignee: jmuizelaar → bgirard
Attachment #8671639 -
Attachment is obsolete: true
Status: REOPENED → ASSIGNED
Attachment #8672136 -
Flags: review?(bas)
Updated•9 years ago
|
Attachment #8672136 -
Flags: review?(bas) → review+
Assignee | ||
Comment 61•9 years ago
|
||
rebase
Attachment #8672136 -
Attachment is obsolete: true
Attachment #8675929 -
Flags: review+
Assignee | ||
Comment 62•9 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=f5aa7f45a058
Assignee | ||
Comment 63•9 years ago
|
||
Bug 1097321 - Fix DoesD3D11TextureSharingWorkInternal to handle Intel/AMD configurations. r=Bas
Assignee | ||
Comment 64•9 years ago
|
||
Bug 1097321 - Add layers.amd-switchable-gfx.enabled pref. r=jrmuizel
Attachment #8676457 -
Flags: review?(jmuizelaar)
Reporter | ||
Comment 65•9 years ago
|
||
Comment on attachment 8676457 [details] MozReview Request: Bug 1097321 - Add layers.amd-switchable-gfx.enabled pref. r=jrmuizel https://reviewboard.mozilla.org/r/22719/#review20185
Attachment #8676457 -
Flags: review?(jmuizelaar) → review+
Assignee | ||
Comment 66•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/5155bb5301f4138e28ab1df547e755f9afe01edf Bug 1097321 - Fix DoesD3D11TextureSharingWorkInternal to handle Intel/AMD configurations. r=Bas https://hg.mozilla.org/integration/mozilla-inbound/rev/ae31deae1e250a46be941c91d9112a45cd781246 Bug 1097321 - Add layers.amd-switchable-gfx.enabled pref. r=jrmuizel
Comment 67•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/5155bb5301f4 https://hg.mozilla.org/mozilla-central/rev/ae31deae1e25
Status: ASSIGNED → RESOLVED
Closed: 9 years ago → 9 years ago
status-firefox44:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla44
You need to log in
before you can comment on or make changes to this bug.
Description
•