This https://msdn.microsoft.com/en-us/windows/uwp/gaming/handling-device-lost-scenarios suggests that we should check the result of Present() call and handle the device reset - both DXGI_ERROR_DEVICE_REMOVED and DXGI_ERROR_DEVICE_RESET states. We don't seem to do that. We currently look at the result of Present in CompositorD3D11::EndFrame(), but "handling" of the error is only putting up a message, and not recreating devices, as suggested in the above article. So, CompositorD3D11::HandleError() really should handle the error and do this, and look for DXGI_ERROR_DEVICE_RESET, not just DXGI_ERROR_DEVICE_REMOVED status. We ignore the return value in CompositorD3D11::ForcePresent() doesn't do any checking, and neither do CompositorD3D9::EndFrame() or either of the SwapChainD3D9::Present() functions. We don't even get the messages in these cases.

Let's resolve this bug in London.

[Tracking Requested - why for this release]: Keep this on the radar, see if it can resolve our driver reset issues. Not a new issue by any means, but more prominent because of the buggy drivers and more common driver resets due to dual graphics.

I don't -think- we necessarily need this, since we will handle this on the main thread on the next frame we'll be checking whether the device is lost anyway and executing the reset. The only 'bug' I could imagine from this scenario is the window being blank for 1 frame. But I haven't seen any bugs complaining about this in practice (it would be very rare and transient so I'm guessing that's why). We could add an explicit main thread message from the compositor thread to be 100% certain this happens, but I don't believe there will currently be a bug.

Let's at least add a critical note here - if we then see each one of those followed by a device reset message from somewhere else, we're good.

(In reply to Bas Schouten (:bas.schouten) from comment #3) > I don't -think- we necessarily need this, since we will handle this on the > main thread on the next frame we'll be checking whether the device is lost > anyway and executing the reset. The only 'bug' I could imagine from this > scenario is the window being blank for 1 frame. But I haven't seen any bugs > complaining about this in practice (it would be very rare and transient so > I'm guessing that's why). > > We could add an explicit main thread message from the compositor thread to > be 100% certain this happens, but I don't believe there will currently be a > bug. That's my assumption as well, if we lose the device in the compositor we should lose it on the main thread at the same time. The GPU process might have to work differently but we know we're going to need a new device-reset handling mechanism for that.

Some conversation on this topic in bug 1285152

Tracking 50+ so as keep track of driver reset issues.

(In reply to Marcia Knous [:marcia - use ni] from comment #7) > Tracking 50+ so as keep track of driver reset issues. Probably don't need to - we deal with driver resets in other places, this is a feature request to unify that work.

(In reply to Milan Sreckovic [:milan] from comment #8) > (In reply to Marcia Knous [:marcia - use ni] from comment #7) > > Tracking 50+ so as keep track of driver reset issues. > > Probably don't need to - we deal with driver resets in other places, this is > a feature request to unify that work. Based on Comment 8, removing the tracking + flag.

Bulk move of gfx-noted bugs without priority to P3 for tracking.