Do the games you have tried have anything in common like engine or bitness?
Also does this happen with older drivers?

If you're using Nvidia PRIME I'd recommend trying:

• switching to Nvidia (Performance Mode)
• launching games with DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce" when using dxvk
• avoid using HDMI outputs entirely if possible due to driver jank around these kinds of setups (DisplayPort will generally be fine)

Do the games you have tried have anything in common like engine or bitness? Also does this happen with older drivers?

No, they do not have anything in common. Any games on any engine be it Source, Unity or Unreal 4 or 5, be it 32-bit or 64-bit game - it will crash.

If you're using Nvidia PRIME I'd recommend trying:

* switching to Nvidia (Performance Mode)

* launching games with `DXVK_FILTER_DEVICE_NAME="NVIDIA GeForce"` when using dxvk

* avoid using HDMI outputs entirely if possible due to driver jank around these kinds of setups (DisplayPort will generally be fine)

I use Nvidia only when playing games.

I did this right now. The result is the same.

I don't use HDMI outputs, the only output I have is the built-in laptop screen.

EDIT: newer logs.

borealAlyph_dxgi.log
borealAlyph_d3d9.log
steam-812370.log

I don't use HDMI outputs, the only output I have is the built-in laptop screen.

Alright, that should be fairly straight forward then. I'm on a NVIDIA GeForce RTX 4060 Mobile, but can't reproduce the behavior you're describing, everything is stable here. I've just played The Witcher 3 for about 3 hours or so, FWIW.

Does anything appear in dmesg or journal when a game crashes?

Does anything appear in dmesg or journal when a game crashes?

No. Literally nothing.

Just noticed you are using dxvk 1.7 for some reason... how about upgrading to 2.5.1, since nobody tests ancient versions on new drivers? And please use all the dlls from a given version, don't mix and match. Your dxgi reports dxvk version 2.4, while d3d9 reports dxvk 1.7. That is not normal.

Just noticed you are using dxvk 1.7 for some reason... how about upgrading to 2.5.1, since nobody tests ancient versions on new drivers?

How do I do this on Steam Proton?

You seem to have a d3d9.dll in the game folder so that is being used instead of the one Proton ships

You seem to have a d3d9.dll in the game folder so that is being used instead of the one Proton ships

O h . . .

Let me resolve that really quick.

DXVK v2.5.1:

borealAlyph_dxgi.log
steam-812370.log
borealAlyph_d3d9.log

ONE NOTE THO: capping FPS down to 60 increased the time before the game crashes. If uncapped, the game usually crashes almost instantly. If capped - I can play for a few minutes before it will crash.

I don't see anything relevant in the logs sadly, so it's very unlikely anything odd happens inside dxvk code.

ONE NOTE THO: capping FPS down to 60 increased the time before the game crashes. If uncapped, the game usually crashes almost instantly. If capped - I can play for a few minutes before it will crash.

That sounds like some sort of system instability or overheating perhaps? Not much we can help with here I'm afraid.

I don't see anything relevant in the logs sadly, so it's very unlikely anything odd happens inside dxvk code.

ONE NOTE THO: capping FPS down to 60 increased the time before the game crashes. If uncapped, the game usually crashes almost instantly. If capped - I can play for a few minutes before it will crash.

That sounds like some sort of system instability or overheating perhaps? Not much we can help with here I'm afraid.

What's weird is that if there's no DXVK - everything works just fine. I played CS2 on Vulkan for 4 hours straight and I played Minecraft on OpenGL for 2 hours straight with no crashes like that and I completed FEAR on WineD3D with no crashes.

You don't perhaps have any overlays or such running? Might also be worth trying to disable steam overlay.
Does it also happen on say the 535 drivers?

You don't perhaps have any overlays or such running? Might also be worth trying to disable steam overlay. Does it also happen on say the 535 drivers?

I have tried 530 drivers - it happened there.

No overlays are running.

Don't have any good ideas then sorry

Don't have any good ideas then sorry

Any ideas on how to softwarely increase stability?

FPS limits or power caps can improve stability on some setups. For the former you can just use the dxvk fps limiter. The later i haven't really messed with so not familiar with what software to use.

Don't have any good ideas then sorry

Any ideas on how to softwarely increase stability?

Possibly disabling power saving functionality (GPU, CPU, PCI-e, etc.)

HAs anyone tried to make this work with War 3 Reforged and Diablo 2 Ressurrected?
DX11 in those games is more of an issue than help.

I was thinking of making a thread about this but this one pretty much asks the same question as i since the game crash before it loads

Diablo 2 Resurrected does not support D3D11. VKD3D-Proton can run the game just fine though.

War 3 reforged crashes when trying to load the game

I'm also seeing this issue, and I think the not a bug label ought to be removed pending further investigation. I can consistently reproduce this across multiple versions of DXVK (including 2.5.2 just released), with multiple different versions of Wine (8.26, 9.22, 9.22-staging, 9.22-tkg). The issue only appears under DXVK. If the game is using VKD3D, the issue disappears.

The game will play fine for some amount of time, typically a few minutes, before freezing. It does not hard crash. I cannot locate anything in the logs that corresponds to the moment of freezing.

I do have a PRIME setup, and I think that's related. I have not seen this issue on any non-PRIME machines in an otherwise similar setup (same distro, same Wine build, same game/version).

Occurs on Nvidia drivers 550.135, and 565.77.

