search

doitsujin / dxvk

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

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

Open dreamhunt opened 1 year ago

dreamhunt commented 1 year ago

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

Log files

Baldur's Gate 3 Proton 8.0-3.log

Blisto91 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

May be it's a Pascal thing?

doitsujin commented 1 year ago

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 commented 1 year ago

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

simifor commented 1 year ago

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

dreamhunt commented 1 year ago

Yep, there's no problem.

simifor commented 1 year ago

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 commented 1 year ago

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

dreamhunt commented 1 year ago

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

simifor commented 1 year ago

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 commented 1 year ago

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

dreamhunt commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

Vulkan Instance Version: 1.3.264

dreamhunt commented 1 year ago

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 commented 1 year ago

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.

Wayland:

X11

How it freezes the computer:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

I have found the root cause.

It happens when the following are all true:

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

Arcitec commented 1 year ago

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

https://github.com/ValveSoftware/Proton/issues/6869#issuecomment-1605401031

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

dreamhunt commented 1 year ago

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

Arcitec commented 1 year ago

@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. :) :heart:

dreamhunt commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Yes, it's great and thank you :)

AngelCry commented 9 months ago

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 commented 8 months ago

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 commented 8 months ago

@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 commented 8 months ago

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

fodrice commented 6 months ago

Made a workaround. This disables VK_KHR_present_id and VK_KHR_present_wait for nvidia. https://github.com/fodrice/dxvk/commit/2f6d30d9d431533fd1711f0b51b2082f2d1ec272

Arcitec commented 4 months ago

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