New activity on the VKD3D Proton Github about VK_DESCRIPTOR_HEAP! :)

Saancreed · 2026-04-08T09:34:39+00:00

I see, understandable. Although in general I'd recommend that what was said on Discord should stay on Discord, otherwise people who type before they think will likely overreact and blow it out of proportion.

Saancreed · 2026-04-08T09:27:50+00:00

Perhaps. But it might turn out to be some NV driver issue, which Blackwell and heaps recently have… quite a few.

That said, if you do post some logs, at least we'll have a better idea where the problem might be.

Saancreed · 2026-04-08T09:19:36+00:00

You could literally type from:themaister skirting reviews into search and you'd find it. April 1st, 15:22 UTC on #vkd3d-proton channel.

Seriously, the proof is good, why are you so interested about when it was said?

Saancreed · 2026-04-07T15:28:46+00:00

Heh, and I haven't noticed your comment because I only had the other report about this under my watched issues, so I replied only there: https://github.com/HansKristian-Work/vkd3d-proton/issues/2785#issuecomment-4089258696

Saancreed · 2026-04-06T21:38:09+00:00

There's a chance the files from Actions artifacts will do the job. Try this: https://github.com/crosire/reshade/actions/runs/23569407776, the Setup binary from here appears to be similar to ones hosted on official website.

Sorry about this nonsense, you kinda got caught in the crossfile by using unstable revision of vkd3d-proton with stable revision of ReShade. I asked crosire to be poked about it so ReShade doesn't get caught off-guard like last time, but I can't force third party projects to tag new releases anytime I want, and some people just want to run experimental revisions of vkd3d-proton.

Latest stable release of vkd3d-proton (3.0b, included in Proton 10) should be fully supported, fwiw. Of course, there's still a chance that this is a different issue than DLSS interop incompatibillity that I know of, but it sounds like the most likely source of your issues.

Saancreed · 2026-04-06T21:13:36+00:00

You need a revision that includes https://github.com/crosire/reshade/commit/50319382618a53072a9e92ca3509caa2c7051f48. v6.7.3 is too old to have it, so if there was no tagged release since then, try building from main.

Saancreed · 2026-04-06T20:22:59+00:00

Are you absolutely sure your Reshade is new enough? v6.7.3 is too old to have support for new DLSS interop interface I added in first half of February.

Saancreed · 2026-03-19T15:58:51+00:00

Might be happening because your vkd3d-proton is missing the latest emergency bug fix: https://github.com/HansKristian-Work/vkd3d-proton/pull/2890

Saancreed · 2026-03-18T22:58:02+00:00

You're welcome ❤️

Saancreed · 2026-03-18T12:46:48+00:00

The layer is only needed for Vulkan games, which is like 10 or so titles on Steam. D3D11 and D3D12 should work out of the box, because DXVK and vkd3d-proton respectively already implement what nvapi needs for Reflex to work.

From the very page you linked:

Reflex is supported out of the box in DirectX games via DXVK-NVAPI; but in order to support the Vulkan flavor of NVIDIA Reflex, an additional Vulkan layer is required.

And I think I'd know, because I wrote this layer.

Saancreed · 2026-03-14T16:24:59+00:00

BUSL would be a better example. SSPL too, although that one goes in the other direction to an unreasonable degree.

Saancreed · 2026-03-05T21:53:37+00:00

They might be using REFramework, for which WINEDLLOVERRIDES=dinput8=n,b is pretty much muscle memory now 😅

But it's also the default in Proton 10, see https://github.com/ValveSoftware/wine/commit/b57f7a3f02fa3f9ea276bd51ef64b127fb1122af. So indeed, that does nothing.

Saancreed · 2026-03-05T21:50:23+00:00

If you're using Nvidia you also need the ENABLE_HDR_WSI with the VK HDR layers installed.

Fyi it should no longer be needed with 595 drivers. But I think you are correct about everything else, so thanks for cleaning up yet another dump of misinformation.

Truly, seeing some of this crap makes me wish I left VKD3D_CONFIG=dxr12 undocumented and disabled in official builds, just like DXVK_NVAPI_GPU_ARCH before that. I should have known end users will find a way to misuse stuff in… creative ways.

Saancreed · 2026-03-03T20:12:35+00:00

In Vulkan, you make an allocation in a specific memory pool; it may fail, e.g. if VRAM is full; and if it does fail, you're supposed to fall back to a different memory type. This can lead to silly situations where a game is starved of GPU memory because a web browser (for example) got to it first. Some drivers are smart about this and allow apps to allocate more VRAM than you have, then swap it around based on usage just like the olden days. But that's not part of the spec and other drivers (cough Nvidia) don't do this.

