doitsujin / dxvk

Vulkan-based implementation of D3D8, 9, 10 and 11 for Linux / Wine
zlib License
13k stars 833 forks source link

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

Closed ranplayer closed 2 years ago

ranplayer commented 2 years ago

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: https://github.com/ValveSoftware/Proton/issues/787

Software information

Game: Metal Gear Rising: Revengeance Settings: default

System information

Apitrace file(s)

Log files

Let me know if more information is needed.

K0bin commented 2 years ago

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

Does this fix it?

ranplayer commented 2 years ago

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 commented 2 years ago

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

ranplayer commented 2 years ago

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 commented 2 years ago

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

ranplayer commented 2 years ago

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

K0bin commented 2 years ago

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

ranplayer commented 2 years ago

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

K0bin commented 2 years ago

d3d9.zip

ranplayer commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.: 2022_04-05 00-59-39

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 commented 2 years ago

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

ranplayer commented 2 years ago

Guys, I've found out the commit responsible for the regression: https://github.com/doitsujin/dxvk/commit/b672c07a939dbc5643933676cbb2b76dbe2fed6b

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 commented 2 years ago

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 commented 2 years ago

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

SeongGino commented 2 years ago

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).