[d3d9] Metal Gear Rising Revengeance: blank screen and freeze after selecting Full Screen

[ranplayer]

If you select "Full Screen" on the graphics options, the screen blanks and the system freezes. This is happening with Proton 7.0 with DXVK: 1.9.4. Using WineD3d the problems doesn't happen (and with Proton 6.3-8 using DXVK [1.9.2-13-g714ca482]).

There is a Proton issue for this problem: ValveSoftware/Proton#787

Software information

Game: Metal Gear Rising: Revengeance
Settings: default

System information

• GPU: GTX 970
• Driver: 510.60.02
• Wine version: Proton 7.0-1
• DXVK version: 1.9.4

Apitrace file(s)

• api trace

Log files

• d3d9.log

Let me know if more information is needed.

[K0bin]

https://github.com/K0bin/dxvk/tree/mgr

Does this fix it?

[ranplayer]

It doesn't, but produces a different effect: the screens blanks but keeps blinking and the system doesn't freeze.

I'm going to attach the build for reference:
dxvk-master.tar.gz

[K0bin]

I can no longer reproduce the problem. What graphics settings are you using otherwise?

[ranplayer]

I've just changed the resolution to 1080p and tried changing the window mode to fullscreen. Also tried just the window mode, but the result is the same. Could you share your build ? Perhaps I might have compiled it wrongly (I basically cloned your fork and executed ./package-release.sh master /your/target/directory --no-package)

[ranplayer]

I know what I did wrong. You are using a different branch. I'm going to recompile the DLLs.

[ranplayer]

I've recompiled the DLLs (./package-release.sh mgr /your/target/directory --no-package) and retested, but the issue remains.

[K0bin]

Works fine for me.
https://www.youtube.com/watch?v=plxl-MymzfA

[ranplayer]

Could you attach your build, please ? So we can say we have the same DLLs running.

[K0bin]

d3d9.zip

[ranplayer]

Same issue yet. I've noticed you tested with a previous Nvidia driver version (510.54.0). I'm going to downgrade the driver, and see if its related to that.

[ranplayer]

Didn't work either. I've also tried to change the kernel to 5.16, but the same result. It seems several users are facing this problem using different driver versions and GPU vendors: https://www.protondb.com/app/235460

The current workaround for Proton 7.0 is to change the graphics using WineD3D (PROTON_USE_WINED3D=1) and then restart with DXVK.

With Proton 6.3-8 the issue doesn't happen.

[K0bin]

Can you git bisect it down to the exact commit that broke it?

Here's a bunch of guide on how to do that:
https://www.tutorialandexample.com/git-bisect
https://www.metaltoad.com/blog/beginners-guide-git-bisect-process-elimination
https://www.youtube.com/watch?v=u9-toShXbBE

[ranplayer]

To be honest I have no knowledge of graphical stacks and related APIs, but I can have a look on the commits history to try figuring out.

So far I know the problem starts with DXVK 1.9.3. So it something between DXVK 1.9.2-13-g714ca482 (Proton 6.3) and 1.9.3.

[K0bin]

To be honest I have no knowledge of graphical stacks and related APIs

That's fine. It would be a huge help if you could figure out the exact commit that broke it. Git bisect is a tool to help with that. It basically does a binary search and each step you tell it whether the version is broken or not.

[ranplayer]

I have been testing commits with build artifacts associated, but at some point they are marked as "expired" and you no longer can download them. So now it is harder because every change has to be compiled.

[SeongGino]

Not OP, but I've tried this out for myself to mixed results.

The good news is, the pre-compiled library @K0bin produced fixes my scaling issue with MGR - it'll only ever fill a 1920x1080 space, even when running in Fullscreen at startup on a 4K display.
i.e.:

Bad news is, at least on KDE 5.24.4 Arch, toggling between Windowed/Fullscreen still causes the FS'd window to spaz out and require either a reboot or switching away from X11 to a new tty to forcibly kill the offending process.

Proton 6.3-8, without the d3d9 override, has the aforementioned scaling issue but will indeed between windowed modes without nigh-irreparable effects.
(Before asking: yes I've tried forcing FS on the window with KWin rules - all that happens is I get a tiny window instead of a quarter of a window).

[K0bin]

Maybe you can bisect this down to a commit if this is indeed a regression. As mentioned earlier, I can't reproduce it.

[ranplayer]

Guys, I've found out the commit responsible for the regression: b672c07

Here is the build for this commit: dxvk-b672c07a939dbc5643933676cbb2b76dbe2fed6b.tar.gz

Here is the build for the commit before that still works:
dxvk-1abd205216f56756e8020f781d7d817e2b40f241.tar.gz

[ranplayer]

I think this issue might be related to specific window managers based on the commit that introduced the regression. I've tested with Kwin/Plasma (Plasma 5.24.3) like @SeongGino

[ranplayer]

I've tried openbox as well, but the issue remains. So I'm probably wrong.

[SeongGino]

#2588 does seem to fix the freeze, but MGR still doesn't scale on >=1080p display with the new artifacts (but @K0bin's library does).