I managed to track down the cause without an apitrace.

The issue was from the VK_EXT_descriptor_buffer support in 2.7.1, which appears to not work for Intel Arc Drivers, or for this specific workload.

I compiled a local build, disabling dxvk.enableDescriptorBuffer, and disabling d3d9.hideIntelGpu and tweaked d3d9.cachedWriteOnlyBuffers to true, and this completely resolves the VK_ERROR_DEVICE_LOST crash. The game is stable.

I have opened a PR with the fix here.

I've been playing various D3D9 things on my Lunar Lake powered laptop recently and haven't noticed any instability. That being said, that's on the Intel Mesa driver stack (ANV), not the Windows drivers, so can't comment on those.

As for not hiding Intel GPUs, we could technically do that for this game, but I doubt it has any specific path for Intel as its GPUs back then were really limited to abysmal GMA iGPUs. Perhaps it's the game's AMD path which is broken, but as Kobin said, we'd need an apitrace to look into it.

Okay, I've done further testing, and created an apitrace: google drive download here

Using JUST the trace, and swapping in and out d3d9.dll's, i have found this:

• DXVK 2.6.1 d3d9.dll: Stable
• DXVK 2.7.1 d3d9.dll: Hangs, doesn't finish trace, gets stuck on cutscene image.
• DXVK 2.7.1 + dxvk.enableDescriptorBuffer = False: Stable

This confirms there is some functional issue in the descriptor buffer for Battlemage on Windows. The AMD spoofing/path is NOT the cause of the hang, like I thought initially.

I'm inclined to remove the d3d9.hideIntelGpu = False from the PR, and just have d3d9.cachedWriteOnlyBuffers = True and dxvk.enableDescriptorBuffer = False, but also I understand this "could" be a bigger issue than just this game

I'm inclined to remove the d3d9.hideIntelGpu = False from the PR

Please do then. AMD has been picked as a spoof for Intel not because of any vendor preference, but because in terms of exposed hardware/driver level capabilities (and D3D9 hacks) on age accurate hardware, they always were rather similar. Unless a game is known to have problems on AMD, there's no reason to mess with the default spoof logic.

@HunterCZ122 was also gracious enough to inform me you lose FSAA support in this game if you report an Intel vendorid. The problem is fairly common in D3D9 games, since Intel didn't have any reasonably capable hardware back then (to put it midly), so most games forced a "potato mode" of sorts on Intel GPUs.

Here's the apitrace of the vanilla game (no mods, fresh install): Google Drive Link

Unfortunately has the same fate as the modded one, so mods being the issue here is ruled out

Tried NFS Carbon 10 minutes ago, worked completely fine, no tweak needed. Very weird considering they use the same engine.

I also want to try older d3d9, like NFS UG1 and UG2, and maybe newer like ProStreet. I'll let you know

https://github.com/user-attachments/assets/dd0750c5-7b6b-47a1-8cc0-b1b090e1f25d

Here is what it looks like

I have new updates! All of these are fresh installs, no mods

• NFS ProStreet - Runs fine on 2.7.1 d3d9.dll
• NFS Underground 2 - HANGS, just like NFSMW
• NFS UNderground 1 - Runs fine on 2.7.1 d3d9.dll

Should I make an apitrace for NFSU2 too?

I also have an Arc B580, and had to set enableDescriptorBuffer to False on Windows 11 for Elite: Dangerous (D3D11 though) to fix crashing on main menu with an DxvkSubmissionQueue: Command submission failed: VK_ERROR_DEVICE_LOST error, so thanks to this issue for the tip.

Sorry to hijack, maybe it's related, should I open a separate issue on this too with an apitrace? Or if you think it's a bug with Intel Vulkan drivers, no worries - just thought I'd share this info regardless.

Sorry to hijack, maybe it's related, should I open a separate issue on this too with an apitrace? Or if you think it's a bug with Intel Vulkan drivers, no worries - just thought I'd share this info regardless.

I think it's definitely related, this proves it goes beyond d3d9. I might open up an issue on the Intel GPU Community Issue Tracker and see what they might have to say as well. Until someone looks deep into this I don't think we will know for sure if its an issue on dxvk's side or intel vulkan windows drivers' side.

I was having a similar crash with Elite Dangerous (Dx11) to use Vulkan instead for better performance.

Getting a crash during menu rendering with a VK_ERROR_DEVICE_LOST error in d3d11.log and warn: DXGI: MakeWindowAssociation: Ignoring flags.

Suspected it was the same issue as this, adjusted enableDescriptorBuffer to False in conf and it fixed the issue entirely. Intel problem with Vulkan renderer, same issue that Star Citizen is currently having with native vulkan rendering?

Software information

Elite Dangerous: Odyssey 4.3.0.1

System information

• GPU: Maxsun Milestone Intel Arc B580 12G
• Driver: 32.0.101.8331
• OS: Windows 11 Pro 25H2
• DXVK version: 2.7.1

same issue that Star Citizen is currently having with native vulkan rendering

So this suggests the fault lies with the Intel Driver, not DXVK.

I have Star Citizen myself, so I might install and try it. How do you reproduce the crash, does it just happen right away? I searched on the Intel GPU Community Issue Tracker for Star Citizen and there is no open issue regarding it. So, if I can confirm that, I might open an issue specifically for Star Citizen, and also link back to this issue as possibly related.

same issue that Star Citizen is currently having with native vulkan rendering

So this suggests the fault lies with the Intel Driver, not DXVK.

I have Star Citizen myself, so I might install and try it. How do you reproduce the crash, does it just happen right away? I searched on the Intel GPU Community Issue Tracker for Star Citizen and there is no open issue regarding it. So, if I can confirm that, I might open an issue specifically for Star Citizen, and also link back to this issue as possibly related.

https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/1301 this is the one you're looking for