Games doesn't run with v.2.3 and Proton but are working fine with 2.2 and previous

[dreamhunt]

Hello,
I have a weird problem:
Some games (all UE 4 titles for example and Baldurs Gate 3) doesn't run with v.2.3 and Proton but are working fine with 2.2 and previous. If I use Wine or Wine-Staging (Tkg), the games are running fine. When I use DXVK 2.3 and Proton or ProtonGE, the games starts to a black screen and doesn't go further.

Software information

Generally all UE 4 games and Baldur's Gate 3. I remember some Unity3D titles but I can't recall the exact names.

System information

• GPU: GTX 1080Ti
• Driver: I tried all possible drivers from 525.125.06 to 535.43.09
• Wine version: Many Proton and ProtonGE versions, including Proton 8.0-3, Proton Experimental (BE), ProtonGE 8-15, etc.
• DXVK version: 2.3

Log files

Baldur's Gate 3 Proton 8.0-3.log

[Blisto91]

Is it still the same on current master https://github.com/doitsujin/dxvk/actions/runs/6240574600

Edit: wait you tried Experimental BE nvm.
Do you know how to compile and bisect dxvk?

[dreamhunt]

I know how to compile but not to bisect. I have the same problem with VKD3D as well. It's fine with 2.9 and it's not working with 2.10.

[dreamhunt]

May be it's a Pascal thing?

[doitsujin]

I don't really see why we'd break specifcally on Proton specifically on Pascal. There haven't really been any significant changes to the Vulkan feature set that we use anyway and I don't see anything suspicious in the log either.

[dreamhunt]

Yes, the log is useless here. I tried it on Nobara, Linux Mint and vanilla Arch Linux. All the same.

[simifor]

if you manually replace proton experimental's dxvk with an older version, do the games start?

[dreamhunt]

Yep, there's no problem.

[simifor]

seems like bisecting is your best option, what you need to do is:

git bisect start
git bisect good v2.2
git bisect bad v2.3

This will make git pick a commit in the middle of those. After that, you'll have to compile the project as normal and test it, if the problem is there you'll do git bisect bad, if the problem isn't there then git bisect good. Then git will change the commit again, so you'll compile again and repeat the previous step of marking good or bad commits, until you find the commit that introduced the issue.

[Blisto91]

Remember to do git submodule update --init --recursive between each bisect step to make sure submodules are updated correctly.

[dreamhunt]

It seems pretty time consuming. I'll try but I'm not sure I'm gonna make it.

[simifor]

In this case, it should be 7 compilations to find the bad commit (not telling you to do it, just giving some more info).

[dreamhunt]

Thanks, let's see if I can do this.

[dreamhunt]

Found it!
Bisecting: 23 revisions left to test after this (roughly 5 steps) [77f6f2a84b6a32a323d87dda28d7a884d8cf0571] [include] Bump Vulkan headers to v1.3.254

Now the game is running fine. What I should do further?

[simifor]