It's not load related. I have tried setting Nvidia to performance profile. I have ensured the dedicated charger is plugged in to ensure the GPU has sufficient current. I have monitored the GPU usage. The game in question is WoW Classic, which is not hitting the GPU very hard (RTA 5000 Ada). Issue occurs even on minimum settings and resolution.

I have tried loading the machine with Linux native games from Steam. None of them exhibit the issue, even at very high GPU load.

I do have a PRIME setup, and I think that's related. I have not seen this issue on any non-PRIME machines in an otherwise similar setup (same distro, same Wine build, same game/version).

If it's PRIME related, just follow these steps and it should be sorted: https://github.com/doitsujin/dxvk/issues/4503#issuecomment-2509084021.

I was having regular freezes that I can only attribute to Vulkan device order changes (device lost type errors), but the issue hasn't reoccurred after setting a dxvk device filter for the card you intend to use with games (typically Nvidia) and avoiding to use HDMI altogether. Using HDMI over a DP-to-HDMI adapter will work.

The lockups when using HDMI outputs directly are common to all Vulkan applications and are in fact caused by the Intel driver stack when using the "On Demand" PRIME mode.

If it's PRIME related, just follow these steps and it should be sorted: [#4503 (comment)](https://github.com/doitsujin/dxvk/issues/4503#issuecomment-2509084021).

Already doing all of these.

It's not load related. I have tried setting Nvidia to performance profile. I have ensured the dedicated charger is plugged in to ensure the GPU has sufficient current. I have monitored the GPU usage. The game in question is WoW Classic, which is not hitting the GPU very hard (RTA 5000 Ada). Issue occurs even on minimum settings and resolution.

Just to clarify, did you try to limit the framerate? In my case, limiting the framerate extended the time before freezing.

Just to clarify, did you try to limit the framerate? In my case, limiting the framerate extended the time before freezing.

I've been using vsync and the framerate has been a steady 60 FPS. Limiting it below that isn't an acceptable solution, especially if it still freezes eventually. Might as well fall back to VKD3D, but the performance with WoW is nowhere near as good as DXVK.

Edit: I've been able to confirm that disabling vsync / frame cap makes the game freeze much sooner. But this is not an indication that it's load related, because monitoring doesn't suggest the GPU is highly loaded, and I cannot reproduce in any non-DXVK scenario, even with dedicated Vulkan benchmarks.

To me it suggests something like a counter overflowing, but I have no idea to begin where to look to debug this.

To me it suggests something like a counter overflowing, but I have no idea to begin where to look to debug this.

In my case limiting the framerate down to 35 lets me play the game for a good while.

Seems like some kind of... Memory leak or overflow, yeah.

DXVK v2.5.1:

borealAlyph_dxgi.log steam-812370.log borealAlyph_d3d9.log

ONE NOTE THO: capping FPS down to 60 increased the time before the game crashes. If uncapped, the game usually crashes almost instantly. If capped - I can play for a few minutes before it will crash.

Interesting.
I have the same issue on windows with dgvoodoo 2's DirectX12 Output and only at 4k

Interesting. I have the same issue on windows with dgvoodoo 2's DirectX12 Output and only at 4k

Um... What does this have to do with DXVK acting up?

@seacat17 Could you please list some games that have this problem on your system?

I just played several hours of Mass Effect Legendary edition on Proton without any problems (Nvidia GPU too). So it obviously doesn't affect every game. We do need a few examples for games where you are sure that you ran into this problem to investigate further.

Indigo Park, Voices of The Void, Phasmophobia, Astroneer, F.E.A.R., Boreal Alyph...

Should I continue? These games have little to nothing in common.

Got same problem with Scrap Mechanic and Deep Rock Galactic.
HP Pavlilon Gaming Laptop 17.
Arch Linux. Proton 9.
00:02.0 VGA compatible controller: Intel Corporation CometLake-H GT2 [UHD Graphics] (rev 05)
01:00.0 VGA compatible controller: NVIDIA Corporation TU116M [GeForce GTX 1660 Ti Mobile] (rev a1)
nvidia-dkms - latest. All drivers updated just now.
Games 100% will freeze after 1-2 minutes of gameplay.
The only fix known by me - run second X server using startx command.
Set DISPLAY=:1 %command%. Run the game from the first server, jump to second.
Problem will not disapear, unfortunately... Game will freeze after 10-15 minutes, BUT swaping back to first X server and back to second again has 50/50% chance fixing it... (also it looks like game was freezed before and unfrezes in 1-2 seconds after swap)
And yes: NO WINDOW MANAGER on second X server! openbox/xfce4/KDE any manager will freeze the game after 5 minutes of gameplay...
About Deep Rock Galactic -> it shows a crash message a few minutes after frezze, but crash message window are also freezed, buttons can't be pressed and cursor stands in <-> mode, like I am trying to edit window size.
Also if mangohud is used it freeses complety too...
P.S. Changed nvidia-dkms to nvidia-open-dkms as arch wiki says -> nothing changed
P.S.2. After long play (45-60 minutes) sugnificant fresses on any input (mouse/keyboard) apears, HUD shows that FPS is around near 40 (limit 45) but it feels almost like playing with 10 fps... Same for both games. Still playable, but meh...

Also, needs to say that that issue didn't appear for me before 2024 year... So... Maybe it's not dxvk bug, but... What the hell must be responsable for such a terrific problem? Updates to the linux core it self? Or maybe something related to Nvidia PRIME tech?