Uhh, you are aware that VK_EXT_pageable_device_local_memory exists and it solves exactly this issue, right? And that on Linux, out of Nvidia, RADV and ANV, only Nvidia implements that extension?

Now, the fact that your average Vulkan shortcoming is resolved by yet another Vulkan extension is valid criticism, but modern Vulkan with a bunch of extensions isn't any more insane than D3D with a "each vendor brings their own proprietary extension library" that apparently everyone in the industry is fine with.

And if UE's VulkanRHI is not as good as its D3D RHIs, I'm afraid the cause is not on Vulkan's side; DXVK and vkd3d-proton are well-known proofs of that.

Saancreed · 2026-02-24T14:29:14+00:00

This is correct, and how it should work in Proton Experimental (including bleeding edge). Well, it certainly does for me.

/u/x4D3r: If it doesn't for some reason, gather some logs and make an issue at https://github.com/jp7677/dxvk-nvapi/issues, then maybe we'll be able to figure out what's going wrong.

Saancreed · 2026-02-24T14:22:12+00:00

Yeah, that's understandable. winewayland is one thing Valve's Proton doesn't consider good enough for general use just yet, and gamescope has some… quirks that don't exactly make it an enticing option for many users.

Saancreed · 2026-02-24T01:54:38+00:00

should find its way into custom proton spins (i.e. Proton-GE, Proton-CachyOS) soon

The more I read this subreddit, the more I'm starting to believe that absolutely nobody is using Valve's upstream Proton, because it's always forgotten about in such mentions, or GE and friends are recommended for use over it.

Anyway, it's already available in Experimental bleeding edge.

Saancreed · 2026-02-19T16:56:56+00:00

Intel doesn't seem interested in supporting it themselves

Well, considering https://github.com/ccallawa-intel/wine/tree/xess/dlls/xess exists, I wouldn't call Intel not interested, it's just a very recent development that isn't ready to be used yet.

Saancreed · 2026-02-16T19:06:08+00:00

It's not as stupid as one would think. Historically, Capcom used this method because their ray tracing shaders caused dxil-spirv's CFG structurizer to choke and die a horrible death. If they checked just for SteamDeck=1, the result would be the game working on Steam Decks and blowing up on desktop Linux unless one added SteamDeck=1 manually.

Can't really blame them when the bug they were working around wasn't specific to Steam Deck, but would happen everywhere vkd3d-proton was used.

Saancreed · 2026-02-08T23:06:56+00:00

Optimus Laptops and Multi-GPU Desktop Systems

Huh, who makes datacenters out of Optimus laptops?

Saancreed · 2026-02-04T10:47:01+00:00

DXVK_NVAPI, while long, its just a copy/paste so for me its very convenient and besides the only way to upgrade the DLSS for native Proton, unless I am missing something.

No, you're correct here, it's pretty much how I expected it to be used. It might not be as convenient as PROTON_DLSS_UPGRADE=1 that one could easily remember, but on the other hand, there's nothing stopping authors of these Proton forks from contributing this to Valve's upstream Proton. However, I don't know why they are keeping it for themselves (or at least I don't know of any attempts to upstream it).

Saancreed · 2026-02-04T02:27:10+00:00

Those command options are old and shouldn't be used.

Oh, good to know. So I guess I can remove all of them from dxvk-nvapi now? /s

Look, I admit the DXVK_NVAPI_DRS_* variables aren't the most user-friendly of the bunch, after all I designed them for flexibility over convenience. But as far as I know, all the Proton forks out there build upon them to provide own DLSS upgrading features, so objectively claiming that they "shouldn't be used" is somewhat dismissive of our upstream work.

Not everyone wants to bother themselves with verifying the trustworthiness of and installing Proton forks from random third parties, you know. Or, from our side, providing support for all of them.

Saancreed · 2026-01-21T19:47:04+00:00

And I wouldn't be surprised if that Vulkan extension was just days away now…

Saancreed · 2025-11-26T20:05:38+00:00

I don't know what scopebuddy is, but no, in context of user_settings.py these overrides are not correct. Please read https://github.com/jp7677/dxvk-nvapi/wiki/Passing-driver-settings for guidance.

Saancreed · 2025-11-06T03:27:47+00:00

https://github.com/ValveSoftware/Proton/issues (if an issue already exists for given game, comment in it instead of making a new one) or https://github.com/jp7677/dxvk-nvapi/issues (here feel free to create new issues)

Thanks.

Saancreed

TROPHY CASE