1003293 - OMTC bugs with Optimus and discrete GPU

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

STR:
1 - run Firefox, enable OMTC in profile
2 - In NVIDIA control panel, set the NVIDIA GPU as the preferred GPU
3 - rename firefox.exe to fx.exe
4 - run fx.exe (with OMTC profile)

Observe broken updates -- it looks like a synchronization issue, and likely on the Optimus side.  Frames are painted to the window with portions of the frame black.

Video at: https://www.dropbox.com/s/eh4d4i28co0m47v/VID_20140429_132907.mp4

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

More data!  Every few runs I get a frozen first frame, and a bunch of:

[564] WARNING: Failed to open shared texture: file c:\proj\moz\mozilla-central\gfx\layers\d3d11/TextureD3D11.cpp, line 307
[564] WARNING: failed to lock front buffer: file c:\proj\moz\mozilla-central\gfx\layers\composite/ImageHost.cpp, line 86
[564] ###!!! ASSERTION: Could not create texture: 'texture', file c:/proj/moz/mozilla-central/gfx/layers/d3d11/CompositorD3D11.cpp, line 435

etc. messages.

I also got a display driver reset warning for the Intel GPU at one point.

Are we somehow ending up in a mixed Intel-NVIDIA rendering situation? (More mixed than normal with Optimus, i.e. more than just the present happening on the intel gpu?)

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

When the above happens (the freeze and errors), I see this in the debugger output:

D3D11: Removing Device.
First-chance exception at 0x000007FEF4E9B7CC in fx.exe: Microsoft C++ exception: _com_error at memory location 0x000000A03283C798.
First-chance exception at 0x000007FEF4E9B7CC in fx.exe: Microsoft C++ exception: _com_error at memory location 0x000000A03283C798.
First-chance exception at 0x000007FEF4E9B7CC in fx.exe: Microsoft C++ exception: _com_error at memory location 0x000000A03283DF80.
...

The _com_errors are being thrown inside D3D, all from under this call in our code at CompositorD3D11.cpp line 638:

      mDevice->CreateShaderResourceView(source->GetD3D11Texture(), nullptr, byRef(view));

Comment 3

[Bas Schouten (:bas.schouten)]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #2)
> When the above happens (the freeze and errors), I see this in the debugger
> output:
> 
> D3D11: Removing Device.
> First-chance exception at 0x000007FEF4E9B7CC in fx.exe: Microsoft C++
> exception: _com_error at memory location 0x000000A03283C798.
> First-chance exception at 0x000007FEF4E9B7CC in fx.exe: Microsoft C++
> exception: _com_error at memory location 0x000000A03283C798.
> First-chance exception at 0x000007FEF4E9B7CC in fx.exe: Microsoft C++
> exception: _com_error at memory location 0x000000A03283DF80.
> ...
> 
> The _com_errors are being thrown inside D3D, all from under this call in our
> code at CompositorD3D11.cpp line 638:
> 
>       mDevice->CreateShaderResourceView(source->GetD3D11Texture(), nullptr,
> byRef(view));

