protonscr

directx11_hellovr sample crashes due to logical device mysteriously getting lost (Nvidia-specific)

dxvkclosed
doitsujin/dxvk#111 · opened 2018-03-01 by roothorick · updated 2018-10-25 · 6 comments · github
Rroothorick 2018-03-01 github

Software information

I made a quick and dirty version with all VR calls no-op'd out, so as to demonstrate the issue, here: https://github.com/roothorick/directx11_hellovr

This crashes under dxvk, both in Win10 and in Linux. From what little I've been able to glean from debugging (Wine is not fond of VS2017 PDB files), the logical device gets lost for no visible reason. The original, when also using WineOpenVR, crashes in exactly the same way. Both the original and no-op version work correctly in Win10 with native d3d (in the no-op case, for a relative definition of correct; giving it empty matrices produces odd results). It's also fine under wined3d.

Here's where things get weird: under radv, the no-op'd version runs correctly, produces output matching native, and shows no validation errors, not even the ones about misshapen attachments. @pdaniell-nv can you take any guesses? It doesn't look shader related...

DXVK_SHADER_OPTIMIZE and DXVK_SHADER_VALIDATE do not visibly change the crash.

System information

  • GPU: GeForce GTX 1080Ti (crashing) / Radeon RX 480 (works)
  • Driver: Official driver 390.25 (crashing) / Mesa 17.3.2 (works)
  • Wine version: 2.21-staging
  • DXVK version: git 3dea58d

Apitrace file(s)

I can't get apitrace to produce a trace file for some reason.

Log files

From the no-op version, Linux under Nvidia
dxHelloworld1_console.log
dxHelloworld1_d3d11.log
dxHelloworld1_dxgi.log

Ppdaniell-nv 2018-03-05 github

Nothing obvious comes to mind. The console.log thinks there are some spec violations to do with the framebuffer attachment being too small. That is quite likely to cause a GPU exception since the GPU may attempt to access outside the framebuffer allocation.

Rroothorick 2018-03-05 github

For reference, here are logs of the same testcase running (successfully) under Mesa 17.3.2 radv on an RX 480. I made sure validation layers are installed and enabled (made that mistake before).

Clearly either the Nvidia driver is misinterpreting something, or it responds to an earlier call in a different but (presumably) valid way which causes the application to behave wrongly at the point where the validation errors pop up. My gut is starting to think it's the latter. I'm about to start in on trying to make this testcase compile and link under MinGW-W64 so it'll hopefully have symbols that winedbg can make sense of.

dxHelloworld1_console.log
dxHelloworld1_d3d11.log
dxHelloworld1_dxgi.log

Ddoitsujin maintainer 2018-03-05 github

The problem with the framebuffer being too small happens in some applications, but I still have absolutely no idea why that happens, where that happens, or how to reliably reproduce it.

The framebuffer size is generally derived from the size of the render targets, so unless an application mixes render targets of different sizes, or an image that is not created by D3D11 for some reason stores incorrect information about its size, there is no way this can happen.

Rroothorick 2018-03-05 github

unless an application mixes render targets of different sizes

Definitely could see a VR app doing this. At a minimum, it will have two render targets, one for each eye, however it would be incredibly bizarre if these were different sizes. It may use a third as an interstitial for rendering to the desktop window for various reasons. It'd be odd for this testcase to be doing that, but I haven't had too close a look at what this application does.

Ddoitsujin maintainer 2018-07-12 github

Is this still an issue?

Rryao 2018-09-20 github

@roothorick ^

Launch options