Testing startx launched with prime-run option... Probably it will help with input lags...
P.S. Not hepled. Input lags still appear. I will try removing term instace from second server to make it complety empty... But I guess it will not change anything, case term already was drawn by GPU (prime-run startx)...
Proton-9... Deep Rock Galactic. On second X server: 38 minutes without input shuttering on 45 fps...
Well... I don't think this problem will have a quick fix...

Same thing, it all started in summer of 2024.

Is it ok that FSD-Win64-Shipping.exe (Deep Rock Galactic) are working in C+G mode?

Well... Guess it's a bug, but not dxvk bug...
I tried vkd3d-proton and got the same results... Also setting NVIDIA as primary GPU for X server not helping at all...
I guess the problemmis MUCH deeper than dxvk bug... If not drivers then, probably changes in linux core or in X server it self might be the reason of this... It also looks like it's not affecting video memory at all... nvidia-smi shows no changes...

Well... Guess it's a bug, but not dxvk bug... I tried vkd3d-proton and got the same results... Also setting NVIDIA as primary GPU for X server not helping at all... I guess the problemmis MUCH deeper than dxvk bug... If not drivers then, probably changes in linux core or in X server it self might be the reason of this... It also looks like it's not affecting video memory at all... nvidia-smi shows no changes...

VKD3D acts weird for me. With capped FPS I was able to complete Indigo Park without a single crash but with uncapped FPS I got crashed even before main menu could display.

VKD3D acts weird for me. With capped FPS I was able to complete Indigo Park without a single crash but with uncapped FPS I got crashed even before main menu could display.

My FPS is always capped (45), but it not helping much... As I said before, after 38 minutes of gameplay with any directX game any input turns my 45 FPS into 10 FPS, mouse click, key press -> 5 or 4 skipped frames, If I stop pressing, normal FPS returns...
Also tried to https://wiki.archlinux.org/title/NVIDIA_Optimus#Use_NVIDIA_graphics_only...
Same results like nothing changed...
I will try replacing nvidia-dkms with basic nvidia, and downgrading xorg and linux-core it self, but I don't think it will change anything... The problem should be inside xorg because when using no window manager the problem with full freezing disapears completly (sometimes returns, but can be easily fixed by swaping two X servers).
Maybe I will be able to found the reason of the problem but guess it time to throw my laptop out of the window and buy a new one with normal GPU...

Also need to say that when launching steam and game on the same server the problem with input shutering and freezes that forces you to swap the server apears in 10-15 minutes and annoys much more frequently...

Very ""good"" New Year present actualy... Another bug that probably will not be fixed in next 2 years... Maybe I realy should return back to Windows...

Maybe full Linux system downgrade will help? I mean from linux-core and nvidia drivers to steam it self?
Can someone with the same problem try it? Pretty please? I have no Idea how to do full downgrade without bumping into dependencies issue...

My FPS is always capped (45), but it not helping much... As I said before, after 38 minutes of gameplay with any directX game any input turns my 45 FPS into 10 FPS, mouse click, key press -> 5 or 4 skipped frames, If I stop pressing, normal FPS returns...

That sounds like this Steam issue https://github.com/doitsujin/dxvk/issues/4436
Try running it with LD_PRELOAD="" %command%

New data... Problem seems to appear only in 3D scenes... I tested 2d visual novel that uses dxvk on my main X server and there was no freezes completly... Or probably it had not enought time to produce an error...

New data... Problem seems to appear only in 3D scenes... I tested 2d visual novel that uses dxvk on my main X server and there was no freezes completly... Or probably it had not enought time to produce an error...

I also tried running another Xorg server on another tty and guess what? I am playing Indigo Park with DXVK with FPS uncapped for like 15 minutes now. No crashes so far.

That sounds like this Steam issue #4436
Try running it with LD_PRELOAD="" %command%

Damn! Looks very familiar! Thanks! If it helps this issue could be marked as "partly-closed": I will post some kind of tutorial, how to launch a game on completly empty X server launched with default startx command.

That sounds like this Steam issue #4436
Try running it with LD_PRELOAD="" %command%

Damn! Looks very familiar! Thanks! If it helps this issue could be marked as "partly-closed": I will post some kind of tutorial, how to launch a game on completly empty X server launched with default startx command.

That sounds like this Steam issue #4436
Try running it with LD_PRELOAD="" %command%

Damn! Looks very familiar! Thanks! If it helps this issue could be marked as "partly-closed": I will post some kind of tutorial, how to launch a game on completly empty X server launched with default startx command.

The thing is that I cannot take screenshots or capture that Xorg server in any way. Maybe there is a way to just fix this issue with all the data we gathered so far?

That sounds like this Steam issue #4436
Try running it with LD_PRELOAD="" %command%

Thank you very much! You have no idea how long I suffered from that! That's awesome!!!!!
More than 1 hour and game still running with no issues!

@seacat17, this is data from my experiments with dxvk freezes in my system.

The first solution for that problem (found by me) was diabling ability of my window manager to control game window:
The game window was controled only by wine (Alt-Tab will not work!).
You probably should try that, and set game window mode to windoped. On my system with that solution EVERYTHING outside game window freezes after 1-2 minutes of gameplay (that how I figured out that the reason of full dxvk freeze might be window manager). After that I swaped my xfce4 to openbox once, but got the same result - freeze.
If game window controled by manager - game freezes, if wine controls game window - xfce or open-box will freeze until game stop running.
So, after that I decided to run second X server.

My current solution:

1. Jump to tty2 and login. Ctrl+Alt+F2
2. Run startx ./xinitrc_game from it
3. Jump back to tty1 where main X server running
4. Run game from steam using DISPLAY=:1 mangohud %command% (or dxvk hud)
5. On game steam page after clicking |> Play wait until it changed to x Close and jump to second X server immediatly!
6. After that the game will work on second X server with steam launched on first, without any additional scripts or configuartions.

Yes, that solution is quite cursed, but work for me, hope it works for everyone who will face such problem with dxvk...
Also need to say that I am not sure who must be guilty for that bug: window manager or xorg it self:
I tried launching steam on second X server and run game right there, but bumped into freezes again.
No window manager, only xterm, steam and game, and it still freezed - but as I said before it can be easily turned back to life by jumping back to first X server and then back to second. So, probably the bug provider is located inside xorg it self...

Also need to say that this "solution" is not perfect: if you jumped to first X server and spend a few minutes in it (5+ minutes) most games will crash (and, it also may case some small problems with some progs on first server too)! This probably can be fixed with a few tweaks (withServerLayout options probably) inside xorg.conf but I am not very skilled in configuring xorg nvidia and all other GPU & rendering related stuff...

Here is my ./xinitrc_game script: xinitrc_game.txt
It has only a few differences from default ./xinitrc.
xterm -geometry 0x0+0+0 - because it may case another freeze if xorg is responsible for fresses (so I made xterm as small as posible like it's not exist at all)
twm & and xclock -geometry 50x50-1+1 & also commented, because they also can probably affect dxvk...
If you are not afraid of axidental but fixable freeses, then you may use default ./xinitrc.

Also xorg.conf: xorg.conf.txt
Generated by nvidia-config mostly but with a few changes...
Proabably it will help to understand what can be the cause of that issue.

I am not very sure about this "fix", but it helped me, and I hope it will help you.

I did it a bit differently.

I jumped to tty2, did startx, then I jumped back to tty7 and in Steam I used DISPLAY=:1 variable. That's all. Now I spent 4 hours playing a game that was completely unplayable for me before.

I did it a bit differently.

I jumped to tty2, did startx, then I jumped back to tty7 and in Steam I used DISPLAY=:1 variable. That's all. Now I spent 4 hours playing a game that was completely unplayable for me before.

Good to know... Crossout is still unplayable for me, unfortunatly, but it mosuly because of stack smashing problem, artifacts on wined3d render (so, it's imposible to play on it) and it's undisableable launcher... I need to search for more info about xorg and dxvk, so Crossout can be at least playable on second X server...

FOUND IT! The main problem is X11 server. I just installed labwc that uses Wayland instead of X server. And run xfce4 in startxfce4 --wayland mode.
There are a very big bunch of problems because xfce4 Wayland support is on alpha stage, but in Gnome and KDE using Wayland shuld be fine. So... Problem completly gone. For DXVK and for VKD3D.
So, I guess this issue is related to this one: https://github.com/doitsujin/dxvk/issues/3670#issuecomment-1732691158
And probably this one: https://github.com/lutris/lutris/issues/5058

So, I guess the best solution is replacing X11 display server with Wayland alternative, so you can run games as before and probably with even better speed and fps stability, since wayland is younger that X11 and probably has much less hidden bugs...

FOUND IT! The main problem is X11 server. I just installed labwc that uses Wayland instead of X server. And run xfce4 in startxfce4 --wayland mode.
There are a very big bunch of problems because xfce4 Wayland support is on alpha stage, but in Gnome and KDE using Wayland shuld be fine. So... Problem completly gone. For DXVK and for VKD3D.
So, I guess this issue is related to this one: https://github.com/doitsujin/dxvk/issues/3670#issuecomment-1732691158
And probably this one: https://github.com/lutris/lutris/issues/5058

So, I guess the best solution is replacing X11 display server with Wayland alternative, so you can run games as before and probably with even better speed and fps stability, since wayland is younger that X11 and probably has much less hidden bugs...

No way I'm using Wayland. I hate Wayland, everything it does is breaking things, and also the DE of my choice won't work on Wayland.

Is there any way to contact the only remaining Xorg dev?

No way I'm using Wayland. I hate Wayland, everything it does is breaking things, and also the DE of my choice won't work on Wayland.

Well... I am not into Wayland too, but I love games more than hate Wayland. It just helps me play games on the same display without X11VNC instalation or constant jumping from one screen to other. So I can just enable youtube on background and listen my favorite chanels with no problems.

Also I found out that in fullscreen mode on Wayland my GPU heats less then on X11. (4C degree difference)
Current GPU chip is new, old one died from overheat (Yea, HP Pavilion Laptops has worst coolling ever) so, probably in future I will use Wayland only, because 80C+ temp on normal quality settings in almost ANY dxvk games is quite big...
Last time I played Deep Rock Galactic it was near 76C which is great, I think.

Is there any way to contact the only remaining Xorg dev?

What the? Excuse me, did Xorg really mantained by ONE person???? Thats horrible!
Now I am really scared about Xorg future and ammount of bugs it may have...

Probably it's posible to contact them throught GitHub, but I don't think they will do anything to fix this problem...
This bug related only with DXVK but not all other apps.
So DXVK it self should adapt to new environment, not xorg...

So. At this moment next solutions are avaliable:

1. Run games on second X server.
2. Use this one - it do nothing for me but may help you, to run games on X11 as before:
   • Disable "Force Full Composition Pipeline" in xorg.conf, OR
   • replace DXVK with VKD3D and use VKD3D_DISABLE_EXTENSIONS=VK_KHR_present_id,VK_KHR_present_wait %command%
3. Replace X11 with Wayland and problem will disapear (better to use GNOME or KDE or Wayland may case much more problems related to all other apps...)
4. Install Wayland and compositor (see this) to run steam it self on second display. It probably may help launching games like Crossout and WarTunder when your main desktop session is under X11. (Launching Crossout using solution 1 will produce the same problem with DXVK).

I use MATE which is not compatible with Wayland.

I have HP Pavilion laptop too, with 100% load it heats up to 67°C max. Also
I have external cooling system that cools it down to 60°C.

I will try those solutions once I'm home.

@MAGGen-hub

Disable "Force Full Composition Pipeline" in xorg.conf

How do you do this?

@MAGGen-hub

Disable "Force Full Composition Pipeline" in xorg.conf

How do you do this?

Look here: https://github.com/ValveSoftware/Proton/issues/6869#issuecomment-2586753701
I tried it, but got error. Because in my version of Nvidia Optimus there is no way to control "metaopts" (or something like that). It's probably possible to set this property through xrandr or something like that, but I have absolutely no idea how and really have no will to experiment with that kind of stuff...

Last time I messed up with Nvidia drivers (not related to this issue), it took three hours of my life to reinstall them correctly... So I am still afraid of ANY stuff, related to Nvidia, Xorg, and all their almost INFINITE configs...

If you use HP Pavilion laptop too, you also may bump into same problem. If you find solution how to set it correctly, please tell me. I found a forum, with the same problem, by typing my error in google, but still don't get how to fix it...

I wrote a few scripts in Lua for Xfce, so using Wayland may become a bit more comfortable, but... Meh... Xfce is still xfce, and it's Wayland support is not very good:
Still looking for way to display keyboard layout in tray when Xfce is under Wayland. Also some icons form xfce4-panel renders over games in fullscreen mode, so I made bash script to hide that panel when playing in fullscreen...
Hacks, scripts and hacks again...
Sometimes Linux make me feel like a real hacker: tired, confused, exhausted, with constant need in coffee...

Any fixes for this one so far? I really am tired of this bug...

I am sadly not aware of any of the devs or testers having reproduced this

I am sadly not aware of any of the devs or testers having reproduced this

...out of all the Linux+Nvidia gamers I'm one of those lucky ones who got this stupid glitch...

I think I'm gonna do a full driver and then system ditch and reinstall to see if that helps.

Just to clarify, did you try to limit the framerate? In my case, limiting the framerate extended the time before freezing.

I've been using vsync and the framerate has been a steady 60 FPS. Limiting it below that isn't an acceptable solution, especially if it still freezes eventually. Might as well fall back to VKD3D, but the performance with WoW is nowhere near as good as DXVK.

Edit: I've been able to confirm that disabling vsync / frame cap makes the game freeze much sooner. But this is not an indication that it's load related, because monitoring doesn't suggest the GPU is highly loaded, and I cannot reproduce in any non-DXVK scenario, even with dedicated Vulkan benchmarks.

To me it suggests something like a counter overflowing, but I have no idea to begin where to look to debug this.

@aeadio I'm deeply sorry for pinging you but could you please provide some logs from your side? We have the same problem. If you already solved it, please tell me how you did that.

I basically just bombed my Nvidia drivers and installed NVK.

I played VOTV for half an hour with AWFUL performance just to ensure that the problem does not occur on open-source drivers. It does not.

Now I'm gonna try nvidia-dkms-535.113.01-2

After installing proprietary drivers again the issue reappeared IMMEDIATELY.

go to /etc/X11/xorg.conf.d/
ls /etc/X11/xorg.conf.d/
there should be file named like 20-nvidia.conf
(could have different number)
edit it:
sudo nano -w /etc/X11/xorg.conf.d/20-nvidia.conf
find and remove lines:
Option "ForceFullCompositionPipeline" "on"
Option "ForceCompositionPipeline" "on"
and restart X server (or you pc if you do not know how to restart only xorg)

Or you can do this with nvidia control panel it will edit config for you.

Or manually downgrade dxvk to 2.2 version It should work. (https://github.com/doitsujin/dxvk/issues/3670#issuecomment-1732691158)

You could try this dxvk builds ( khrPresentId and khrPresentWait disabled for nvidia )
dxvk-2.3.1-nv.zip
dxvk-2.6-nvidia-fix.zip

You could try this dxvk builds ( khrPresentId and khrPresentWait disabled for nvidia ) dxvk-2.3.1-nv.zip dxvk-2.6-nvidia-fix.zip

I'm sorry but after all I've went through I sacrificed my comfort and moved to Wayland... I still have X11 so i might test your binaries but I won't promise anything.

Also DXVK 2.2 didn't work for me either.

Hi!

I believe I've finally managed to crack this issue after sinking months into reverse engineering various parts of the proprietary nvidia linux driver stact. It might also explain other vulkan related hangs in general (like https://github.com/ValveSoftware/Proton/issues/6869 ).

In short, it appears to be a dumb race condition made possible by libGLX_nvidia.so calling XSync() on the wrong X connection, which lets the wait fence (used in the present extension) trigger before it's reset for reuse, effectively deadlocking the client.

I've created a small proof-of-concept fix ( https://github.com/vahook/nvglxfix/ ), although taking a slightly different synchronization approach. For me, it seems like it completely eliminated the random hangs in vulkan applications (including DXVK and proton games in general), with no performance penalty.

Can someone test this solution mentioned above? I have no idea how to properly compile and use such stuff, and I... Moved to Wayland at this point, just to get rid of this issue.

If no one is willing to, I will test it myself, even though that will be rather tedious.

@MAGGen-hub @aeadio

Can someone test this solution mentioned above? I have no idea how to properly compile and use such stuff, and I... Moved to Wayland at this point, just to get rid of this issue.

If no one is willing to, I will test it myself, even though that will be rather tedious.

@MAGGen-hub @aeadio

I will test the solution later today and will leave a feedback here.

@seacat17 I’ve tested by myself. I’ve played around 1.5 hour Kingdom Come Deliverance with the modification and haven’t encountered any freezes during this time (the game usually freezes after 5-10 minutes).

@vahook thank you, you’re a legend. Is it possible to push the changes upstream to fix the issue for everybody?

I'm glad it works! I opened a thread on the nvidia dev forums with a bit more info (https://forums.developer.nvidia.com/t/the-possible-root-cause-of-the-vk-khr-present-wait-and-vulkan-related-freezes/328932), so let's hope the engineers take notice and fix their driver. Sadly, I don't think I can do more.

I've experienced this issue sporadically in Deadlock, especially when switching windows. But in Schedule I it happens all the time.

For me the problem suddenly disappeared, and after many hours of debugging I figured out the following Xorg configuration makes it go away:

Section "Device"
	Identifier "Card1"
	Driver "amdgpu"
	BusID "PCI:4:0:0"
EndSection

On the other hand it does not happen in Wayland.

I think it's related to NVIDIA PRIME technology (I have Ryzen integrated GPU).

Indeed, the above configuration disables nvidia for Xorg. Even if I use amdgpu for the game, just having nvidia enabled for Xorg makes the game freeze.

This works:

Section "Device"
	Identifier "Card1"
	Driver "amdgpu"
	BusID "PCI:4:0:0"
EndSection

This freezes:

Section "Device"
	Identifier "Card1"
	Driver "amdgpu"
	BusID "PCI:4:0:0"
EndSection

Section "Device"
	Identifier "Card2"
	Driver "nvidia"
	BusID "PCI:1:0:0"
EndSection

However, it doesn't happen as often in KDE, whereas in Xfce and i3 it happens pretty much immediately.

@vahook

I have this issue with Oblivion Remastered.

I have a strong Nvidia card and a weak Intel.

xspam, indeed, leads to the game freezing instantly, however the fix does not seem to work

I'm glad it works! I opened a thread on the nvidia dev forums with a bit more info (https://forums.developer.nvidia.com/t/the-possible-root-cause-of-the-vk-khr-present-wait-and-vulkan-related-freezes/328932), so let's hope the engineers take notice and fix their driver. Sadly, I don't think I can do more.

Can you go lightly punch them in the face so they would get to work? The issue is still not fixed in the latest driver version.

@seacat17 Nvidia doesn't care. X developers have contacted them multiple times and they never respond.

@seacat17 Nvidia doesn't care. X developers have contacted them multiple times and they never respond.

Can we spam their forum every time the issue occurs?

Indeed, the above configuration disables nvidia for Xorg. Even if I use amdgpu for the game, just having nvidia enabled for Xorg makes the game freeze.

This works:

Section "Device"
	Identifier "Card1"
	Driver "amdgpu"
	BusID "PCI:4:0:0"
EndSection

This freezes:

Section "Device"
	Identifier "Card1"
	Driver "amdgpu"
	BusID "PCI:4:0:0"
EndSection

Section "Device"
	Identifier "Card2"
	Driver "nvidia"
	BusID "PCI:1:0:0"
EndSection

However, it doesn't happen as often in KDE, whereas in Xfce and i3 it happens pretty much immediately.

I finally, FINALLY got my hands on this solution. And it works!

So sad that big NV cannot get their crap together...

Indeed, the above configuration disables nvidia for Xorg. Even if I use amdgpu for the game, just having nvidia enabled for Xorg makes the game freeze.

This works:

Section "Device"
	Identifier "Card1"
	Driver "amdgpu"
	BusID "PCI:4:0:0"
EndSection

This freezes:

Section "Device"
	Identifier "Card1"
	Driver "amdgpu"
	BusID "PCI:4:0:0"
EndSection

Section "Device"
	Identifier "Card2"
	Driver "nvidia"
	BusID "PCI:1:0:0"
EndSection

However, it doesn't happen as often in KDE, whereas in Xfce and i3 it happens pretty much immediately.

Hi @felipec , i have the same config: nvidia 3060 + Vega 3 iGPU, but i dont have any xorg.conf or xorg.conf.d in /etc/X11/ on Debian 13, and as i understand its normal situation. Did you create these files manually?

BTW: i dont have issues with freezes and crashes in games

@kar1kam1 wrote:

as i understand its normal situation. Did you create these files manually?

Yes, that is the normal situation, and yes I created this file manually.

If I don't create that file, then Xorg enables both drivers, and I experience the freeze.

i have the same config: nvidia 3060 + Vega 3 iGPU

Which driver are you using for rendering? In my setup it's the AMD driver the one being used as sink.

What does this command show?

xrandr --listproviders

Also, my screen is the laptop panel, I'm not using an external monitor right now.

Which driver are you using for rendering?

Mesa for Vega iGPU (not Vega 3, Vega 7, i misspelled) and 550 driver from official Debian repo for nVidia
I'm on desktop: Ryzen 5 5600G + nVidia 3060 12Gb, i set in BIOS IGP priority (or something similar, which means iGPU) and connect my monitor to motherboard. To run games on nVidia in steam i add command like "__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia _VK_LAYER_NV_optimus=NVIDIA_only %command%", in Lutris there is option that works fine.

What does this command show?

xrandr --listproviders Providers: number : 2 Provider 0: id: 0x55 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 1 name:AMD Radeon Graphics @ pci:0000:0a:00.0 Provider 1: id: 0x209 cap: 0x2, Sink Output crtcs: 4 outputs: 7 associated providers: 1 name:NVIDIA-G0

@kar1kam1 wrote:

Mesa for Vega iGPU (not Vega 3, Vega 7, i misspelled) and 550 driver from official Debian repo for nVidia

That's not what I mean.

Mesa is used for 3D rendering, not by Xorg, and it depends on the monitor.

For example in my machine Xorg log shows this:

AMDGPU(0): Output eDP connected

Which means Xorg is using the amdgpu driver on my machine for this screen.

Providers: number : 2

That's the same here: AMD Radeon Graphics and NVIDIA-G0.

However, notice that that different connectors use different drivers. For example I cannot use the amdgpu driver if I connect a monitor on my DisplayPort connector.

If you are using a desktop, I presume you are connecting your monitor to the NVIDIA graphics card connector, in which case the NVIDIA(G0) driver will be used. You might be able to reproduce my setup by plugging your monitor on a different connector (so the amdgpu driver is used).

To run games on nVidia in steam i add command like "__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia _VK_LAYER_NV_optimus=NVIDIA_only %command%"

That is orthogonal to this issue. That specifies which driver to use for 3D rendering, it doesn't change which driver Xorg uses to render the result.

In my case the freeze happens whether I set __NV_PRIME_RENDER_OFFLOAD=1 or not. Because this is an issue with the NVIDIA Xorg driver, not the 3D driver.

To be specific, this is the driver I'm talking about:

/usr/lib/xorg/modules/drivers/nvidia_drv.so

For example I cannot use the amdgpu driver if I connect a monitor on my DisplayPort connector.

As far as I understand, these are some hardware “nuances” of the implementation of how the laptop outputs a video signal - the internal display of the laptop “connects” to the iGPU, and the external monitor connected to the HDMI/DP port uses the dGPU.

If you are using a desktop, I presume you are connecting your monitor to the NVIDIA graphics card connector, in which case the NVIDIA(G0) driver will be used. You might be able to reproduce my setup by plugging your monitor on a different connector (so the amdgpu driver is used).

As i said: " i set in BIOS IGP priority (or something similar, which means iGPU) and connect my monitor to motherboard", which means that Xorg uses amdgpu(Vega 7 iGPU) driver i suppose.

In my case the freeze happens whether I set __NV_PRIME_RENDER_OFFLOAD=1 or not. Because this is an issue with the NVIDIA Xorg driver, not the 3D driver.

Hmmm, now i see, but it is very strange why i dont have the same issues :\

As i said: " i set in BIOS IGP priority (or something similar, which means iGPU)

That priority only matters while booting. Once you are running linux the display can change.

Linux and Xorg can choose to respect the BIOS priority, but they might ignore it too.

The only way to know is looking at the Xorg log.

and connect my monitor to motherboard"

Well, not directly to the motherboard. Presumably there's a connector that connects to the motherboard.

But that's weird, because most (all?) desktop graphic cards have their own connector that you are supposed to use.

But that's weird, because most (all?) desktop graphic cards have their own connector that you are supposed to use.

Yes, I know )) I chose this particular configuration because this way I use the integrated AMD graphics card for display rendering, which is better supported in Linux. If I connect the monitor directly to the discrete NVIDIA graphics card, I will encounter some issues such as screen tearing and no hardware video acceleration in Chrome.

@kar1kam1 that's a good idea, I didn't think about that. I don't encounter any of the issues many people claim about Nvidia, but I'm not using it for Xorg rendering.

It would still be useful to make sure which driver you are using by looking at the Xorg log.

If Xorg isn't using the nvidia driver, then you should be experiencing the same problem. Maybe it wasn't present on 550. I can't install it on my modern Arch Linux system, I'm using 575.64.05.

It would still be useful to make sure which driver you are using by looking at the Xorg log.

seems i'm using both drivers
I'm wondering why I have no problems, but your games freeze.

grep -i "driver" /var/log/Xorg.0.log
[ 11.678] X.Org Video Driver: 25.2
[ 11.678] X.Org XInput driver : 24.4
[ 11.730] loading driver: amdgpu
[ 11.730] loading driver: nvidia
[ 12.227] (==) Matched amdgpu as autoconfigured driver 0
[ 12.227] (==) Matched ati as autoconfigured driver 1
[ 12.227] (==) Matched nvidia as autoconfigured driver 2
[ 12.227] (==) Matched nouveau as autoconfigured driver 3
[ 12.227] (==) Matched nv as autoconfigured driver 4
[ 12.227] (==) Matched modesetting as autoconfigured driver 5
[ 12.227] (==) Matched fbdev as autoconfigured driver 6
[ 12.227] (==) Matched vesa as autoconfigured driver 7
[ 12.227] (==) Assigned the driver to the xf86ConfigLayout
[ 12.227] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so
[ 12.229] Module class: X.Org Video Driver
[ 12.229] ABI class: X.Org Video Driver, version 25.2
[ 12.229] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[ 12.229] Module class: X.Org Video Driver
[ 12.229] ABI class: X.Org Video Driver, version 25.2
[ 12.250] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[ 12.273] Module class: X.Org Video Driver
[ 12.275] (II) Loading /usr/lib/xorg/modules/drivers/nouveau_drv.so
[ 12.276] Module class: X.Org Video Driver
[ 12.276] ABI class: X.Org Video Driver, version 25.2
[ 12.277] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 12.277] Module class: X.Org Video Driver
[ 12.277] ABI class: X.Org Video Driver, version 25.2
[ 12.277] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 12.278] Module class: X.Org Video Driver
[ 12.278] ABI class: X.Org Video Driver, version 25.2
[ 12.278] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[ 12.278] Module class: X.Org Video Driver
[ 12.278] ABI class: X.Org Video Driver, version 25.2
[ 12.278] (II) AMDGPU: Driver for AMD Radeon:
All GPUs supported by the amdgpu kernel driver
[ 12.278] (II) NVIDIA dlloader X Driver 550.163.01 Tue Apr 8 12:13:21 UTC 2025
[ 12.278] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs
[ 12.279] (II) NOUVEAU driver Date: Thu Nov 7 13:15:35 2024 -0500
[ 12.279] (II) NOUVEAU driver for NVIDIA chipset families :
[ 12.279] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 12.279] (II) FBDEV: driver for framebuffer: fbdev
[ 12.279] (II) VESA: driver for VESA chipsets: vesa
[ 12.289] ABI class: X.Org Video Driver, version 25.2
[ 12.536] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi
[ 12.536] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
[ 12.567] (WW) AMDGPU(0): Option "HotplugDriver" is not used
[ 12.570] (II) NVIDIA(G0): ACPI event daemon is available, the NVIDIA X driver will
[ 12.593] (II) NVIDIA(G0): [DRI2] VDPAU driver: nvidia
[ 12.654] Module class: X.Org XInput Driver
[ 12.654] ABI class: X.Org XInput driver, version 24.4
[ 12.654] (II) Using input driver 'libinput' for 'Power Button'
[ 12.686] (II) Using input driver 'libinput' for 'Video Bus'
[ 12.726] (II) Using input driver 'libinput' for 'Power Button'
[ 12.742] (II) No input driver specified, ignoring this device.
[ 12.742] (II) No input driver specified, ignoring this device.
[ 12.742] (II) No input driver specified, ignoring this device.
[ 12.743] (II) No input driver specified, ignoring this device.
[ 12.743] (II) No input driver specified, ignoring this device.
[ 12.744] (II) Using input driver 'libinput' for 'Logitech Wireless Keyboard PID:4023'
[ 12.763] (II) Using input driver 'libinput' for 'Logitech Wireless Mouse'
[ 12.791] (II) No input driver specified, ignoring this device.
[ 12.791] (II) No input driver specified, ignoring this device.
[ 12.791] (II) No input driver specified, ignoring this device.
[ 12.792] (II) No input driver specified, ignoring this device.
[ 12.792] (II) No input driver specified, ignoring this device.
[ 12.792] (II) No input driver specified, ignoring this device.
[ 12.792] (II) Using input driver 'libinput' for 'Eee PC WMI hotkeys'
[ 12.829] (II) No input driver specified, ignoring this device.
[ 12.852] (II) Using input driver 'libinput' for 'Logitech Wireless Keyboard PID:4023'
[ 12.852] (II) Using input driver 'libinput' for 'Logitech Wireless Mouse'

