I hope it's clear that dxvk can't crash your computer - what it can do is use your hardware resources more efficiently and that could in turn expose problems that otherwise stay dormant.

To be honest your issue sounds like something I'm glad I'm not stuck with, because the root cause could be a large number of things and it's probably going to take a lot of patience and time to narrow it down. Here are some potential causes I can think of:

• PCIe bus issues - panicking GPUs can sometimes cause PCIe bus resets. Those may reset your NVMe drive as well and cause havok with other PCIe attached things, including the PCH, soundcard etc.
• C-states / powersaving madness - either your CPU or one of your PCIe devices doesn't like the C-states or powersaving options your drivers or motherboard are using. I'd recommend disabling all power saving options in the BIOS to see if that helps.
• Unstable overclock - tune it down a little if you are overcloking.
• Underspecced power supply - try running GPU + CPU benchmarks on your system to see how it behaves in a high-power draw scenario. It could just be your PSU can't supply the correct voltage at a high load and your MB panics and partially locks up.
• Kernel bug - you are blessed with hardware (or a hardware combination) that exposes a kernel bug. Look at dmesg and see if there's anything relevant before or during crashes. Oh, and pray you are not the first to have this bug, that someone has already gone through hell and there's a nice forum post somewhere about what kernel boot options to use to circumvent the problem (if you're lucky).
• Hardware fault - bit of a bummer, but it's not unheard of. Should be investigated as any potential hardware fault once all other options have been ruled out.

In any case, I doubt this is a (user space) software problem, the symptoms you've mentioned are a bit too harsh for that.

We'd probably at minimum need a dmesg or journal log to be able to get an idea.

Thanks you all for taking your time to exploring my problem.
As of Mysterious crash from Proton games I'm not the only one with this exact problem. I will try benchmarking to see if I can make it emerge in another situation as suggested.
PCIe bus issues - If this is the case, how do I make sure? Is there a good channel for me to post this information and make the problem avaliable to interested people?
C-states / powersaving madness - I had already had problems with it in the past. All options are already disabled as of now. Maybe it is related.
Unstable overclock - I do not overclock.
Kernel bug - If it is the case, how do I communicate it? Where should I post for making this problem avaliable to interested people? What should I look for on dmesg?
Hardware fault - It was my first thought, that made me change the NVME. I ran a bunch of tests on this and related possibilities and all came clean. But maybe it is mobo or pci related as you pointed out.

Dmesg or journal log - How does one attain it? What is relevant to you to see? How does I provide it to you? I already tried to take a peek on dmesg but nothing made sense to me. The messages just before the crash are no different in my eyes from the messages that were before. I think, as the disk is not accessible anymore, even if it was the case of a loggable error no log would be written anyway as the computer can't access the log file anymore.

Thank you all that commented for your time.

For dmesg, ssh in from another computer and run dmesg -w in that shell. Also works for journalctl -f. Assuming the network interface doesn't disapper immediately when the error occurs you can then save the messages on the other computer.

PCIe bus issues - If this is the case, how do I make sure? Is there a good channel for me to post this information and make the problem available to interested people?

I don't think there's a specific channel for these sort of things, but any hardware enthusiasts' forum is potentially a good place to start.

Kernel bug - If it is the case, how do I communicate it? Where should I post for making this problem available to interested people?

You should probably rule out other root causes first, before you start bothering any of the kernel folk. A lot of this is, unfortunately, scouring the internet for users with similar hardware configurations and seeing if they've had issues. In short, long and arduous detective work.

What should I look for on dmesg?

Anything that might point to a cause, as dmesg will capture kernel module responses to a whole range of situations, including hardware faults.

I think, as the disk is not accessible anymore, even if it was the case of a loggable error no log would be written anyway as the computer can't access the log file anymore.

Don't quote me on this, but I think dmesg will write to memory first, so assuming your system/CPU is still alive, it should still dish out information. That being said there are other things that can make it choke. If dmesg doesn't register anything, that's quite the pickle. Perhaps run it in a separate terminal before the crash happens, so you can still see the output once it does?

ssh in from another computer and run dmesg -w in that shell

Good advice in theory, but ssh logins won't work if it can't read auth keys or passwords from your drive. Or if you meant doing that before the crash, then sure, but I doubt it will continue logging anything.

You can show dmesg from previous boot with journalctl so no need to ssh in while it is happening.
journalctl -k -b -1
To output it in to a file you can
journalctl -k -b -1 > dmesg.txt (or a path to the file if you want it a specific location)

Edit: Though if it can't actually save this to disk after the crash happens doing it the above way might not yield anything useful

More info on the hardware theory: I checked the post that saved me (Mysterious crash from Proton games) and noticed that the OP had their inxi info, I checked and we do not share any hardware in CPU, MOBO or GPU. We both have a WD NVME, but, I had the problem before I changed NVME and it was a xraydisk. Their filesystem is ext4 and mine BTRFS.

As for now our only similarity is having the system running in a NVME. And running a Manjaro based distro.

I had this exact same issue on more demanding games. Game froze, I could switch to terminal but everything gave input/output error. After some time the game continued to work, but the computer slowly but surely failed until no keyboard or mouse input was accepted. Forza Horizon 5 that use ~98% GPU, could trigger it in a minute or two consistently, but some others could do it in 10 seconds.
After a reboot, I found no error logs with journalctl -b -1, probably no data was written.

OS: EndeavourOS x86_64
Kernel: 6.11.3
Motherboard: Asus Prime x570-P
Processor: AMD Ryzen 9 5900x
GPU: Sapphire Radeon RX Vega 56 Pulse
GPU Drivers: Mesa 24.2.4
PSU: Zalman ZM850-ARX

When I found this issue, I tried with PROTON_USE_WINED3D=1 %command% I had no freezes, but performance was bad as expected. I had no issues in Windows 11 either. It started a few weeks ago after some system upgrade, so I was almost sure that this must be a dxvk/vulkan issue (I was wrong). I tried multiple proton even proton-ge versions, to see if the dxvk version change would help. It did not.

I followed the list of @WinterSnowfall and it started to think that it is a PCIe issue, as my OS is on an NVME drive and the game is on another NVME drive. It turned out that the system on a chip was the issue, that controls the PCIe as well. The SoC voltage was a bit too high, I dropped it to 1075-1100mV and the issue was resolved. I found a guide that might help you to stabilize your SoC with AM4 motherboards.

After longer testing, it seems that it just got better and fails later with the same issue.

Edit: I could confirm from the terminal that it is still a PCIe issue, as I could cd into the hard disk drive, but I could not cd to NVME drives.

Edit2: After a few hours of testing, it seems the GPU silicon has aged over the years, and the peak frequency needed to be lowered. So my best theory now is that GPU had a too high boost clock, that was unstable at high loads. It caused a GPU panic during the games, that reset the PCIe bus, that caused the freeze and input/output error due to the game and the root is on NVME drives, that were not accessible due to the PCIe reset.