Deck doesn't run AMDVLK by default (it's rdna2 fwiw, not rdna1), so it does actually benefit from the new fast path.

This is only an issue because AMD had the glorious idea to disable some MSAA-related hardware optimizations when using descriptor_buffer, but RADV doesn't do that so it's fine in that regard.

View this comment - View article - View full comments

D3D12 rendering should be fixed on current vkd3d-proton master. Rather trivial fix since the game just chooses not to render anything if that one feature flag isn't exposed for some reason.

I think to get RT on 6800 cards your going to need software RT project

RDNA2 has hardware-accelerated RT, so no.

Also I think the software fallback path is enabled by default on GFX8 onwards anyway, but I could be wrong there.

View this comment - View article - View full comments

Hm, just thinking if this D3D9 shader validation issue fix might solve this constant redownload of the shaders for the games.

This has nothing to do with that at all, Steam's shader download are orthogonal to anything Proton-related anyway, from a DXVK point of view we don't even know it exists.

The shader validation API is just a (mostly undocumented) part of D3D9 that some games rely on in one way or another, and in this case a bug caused a game to not load its assets properly.

View this comment - View article - View full comments

Hopefully then, this will mean less potential lock-ups in certain games on systems like the Steam Deck, which has in the past been a bit notorious for VRAM spiking up and then the system just locking up. Something I and many others have seen in God of War and various other AAA games.

FWIW, this was a big reason to do this kind of rework. God of War pretty much went from locking up the Deck after like 10 minutes of teleporting around to being pretty much stable in my testing, at least on default settings. Recent SteamOS updates help too.

View this comment - View article - View full comments

Currently it's only supported on Gamescope when ENABLE_GAMESCOPE_WSI=1 is set.

This actually only applies to the EXT_swapchain_maintenance1 part. present_wait is supported on (most) Mesa + Wayland setups regardless of Gamescope (but might be a bit weird on Gnome), as well as Nvidia + X11. Not sure about Nvidia + Wayland off the top of my head.

Sorry if the release notes didn't make this clear.

View this comment - View article - View full comments

Quoting: KlaasThat's my understanding as well. If dxvk dlls are used the game should behave like a Vulkan game inside wine.

Yes, it will affect vkd3d-proton and DXVK, probably quite severely.

It's frustrating but we're just going to have to live with it. It's not something we can really work around on the DXVK or vkd3d-proton side either.

View this comment - View article - View full comments

Quoting: cprnActually, can they legally make improvements and not contribute the changes back upstream?

It's fine, and I bet that 95% of the changes they had to do to make things work in a driver environment wouldn't be very useful for us anyway.

They are far better off with a hard fork anyway. Get rid of things they don't need, change things to make WHQL stuff pass (we got bug reports from them about that, which unfortunately were pretty much completely useless for us), maybe change a few things here and there to be more efficient on their Vulkan driver (Steam Deck hardware is obviously higher priority for us). In the long term, refactor the D3D9 front-end to implement the DDI natively.

All of this is allowed, and honestly, the less we have to worry about it, the better.

View this comment - View article - View full comments

Quoting: mr-victoryNow Imwait for stable Proton to pick this up...

FWIW Proton 7.0 won't get this since we don't want to bump the hw/driver requirements on a stable release. Next major update should have it though, and this has basically been in Experimental for quite some time now.

View this comment - View article - View full comments

Quoting: wit_as_a_riddleThis is only potentially useful for people relying on their intel CPU chip's integrated graphics, correct? No benefit for anyone using AMD or NVIDIA.

Correct, although RADV has seen similar patches recently which AMD users will benefit from.

At least on the RADV side of things I wouldn't expect huge improvements for real-world applications though. It's good that improvements are being made, but a 35% improvement in pure vkCmdDraw throughput is unlikely to lead to more than a 1-2% bump in something like DXVK, since there's a lot more going on than just Vulkan draw calls.

Not sure what's going on with Cyberpunk on Intel though, even on the D3D12 side of things, bottlenecks tend to be elsewhere.

View this comment - View article - View full comments

> VK_EXT_graphics_pipeline_library is included with this release, and it has huge effects on shader compilation stutters. In a good way.

No, it is not. This would be mentioned in the release notes.

It's just included in current development code in the master branch.

View this comment - View article - View full comments