Dxvk: The Witness

[notaz]

A nice puzzle game with no Linux version available that has rendering problems with wine's d3d11 implementation. Uses multisample textures and alpha-to-coverage.
https://bugs.winehq.org/show_bug.cgi?id=42820
https://bugs.winehq.org/show_bug.cgi?id=42819

log with low settings: http://notaz.gp2x.de/tmp/dxvk/wit_u
log with high settings: http://notaz.gp2x.de/tmp/dxvk/wit_u_hi

[doitsujin]

Thanks for the report. Seems like the game crashes because D3D11DeviceContext::Map still does not support images properly. I'll work on that, since more applications are popping up that need this.

As for high settings, the bug that causes issues with the SPIR-V compiler should hopefully be fixed in https://github.com/doitsujin/dxvk/commit/aa02612b9e5c5eb0e69ced0f3b71b5fb6da9037c.

If you can, please create a D3D apitrace (preferably on Windows) so that I can test locally. Multisampling and Alpha to Coverage is something that isn't exactly well tested, and some related feature are not implemented yet.

[doitsujin]

I implemented the remaining modes for image mapping, so the game should hopefully not crash anymore. Can you test again with lastest master?

GenerateMips is still not implemented though, so even if it runs it probably won't display textures correctly.

[notaz]

No longer crashing indeed, thanks, but there are missing things like you said:
http://notaz.gp2x.de/tmp/dxvk/witness2.jpg

The log says:

warn: DxbcCompiler: Unhandled opcode class: DxbcOpcode::SampleB
warn: D3D11Query: Unsupported query type 2
warn: D3D11Query: Unsupported query type 3
warn: D3D11Query::GetData: Stub
err: D3D11DeviceContext: GetData: Data size mismatch
radv_descriptor_set.c:276: VK_ERROR_OUT_OF_POOL_MEMORY_KHR

with the last 2 lines spammed continuously.

I don't currently have working Windows setup, but maybe I can get something with a vm and GPU passthrough later.

[doitsujin]

I implemented the missing features, please test with latest master. The last two messages should not cause too much trouble, although any sort of log spamming may degrade performance.

As for apitrace, you can also try to run the Windows version of apitrace through wine, but it might not work. I've had some trouble with it with wine-staging, seems to be a bit more reliable on wine 3.0.

[notaz]

Unfortunately while "Unhandled opcode class: DxbcOpcode::SampleB" is gone, the rendering is still not correct. I'm not sure if it improved at all.

I think I've managed to get the traces with wine. They seem to replay for me with both wine's d3d11 and dxvk.
low settings: https://drive.google.com/file/d/1eIZkwX_PvkkePhrV1-BB2JGXkvWQZVzG/view?usp=sharing
high settings: https://drive.google.com/file/d/1TXpNn95gRnAxJDfHyeoh2bclcuejXQFk/view?usp=sharing

[doitsujin]

Thanks for providing the trace files, I'll look into it.

[doitsujin]

Haven't been able to figure out what exactly is causing the issues, but with mesa-git and RADV_DEBUG=nohiz it seems that the high settings preset renders correctly. Can you test that?

As for the low preset, it looks like there is an insane amount of Z fighting going on but I don't know what might cause this at the moment.

[exolyte]

Can confirm the game is rendering correctly as long as multisampling is enabled. Using mesa 17.3.3 with RADV_DEBUG=nohiz.

[notaz]

With multisampling it's indeed rendering almost correct. However the water reflections seem to be broken - it renders them once but they do not update, when camera is moved the reflection stays at the same screen location and plain color appears at the areas of screen newly taken by water. Every several seconds it updates for one frame and stops again.

Unfortunately I wasn't able to reproduce it with a trace, with it "warning: failed with 0x80070057 (E_INVALIDARG): Invalid parameter." is spammed every frame and it behaves more like "low settings" trace. It replays correctly with wine's d3d11, so I've uploaded it anyway:
https://drive.google.com/file/d/1fFCVytDdybsVgZqiTIKS5XseegIO5yzc/view?usp=sharing

[notaz]

There seems to be a regression, now the game gets stuck in some kind of loop. Also reproduceable with the traces. Bisect result:
commit 5334ff57bff0521bf3ad5b22ccd7f8c405aea6c9
[d3d11] Wired up D3D11Query to backend

[doitsujin]

I cannot reproduce this with any of the trace files. Is there any indication what the game might be doing when it freezes (i.e. CPU load, debug messages)?

Please also try to instrument the following D3D11DeviceContext methods with debug info: Begin, End, GetData

[doitsujin]

@notaz Probably the same issue as #96. Can't reproduce either problem, so the only option I see is to disable queries entirely again.

[notaz]

With query fixes the water-not-updating issue went away, now it's updating but is seemingly behaving the same way like the whole game renders when MSAA is off ("low settings" trace from https://github.com/doitsujin/dxvk/issues/10#issuecomment-359180226).

Random guess: could there be something wrong when ATOC is used without multisampling? There is some information in this wine bug: https://bugs.winehq.org/show_bug.cgi?id=44590

[doitsujin]

Just tested that, doesn't work. As in the wine bug report, disabling Alpha to Coverage makes semi-transparent objects show up incorrectly, but does not solve the flickering. I still have no idea what causes this sadly.

[exolyte]

I tested this on windows with dxvk and did not experience any flickering so it might not be a dxvk issue.

[ekianjo]

@notaz small world :)

[exolyte]

The artifacts are gone when using amdgpu-pro 18.20 on my RX570, just like https://github.com/doitsujin/dxvk/issues/343#issuecomment-388325836 . There are artifacts with amdvlk.

RADV:

AMDVLK:

AMDGPU-PRO:

[hakzsam]

Hey guys,

I can reproduce the issue when multisampling is disabled on my Polaris. I will investigate.

[hakzsam]

This workaround [1] should fix the rendering issues both with and without multisampling. Can someone confirm? Also it would be nice to know if World of Warcraft is also fixed with that change. Thanks.

[1] https://hastebin.com/ibenemoyab

[exolyte]

I tested the patch with no multisampling and with 8x MSAA and both looked fine.

[libcg]

@hakzsam this patch also fixes the flickering seen on #191 when applied over mesa 18.0.4 (ac_nir_to_llvm.c:5501).

[notaz]

Confirming fixed here too.

Does this mean DXVK is incorrectly setting the centroid decoration somewhere, or is it a driver issue?

[doitsujin]

That's what I would like to know as well. As far as I'm aware, it is not illegal to set the Centroid and Sample interpolation modes when MSAA is disabled, but I might be missing something.

FWIW, I'm only setting Centroid when the DXBC shader actually specifies it for a given variable.

[hakzsam]

I think it's legal as well, I should have a proper patch soon.

[hakzsam]

Here's the patch https://patchwork.freedesktop.org/patch/224448/

[doitsujin]

Thanks, i'll close this issue since a patch is available.

[hakzsam]

Fixed in master with https://cgit.freedesktop.org/mesa/mesa/commit/?id=73df16dcee79e2281c8d8a830dbbe6655359c82d

The patch should be available in mesa 18.0.5/18.1.1.