seems i'm using both drivers

You didn't show the part where your screen is connected. xrandr should show the name of your connector, in my case it's "eDP", the log shows:

AMDGPU(0): Output eDP connected

@felipec as i already said, the monitor is connected to AMD iGPU

grep -E "Output" /var/log/Xorg.0.log
[    11.793] (II) Applying OutputClass "AMDgpu" to /dev/dri/card0
[    11.793] (II) Applying OutputClass "nvidia" to /dev/dri/card1
[    12.351] (II) Applying OutputClass "AMDgpu" options to /dev/dri/card0
[    12.541] (II) AMDGPU(0): Output HDMI-A-0 has no monitor section
[    12.541] (II) AMDGPU(0): Output HDMI-A-1 has no monitor section
[    12.541] (II) AMDGPU(0): Output DisplayPort-0 has no monitor section
[    12.547] (II) AMDGPU(0): Output HDMI-A-0 connected
[    12.547] (II) AMDGPU(0): Output HDMI-A-1 disconnected
[    12.547] (II) AMDGPU(0): Output DisplayPort-0 disconnected
[    12.547] (II) AMDGPU(0): Output HDMI-A-0 using initial mode 2560x1440 +0+0

@kar1kam1 yeah I just wanted to verify.

I don't see why you are not experiencing the issue then.

What DE are you using? Have you tried on Xfce? Also, is there any chance you can try the 575 driver? Me trying the 550 would be very challenging.

Other than that I cannot think of any other possible difference.

What DE are you using?

KDE 6.3.6

Have you tried on Xfce?

Nope, only KDE

Also, is there any chance you can try the 575 driver? Me trying the 550 would be very challenging.

The latest driver in Debian repositories is 550(for Debian 13), 575 can only be installed from NVIDIA CUDA repositories or via the run file from NVIDIA's website, which would be waaaay challenging for a Linux newbie like me. I wouldn't say it's impossible, but I'm pretty sure I'll break something. Maybe I'll try it when I figure out the backups.

KDE 6.3.6

As I said, for some reason it doesn't happen very easily on KDE.

would be waaaay challenging for a Linux newbie like me.

OK. But you could try running Xfce4 or i3. The issue happens very easily there.