[Tracking Requested - why for this release]: Regression Regression window (mozilla-inbound-win32) Good: https://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1470194747/ Bad: https://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win32/1470196301/ Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=577158be08e8c1211ffa1198a21e3c059f98f477&tochange=b407b980351600f6708db179c9bdb3338bf24796 Caused by: Bug 1289640 - Remove D3D11 ImageBridge device

Also Hardware H264 Decoding is broken. AzureCanvasBackend fallout to skia instead of direct2d 1.1. AzureContentBackend fallout to cairo instead of direct2d 1.1. Some more errors in attached Graphic section from about:support from Comment #2

This (per fallout to Direct3D 9) also exposed these bugs: Bug #1059804 - [OMTC] [Direct3D9] Titlebar fog overlays Windows command buttons Bug #1089312 - [OMTC] [Direct3D9] Minimize, maximize, close buttons are not visible with theme

Makes sense to track this regresssion for 51 - we should show accurate information in the Graphics section.

I'm facing this same issue. In addition to falling back to D3D9 composition I sometimes get only "BasicLayers (main thread, no OMTC)" reported in about:support. I don't know what triggers this though. I'm not sure if the reporting is working well since it can change back to d3d9 at runtime, which seems a bit weird to me.

Same problem, same platform. Unsure if I'm allowed to attach my graphics section but I'll put it anyway.

So it looks like if we request video support on the d3d11 device when on Windows 7 (< WDDM 1.2), then it forces the device to be created at a 9.x feature level (if specified in the feature level list) - See D3D11_CREATE_DEVICE_VIDEO_SUPPORT on [1]. When we're running feature level 9.3: * We fail to initialize CompositorD3D11 since it doesn't support our component alpha blend mode ("create component blender failed" from the log). From [2] "Dual-source color blend not supported (any SrcBlend or DestBlend with SRC1 in the name)" * When we query the DXGIAdapter for the VendorId it returns 0 ("VendorIDMismatch V 0x10de 0" in the log). This behaviour is documented for feature level 9 graphics devices here - [3]. * We fail the check at [4] and disable texture sharing (h/w accelerated video decoding and direct2d). "Direct3D11 device does not support texture sharing" in the log. * We disable D3D11_HW_ANGLE ("RenderTargetViews need recreating") because of the check at [5] It really seems like allowing a feature level 9.3 device to be created isn't helpful since we can't use it for anything. Can we just drop D3D_FEATURE_LEVEL_9_3 from mFeatureLevels to stop this from happening? I've confirmed that without D3D_FEATURE_LEVEL_9_3 we instead fail to create the device entirely, which will trigger us to retry without the video support flag and give us the old behaviour. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ff476107(v=vs.85).aspx [2] https://msdn.microsoft.com/en-nz/library/windows/desktop/ff476150(v=vs.85).aspx#ID3D11Device_CreateBlendState [3] https://msdn.microsoft.com/en-us/library/windows/desktop/ff471326(v=vs.85).aspx [4] http://searchfox.org/mozilla-central/rev/389a3e0817b873a64376ec2b65f6807afbba9d8f/gfx/thebes/D3D11Checks.cpp#191 [5] http://searchfox.org/mozilla-central/rev/389a3e0817b873a64376ec2b65f6807afbba9d8f/gfx/thebes/D3D11Checks.cpp#29

According to Telemetry, 1.1% of users have FEATURE_LEVEL_9_3 hardware - but almost certainly those users are not getting a D3D11 compositor if it's as broken as comment #10 suggests. (I can confirm this tomorrow.)

This change is too useful to back out - let's sort this out this week. I'm unclear as to why this regressed though - what is the difference in logic before and after bug 1289640?

(In reply to Milan Sreckovic [:milan] from comment #12) > This change is too useful to back out - let's sort this out this week. > > I'm unclear as to why this regressed though - what is the difference in > logic before and after bug 1289640? We now pass D3D11_CREATE_DEVICE_VIDEO_SUPPORT during creation of the compositor device, with the expectation that we'll get a device suitable for decoding video, or otherwise no device and we can retry without the extra flag. We instead get a device that is basically useless, so it avoids a retry and instead just fails to initialize all features that use the device.

Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/f22049a0aa1f Don't support D3D11 feature level 9_3 since it doesn't work with any of our use cases. r=Bas

Just to confirm, 0 users with this feature level have a D3D11 compositor (87.5% basic, 12.5% d3d9).

I'm confirming that this bug is fixed in today Nightly 51.0a1 (2016-08-10)

(In reply to David Anderson [:dvander] from comment #17) > Just to confirm, 0 users with this feature level have a D3D11 compositor > (87.5% basic, 12.5% d3d9). Apparently, we had at least one; see bug 1095781 comment 54.

(In reply to Milan Sreckovic [:milan] from comment #19) > (In reply to David Anderson [:dvander] from comment #17) > > Just to confirm, 0 users with this feature level have a D3D11 compositor > > (87.5% basic, 12.5% d3d9). > > Apparently, we had at least one; see bug 1095781 comment 54. Hrm, it's not clear whether that's true from that report, but we can dig to see...

after the GPU SoC on CPU era, Windows 10's Intergrated Drivers and Windows Update server's Automatic Driver Download got igd10umd64.dll for Old CPU Intergrated GPU like 2nd Gen iCore Series(Sandy Bridge)'s HD2000/3000. as an example, my system is i5-2500K with GeForce 980ti, so, 2500K's HD3000 Chipset is Only Support far as WDDM 1.2 Featured 9_3 Level(it's DX10.1 as specification but meaningless on Win10) and GeForce 980ti is WDDM 2.1 Faetured Level 12_1 i'm not using HD3000 and not Plugged any cable in there, but Windows Update Download Automatly Install Intel GFX Driver when Windows 10 Install. and even if i Delete Driver for HD3000 Chipset, That igd10umd64.dll(and other) file is still in there. so.. using old Feature Level GFX or not, Firefox Just Recorgnize that Dydnamic Library on System32 and Only using D3D9 API for HW H.264 Decode instead D3D11. Tested on x64 Win10 Pro 1607 (14393.187) / x64 FF49.0.1 with e10s On

Seems Windows's Drive Uninstall from Device Manager is not delete that file, but DDU(Display Driver Uninstaller) 17.0.2.0 can Delete those.