Neovide causes a driver crash on integrated intel gpu when rendering with DX11

[OrangeLightning219]

Describe the bug
When running an application that uses DX11 for rendering (a game for example) and then switching the window to neovide the other application crashes with error DXGI_ERROR_DEVICE_HUNG. Sometimes even the whole driver crashes and freezes the laptop.

This does not happen with every game. I managed to get this error when running my game and Divinity Original Sin 2 (both games run fine before switching to neovide). Also running my game and Divinity at the same time and switching between them works fine.

To Reproduce
Steps to reproduce the behavior:

1. Open neovide
2. Open a resource heavy game
3. Switch to neovide window
4. The game crashes

Expected behavior
Nothing happens when switching to neovide.

Desktop (please complete the following information):

• OS: Windows 11
• Neovide Version: Built from source from this commit
• Neovim Version: v0.10.0-dev-2898+g4c31a1b80

Please run neovide --log and paste the contents of the .log file created in the current directory here:
neovide_rCURRENT.log

Additional context

• Everything works fine on my desktop with a Nvidia RTX 3060ti gpu.
• This only happens with DX11. Running with --opengl works fine.
• I'm getting this error on a integrated 9th gen intel gpu with latest drivers.
• I'm running the games in windowed mode with 1280x720 resolution.
• This has something to do with complex shaders running in the games - when I disabled rendering of all 3d models in my game it stopped crashing.
• Also this may be related to compute shaders because after the DXGI_ERROR_DEVICE_HUNG my game shows a lot of errors about failed buffer and SRV creations for buffers that are used in compute shaders (this is only speculation and may not be related at all). Divinity also uses compute shaders (I checked by capturing a frame with renderdoc).
• There are also games like Hades or The Witness that don't cause this issue. Hades doesn't run any compute shaders (I don't know about The Witness because I wasn't able to capture a frame)
• Here's a full error message from DX11 debug layer: ID3D11RemoveDevice: Device removal has been triggered for the following reason (DXGI_ERROR_DEVICE_HUNG: The Device took an unreasonable amount of time to execute its commands, or the hardware crashed/hung. As a result, the TDR (Timeout Detection and Recovery) mechanism has been triggered. The current Device Context was executing commands when the hang occurred. The application may want to respawn and fallback to less aggressive use of the display hardware). [ EXECUTION ERROR #378: DEVICE_REMOVAL_PROCESS_AT_FAULT]

[fredizzimo]

Would you be able to try to fix this yourself with some pointers?

I think you could try adding this (in d3d.rs) both before and after the detecting a focus lost event (handled in window_wrapper.rs)

self.gr_context.flush_submit_and_sync_cpu();
self.wait_for_gpu();

[OrangeLightning219]

Sure, I'll try that tomorrow.

[fredizzimo]

I think the most likely reason is a driver bug though. Are you using the latest drivers?

[OrangeLightning219]

Yes, I have the latest drivers installed.

[fredizzimo]

Actually, I think for an even easier testing, you could just call self.skia_renderer.resize(); from the window wrapper.

[OrangeLightning219]

Adding the resize call in the focus handlers didn't change anything. It looks like it has nothing to do with gaining focus because if I focus the window by clicking on the title bar nothing happens. The crash happens when rendering of the next frame is triggered.

Also while running through the debugger there is a bunch of errors and warnings from the directx debug layer:

• D3D12 ERROR: ID3D12DescriptorHeap::GetGPUDescriptorHandleForHeapStart: GetGPUDescriptorHandleForHeapStart is invalid to call on a descriptor heap that does not have DESCRIPTOR_HEAP_FLAG_SHADER_VISIBLE set. If the heap is not supposed to be shader visible, then GetCPUDescriptorHandleForHeapStart would be the appropriate method to call. That call is valid both for shader visible and non shader visible descriptor heaps. [ STATE_GETTING ERROR #1315: DESCRIPTOR_HEAP_NOT_SHADER_VISIBLE]
• D3D12 WARNING: ID3D12CommandList::ClearRenderTargetView: The clear values do not match those passed to resource creation. The clear operation is typically slower as a result; but will still clear to the desired value. [ EXECUTION WARNING #820: CLEARRENDERTARGETVIEW_MISMATCHINGCLEARVALUE]
  And this when switching between windows:
• D3D12 ERROR: ID3D12CommandList::OMSetRenderTargets: The RenderTargetView at slot 0 is not compatible with the DepthStencilView. DepthStencilViews may only be used with RenderTargetViews if the effective dimensions of the Views are equal, as well as the Resource types, multisample count, and multisample quality. One exception is that DepthStencil width and/or height can be larger than RenderTarget width/height.The RenderTargetView at slot 0 has (w:1920,h:1009,as:1), while the Resource is a Texture2D with (mc:1,mq:0). The DepthStencilView has (w:1920,h:1009,as:1), while the Resource is a Texture2D with (mc:1,mq:4294967295). [ EXECUTION ERROR #728: SET_RENDER_TARGETS_INVALID]
• D3D12 ERROR: ID3D12CommandList::DrawIndexedInstanced: The depth stencil sample desc does not match that specified by the current pipeline state.(pipeline state = count 1 quality 0, depth stencil view = count 1 quality -1, ID3D12Resource* = 0x0000023E2E605260:'Unnamed ID3D12Resource Object') [ EXECUTION ERROR #616: DEPTH_STENCIL_SAMPLE_DESC_MISMATCH_PIPELINE_STATE]
• D3D12 ERROR: ID3D12CommandList::DrawInstanced: The depth stencil sample desc does not match that specified by the current pipeline state.(pipeline state = count 1 quality 0, depth stencil view = count 1 quality -1, ID3D12Resource* = 0x0000023E2E605260:'Unnamed ID3D12Resource Object') [ EXECUTION ERROR #616: DEPTH_STENCIL_SAMPLE_DESC_MISMATCH_PIPELINE_STATE]

[fredizzimo]

I don't immediately see what's wrong and some of those errors, especially the first one seem to be totally internal to skia.

You could compare our code to the skia examples
https://github.com/google/skia/blob/341ee60bc0e4022605df316f38166e1897691ddd/tools/window/win/D3D12WindowContext_win.cpp#L116
https://github.com/google/skia/blob/341ee60bc0e4022605df316f38166e1897691ddd/tools/gpu/d3d/D3DTestUtils.cpp#L28

[OrangeLightning219]

I don't see anything obviously wrong either (but I don't have any experience with DX12, I only used DX11). I think we can assume it's either a driver bug or a bug in skia. I don't really care that much about this because I'm not currently using this laptop for programming and if I ever need to I can run neovide in opengl mode. Maybe someone more experienced in DX12 and familiar with the skia codebase could take a look at that.

[fredizzimo]

You could try to add D3D12_COMMAND_QUEUE_FLAG_DISABLE_GPU_TIMEOUT to the D3D12_COMMAND_QUEUE_DESC