This is just indicative of a driver crash :(.

Fwiw, I don't see these display driver crashes on my machine, but we should probably work out 1. What's triggering them. and 2. How to deal with a driver crash more gracefully.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Razer Blade 14", intel 10.18.10.3412, nvidia 331.65.  Updating to .3496 now.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I have not 100% confirmed this, but I think this actually has nothing to do with Optimus, it's just exacerbated by it.

Our compositor is using a D3D11 device.  D2D uses/requires a D3D 10.1 device.  Despite these being created on the same DXGI adapter, they are separate devices -- we have to explicitly synchronize any resources (textures) between the two, which we don't seem to do any of right now.  And indeed, what I'm seeing looks exactly like synchronization problems.

See http://msdn.microsoft.com/en-us/library/windows/desktop/ee913554%28v=vs.85%29.aspx -- "Synchronized Shared Surfaces"
And the thread at http://www.gamedev.net/topic/547920-how-to-use-d2d-with-d3d11/?view=findpost&p=4529618

IMO, this needs to block OMTC on Windows.

Comment 6

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

Sorry, needinfo went to "wrong" account ([e-mail] is the "right" one), so I didn't see it.

Comment 7

[Bas Schouten (:bas.schouten)]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #5)
> I have not 100% confirmed this, but I think this actually has nothing to do
> with Optimus, it's just exacerbated by it.
> 
> Our compositor is using a D3D11 device.  D2D uses/requires a D3D 10.1
> device.  Despite these being created on the same DXGI adapter, they are
> separate devices -- we have to explicitly synchronize any resources
> (textures) between the two, which we don't seem to do any of right now.  And
> indeed, what I'm seeing looks exactly like synchronization problems.
> 
> See
> http://msdn.microsoft.com/en-us/library/windows/desktop/ee913554%28v=vs.
> 85%29.aspx -- "Synchronized Shared Surfaces"
> And the thread at
> http://www.gamedev.net/topic/547920-how-to-use-d2d-with-d3d11/
> ?view=findpost&p=4529618
> 
> IMO, this needs to block OMTC on Windows.

Hmm? We create our D2D surfaces on a dedicated D3D 10.1 adapter created for the client side, see:

http://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d11/TextureD3D11.cpp#232

 Our -compositor- uses D3D11, and we synchronize with that here:

Client: http://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d11/TextureD3D11.cpp#179
Host: http://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d11/TextureD3D11.cpp#317

So all the synchronization should be happening as required.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Hmm, quite.  Right now we create a D3D10 Texture, and then open its share handle from the D3D11 device.  Bas and I talked about trying to do the opposite; I'll give this a shot and report back.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: (prototype) create texture using D3D11

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #8)
> Hmm, quite.  Right now we create a D3D10 Texture, and then open its share
> handle from the D3D11 device.  Bas and I talked about trying to do the
> opposite; I'll give this a shot and report back.

This totally works.  No rendering artifacts.  Attached is the patch I used; it's a little hacky, but it works.

Cleaner would be to pass the D3DTexture11 to the compositor directly instead of passing it as a shared handle, and have TextureClientD3D11 keep around both the D3D10 and D3D11 texture.

But worst case we can put this behind IsOptimus for now, as Bas suggested; but it feels like we should just do this everywhere.

Comment 10

[Bas Schouten (:bas.schouten)]

(In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #9)
> Created attachment 8420670 [details] [diff] [review]
> (prototype) create texture using D3D11
> 
> (In reply to Vladimir Vukicevic [:vlad] [:vladv] from comment #8)
> > Hmm, quite.  Right now we create a D3D10 Texture, and then open its share
> > handle from the D3D11 device.  Bas and I talked about trying to do the
> > opposite; I'll give this a shot and report back.
> 
> This totally works.  No rendering artifacts.  Attached is the patch I used;
> it's a little hacky, but it works.
> 
> Cleaner would be to pass the D3DTexture11 to the compositor directly instead
> of passing it as a shared handle, and have TextureClientD3D11 keep around
> both the D3D10 and D3D11 texture.
> 
> But worst case we can put this behind IsOptimus for now, as Bas suggested;
> but it feels like we should just do this everywhere.

I'm concerned about paying the cost of two texture creations on the Client thread instead of one. So I'm all for taking this approach, but I would like to see it behind IsOptimus until we can come up with something better (I bet if we use D3D11 on both sides we might be fine, which we should start doing fairly soon with D2D 1.1). There's also the fact that on a lot of drivers texture creation grabs a lock which could cause blocking of the compositor thread (http://msdn.microsoft.com/en-us/library/windows/desktop/ff476130%28v=vs.85%29.aspx), briefly, but for no good reason.

Comment 11

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: Fix IsOptimus()

So it turns out the bug here isn't about D3D11/D3D10 synchronization, but it's about IsOptimus() and DXGI_SWAP_CHAIN_FLAG_GDI_COMPATIBLE.

IsOptimus() seemed to be broken -- the module on my system that was actually loaded is nvumdshimx.dll, even though I only have nvumdshim.dll in system32.  I suspect the NV driver is moving things into place, or maybe this is because it's 64-bit.  Regardless, this fixes IsOptimus, and with that fix, this corruption goes away; we should take this patch.

But, two questions come up.. First, given that the d3d11/d3d10 texture creation thing *also* fixes things even when FLAG_GDI_COMPATIBLE is used, does that change any of our decisions around that flag? Second, the dropdown issue only appears with circa-2010 drivers (or maybe older hardware?).  Should we change that flag usage to just set it on older drivers, and leave it to 0 on modern hardware?  I don't think we -want- DXGI_SWAP_CHAIN_FLAG_GDI_COMPATIBLE.

Comment 12

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: Alternatively, nuke the GDI_COMPAT flag always

This is an alternative approach... IsOptimus can then go away.

Comment 13

[Bas Schouten (:bas.schouten)]

Comment on attachment 8421169 [details] [diff] [review]
Fix IsOptimus()

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

They're valid questions, if we can easily dump it I'm in favor, I'm not too interested in jumping through too many hoops though :-).

Comment 14

[Bas Schouten (:bas.schouten)]

Comment on attachment 8421177 [details] [diff] [review]
Alternatively, nuke the GDI_COMPAT flag always

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

Don't we still want it for the client-side-D3D11-creation code?

Comment 15

[Bas Schouten (:bas.schouten)]

Attachment: Nuke the GDI_COMPAT flag v2

This makes us also nuke the flag when resizing the window.

Comment 16

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 8423434 [details] [diff] [review]
Nuke the GDI_COMPAT flag v2

Looks good, please land the IsOptimus fix as well (even though we won't use it anywhere after this, leaving it broken is a footgun though)

Comment 17

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a1bd40106a99

Comment 18

[Bas Schouten (:bas.schouten)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/812ba047a9af

Comment 19

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/a1bd40106a99
https://hg.mozilla.org/mozilla-central/rev/812ba047a9af