According to that, you still need some more steps, but you can try bringing the output of this `vulkaninfo | grep -i "instance version", I think it should be no lower than the one mentioned in that commit, but I'm not sure about it.

[dreamhunt]

Oh, I see. Now I have to finish all the steps. Thank you!

Vulkan Instance Version: 1.3.264

[dreamhunt]

The final result is this:

215c4f8f6fcbb6622b8dfdb87f906a46f21f37ce is the first bad commit
commit 215c4f8f6fcbb6622b8dfdb87f906a46f21f37ce
Author: Philip Rebohle <philip.rebohle@tu-dortmund.de>
Date:   Thu Jun 1 18:08:28 2023 +0200

    [dxvk] Enable VK_KHR_present_id and VK_KHR_present_wait if supported

 src/dxvk/dxvk_adapter.cpp   | 47 +++++++++++++++++++++++++++++++++++++++++++++
 src/dxvk/dxvk_device_info.h |  2 ++
 src/dxvk/dxvk_extensions.h  |  2 ++
 src/vulkan/vulkan_loader.h  |  4 ++++
 4 files changed, 55 insertions(+)

[Arcitec]

I will say right away that I don't have time to devote to this. I am just adding some hopefully useful information regarding a family member's computer.

• Fedora Workstation 38
• RTX 2070 Super with NVIDIA driver 535 (I can't remember the exact sub-version, it's the latest on RPMFusion right now).
• GNOME 44
• Kernel 5.15.x LTS and 6.2.x tested.
• Wine version: GE (WINE) in Heroic Launcher. Tried many versions, including the latest 8-15.

Wayland:

• DXVK 2.3 release: Works.
• DXVK 2.2 release: Works.

X11

• DXVK 2.3 release: Freezes the computer.
• DXVK 2.2 release: Works.

How it freezes the computer:

• The game screen briefly appears.
• As soon as you see the game render something, the desktop freezes. Nothing works. No alt tab, no super key, no "super + t to open a terminal" etc. There is NO game sound or music.
• Pressing Ctrl-Alt-F3 to switch to a virtual terminal works, but takes roughly 20 seconds.
• When the fullscreen virtual terminal appears, the X11 desktop disappears, and the game can be heard somewhat "unfreezing" in the backgrund and the game's music/sound will begin playing now.
• Attempting to switch back to the desktop (Ctrl-Alt-F2) does nothing/freezes again.
• Trying to killall wineserver doesn't unfreeze the computer.
• The only way out is systemctl reboot.

By looking at the DXVK 2.3 release notes, I am guessing that NVIDIA has issues on X11 with the VK_KHR_present_wait or VK_EXT_swapchain_maintenance1. Because this whole issue is very similar to past issues where NVIDIA GPUs have frozen when various swapchain/present features are used. I remember having to disable some features such as _id (present_id or something) to avoid freezes on NVIDIA, during the time when DXVK briefly un-blacklisted that broken NVIDIA feature. This new issue feels exactly like that one.

[dreamhunt]

How can I disable VK_KHR_present_wait or VK_EXT_swapchain_maintenance1? Any variable?

For me if I press Super+D (show desktop) and wait a fair amount of time. the game minimizes and I can kill it from Ksysguard or with kill -INT $(pgrep wine) but this freezes the PC again and I have to wait another minute or two. Yes, I'm on X11.

[simifor]

Hmm it's weird that present wait would be the issue as it should only be enabled on drivers past 535, but you originally tested with the 525 series as well. What driver did you use while bisecting?

[dreamhunt]

I tested it with 525.125.06 but the problem exisits on 535.43.09 as well. Is there a variable to disable this feature? I tried with VKD3D and there's such option:
VKD3D_DISABLE_EXTENSIONS=VK_KHR_present_id,VK_KHR_present_wait
It doesn't work on DXVK though.

[Arcitec]

I have found the root cause.

It happens when the following are all true:

• X11 is being used. It doesn't affect Wayland.
• An application is rendering via Vulkan.
• The Vulkan extensions VK_KHR_present_id and/or VK_KHR_present_wait are being used.
• NVIDIA's "Force Full Composition Pipeline" is enabled. This is a feature where NVIDIA's driver attempts to do implicit sync (vsync) to avoid screen tearing on X11.
• Disabling "Force Full Composition Pipeline" solves the issue.

PS: Just for reference, I checked the exact NVIDIA driver version on my family member's computer. They're on 535.104.05.

[Arcitec]

Some searching reveals that the "Force Full Composition Pipeline" NVIDIA bug was discussed back in June of 2023 already, by the author of VKD3D:

ValveSoftware/Proton#6869 (comment)

This confirms it. And several other people in that thread confirmed it too.

[dreamhunt]

Yes, now everything is working fine. Thank you for that!
Should I close the issue since it's not a DXVK bug?

[Arcitec]

@dreamhunt Happy to hear it helped you too! :)

I have noticed that "Force Full Composition Pipeline" isn't required on X11 anymore if you use Chrome-based browsers (I use Brave). It now synchronizes the display of fullscreen videos and doesn't have tearing anymore even without that feature enabled. So for me, I don't see any reason to keep that checkbox enabled anymore. It was always a hack, according to NVIDIA. That setting does something to force vsync on X11 by guessing about when each frame changes, to avoid tearing if apps don't handle vsync internally. Two years ago, it was absolutely necessary but now it seems fine to disable that setting. :)

As for reporting it to where it belongs, you probably saw the linked post where HansKristian from VKD3D said that he has reported it to NVIDIA back in June. I wasn't able to find his report (I searched for keywords in the entire Linux NVIDIA forum), and he hasn't replied with details about how he reported it, which leads me to assume that he has reported it to them privately.

It might help to also report it publicly just in case, so I made a thread via a trash account here:

https://forums.developer.nvidia.com/t/complete-gpu-crash-on-x11-with-force-full-composition-pipeline-and-vk-khr-present-wait-100-reproducible/267934

If you have an NVIDIA account (or can make one with a trash email quickly), you could add your voice to that if you wanna show NVIDIA that it's a confirmed issue.

Other than that, there's nothing else we can do but wait for NVIDIA to fix it.

@doitsujin I'd suggest that you keep the "crashing" feature enabled in DXVK. It's about time that NVIDIA fully fixes their driver instead of DXVK/VKD3D having to kludge/blacklist the broken feature. :) And each time it's "wallpapered over" by DXVK, to make the issue invisible, it just delays the pressure on NVIDIA to actually fix it. :) ❤️

[dreamhunt]

I'm actually mozo78 but I don't know why I can't write here with my main account and I'm using another one.
I'm using Firefox but I don't really see any problems thus far, there's no tearing at all.

[Arcitec]

I'm using Firefox but I don't really see any problems thus far, there's no tearing at all.

That's fantastic news. Two years ago, I remember that every video would tear in fullscreen on X11 in my browser. I was using either Brave or Firefox back then. And that's why I started using NVIDIA's "Force Full Composition Pipeline" workaround.

If Firefox doesn't tear in fullscreen, then that would mean both of the major browser brands work on X11 now. In that case, I really don't see any reason to keep the buggy NVIDIA setting anymore. It was always a hack and always caused various issues with the graphics rendering pipeline, frame delays, lower performance, etc. So it would be great if we can live without it now.

X11 is unsynchronized by default and means that we theoretically might see tearing in some apps now, but I think it's gonna be fine since we've both confirmed that browsers work, and the big app GUI toolkits like Qt and GTK nowadays handle synchronized (tear-free) rendering properly on their own.

It's nice that this driver bug taught me that I can finally disable the NVIDIA hack! ;)

Edit: The mpv video player has tearing on X11 now, but I can live with that while waiting for NVIDIA's final Wayland support sometime in 2024.

[dreamhunt]

Yes, it's great and thank you :)

[AngelCry]

I'm here just to confirm problem with dxvk 2.3 with another UE4 title - Evospace. Game run fine with dxvk 2.2, but with dxvk 2.3 crash on startup if focused. If unfocused, game load to menu even on dxvk 2.3, but crash once focused. Error message always same: "GameThread timed out waiting for RenderThread after 120.00 secs". Btw, i see here discussion about "Force Full Composition Pipeline" on NVIDIA causes problem, while i have is disabled, i have only "Force Composition Pipeline" enabled. I'm going to check with both disabled later, as is need reboot to take effect. Also, @Arcitec on nvidia forum say "NVIDIA driver 535+.", but actually 515.65 affected too (im on this version still)

[wchao96]

Just adding in dxvk 2.3 doesn't work with Rockstar Games Launcher (for RDR2). It says compiling shaders on the bottom left of the launcher and freezes. dxvk 2.2 works fine.

It also doesn't work for Honkai Star Rail, a unity game (free to play). On HSR it shows a black screen but the game is still running in the background. Again, works with dxvk 2.2.

Using Radeon 6700XT on radv Mesa 24.1.0-devel

Looks like it isn't limited to UE4 titles or Nvidia GPU's?

[Blisto91]

@wchao96 I am thinking that is likely unrelated to the original issue of the tread. I will try the ones you mention here later on AMD. Is the RDR2 launcher trough Steam or?

@AngelCry Did you come to any conclusion in regards to your setup?

[K0bin]

@wchao96 That is indeed unrelated, please open a separate issue.

[fodrice]

Made a workaround. This disables VK_KHR_present_id and VK_KHR_present_wait for nvidia.
fodrice@2f6d30d

[Arcitec]

@AngelCry

Btw, i see here discussion about "Force Full Composition Pipeline" on NVIDIA causes problem, while i have is disabled, i have only "Force Composition Pipeline" enabled. I'm going to check with both disabled later, as is need reboot to take effect. Also, @Arcitec on nvidia forum say "NVIDIA driver 535+.", but actually 515.65 affected too (im on this version still)

My comment was based on the source code of DXVK:

    // Unless we're on an Nvidia driver where these extensions are known to be broken
    if (matchesDriver(VK_DRIVER_ID_NVIDIA_PROPRIETARY, 0, VK_MAKE_VERSION(535, 0, 0))) {
      enabledFeatures.khrPresentId.presentId = VK_FALSE;
      enabledFeatures.khrPresentWait.presentWait = VK_FALSE;
    }

These features are disabled in DXVK unless you are on driver 535+. So you should not have any hanging due to that.

Still, I am curious if you would like to follow up with whether disabling composition pipeline helped you? I would assume it doesn't help, since only driver 535+ are affected by this bug. In older drivers than that, the present id/wait features were completely broken and that's why DXVK blacklists them in older drivers.

Edit: There was a very brief period where a DXVK release in 2023 un-blacklisted those features on older drivers, which broke NVIDIA drivers. If you are affected by that other issue, you need to update DXVK or Proton (which contains older DXVK versions).