#VK_EXT_Graphics_Pipeline_Library is broken on Windows

1 messages · Page 1 of 1 (latest)

keen saddle
#

AMD introduced in 2025 on Windows for Adrenalin drivers support for VK_EXT_Graphics_Pipeline_Library, famously used by DXVK. Forgot which version introduced it. It was still blacklisted in DXVK for some 1-2 driver versions, then it was allowed.

And now VK_EXT_Graphics_Pipeline_Library has been non functional in DXVK since at least ~25.7.1

How to test: play any DX11 game, e.g. Dying Light 1 with DXVK then play the same game with DXVK GPLAsync (with dxvk.conf configured with dxvk.enableAsync=true).

They should both be just as smooth with no stutters. However GPLAsync is smooth while regular DXVK isn't.

oak carbon
#

What about native VK apps on Windows? IIRC certain Valve games are a major user of GPL, such as Dota 2 if I'm not mistaken.

Also note the Windows AMDVLK driver currently just emulates VK_EXT_shader_object on top of graphics_pipeline_library for now, so any apps using SO would presumably show the same behavior.

#

Do note that layered APIs like DXVK/VKD3D inherently have a fair bit of odd compatibility edge cases.

keen saddle
#

I'm not aware if any Vulkan based game inherently uses GPL.

#

I can retest HL2 / Episodes / L4D2 / Portal 2 with the native Vulkan launch command and see what happens

#

Shader_Object is to my knowledge unrelated to GPL

keen saddle
oak carbon
#

the games you're referring to are Source 1

#

shader_object is quite different yet related to GPL

#

Anything shader compilation-related can get deep into async bug hell. Vulkan CTS only just added new test cases for this sort of thing recently.

#

Often gets into OS filesystem driver bugs, too.

#

We've scratched our heads over nasty FS corruption bugs.

#

In any case, I will ask the DXVK maintainers. We're in regular contact with them.

tiny valve
#

I think what you see is llpc just being slow though

#

Especially if your base comparison is against ACO

#

Did you test with amdvlk on Linux?

keen saddle
#

I have not tested Valve games, native Vulkan games or amdvlk recently or in particular.

This is just something that's affecting DXVK on Windows, regardless of game.

It used to work. It doesn't anymore 🥲

oak carbon
#

I've got quite a busy schedule at the moment, apologies. I'll try to see what the status of this is whenever I get free time.

#

Last I checked, we weren't quite certain about thread-safety with the GPL path in AMDVLK when applied universally.

tiny valve
#

That is a 3 years old extension 🐸

toxic mesa
#

Will file this for xgl to take a look into

toxic mesa
#

Hey there @keen saddle , how's it going

#

can you tell me which GPU you're using in this instance?

#

Or am I right in thinking it affects all RDNA gfx since approx 25.8.1?

keen saddle
keen saddle
keen saddle
toxic mesa
#

So 25.8.1 introduced ext support, I'm wondering if that's relevant

#

Can you give me a concise game to test with, ideally with a save file

keen saddle
#

I can absolutely say "anything DX11". I personally tested Dying Light 1. You can try Jedi: Fallen Order. Any save point should show the differences instantly

#

I can download Dying Light and upload a save

#

(later in the day)

toxic mesa
#

sounds good, will file this to the Vulkan team in the mean time

toxic mesa
#

for whatever it's worth, we've attempted to repro with DL2 whilst we procure DL1.

When running the app in DX11 mode > Vulkan via DXVK, we're not seeing any perf characteristic differences between dxvk.enableAsync=true and dxvk.enableAsync=false

#

Is this issue more apparent in specific titles?

tiny valve
#

If yes your testing is completely wrong

toxic mesa
#

is this contingent on a specific version?

tiny valve
#

Yes

toxic mesa
#

was that version mentioned above?

#

I might have missed it

tiny valve
#

Upstream dxvk only has gpl

#

This one has async and gpl

toxic mesa
#

cheers

tiny valve
#

👍

toxic mesa
#

do we need both upstream and the fork to compare or just the fork with the conf alterations

tiny valve
#

Async is enabled with DXVK_ASYNC=1 environment variable or dxvk.enableAsync=true in dxvk.conf.

#

Per this

#

One without that conf, clean shader cache

#

One with that conf, clean shader cache

#

I would test like this

toxic mesa
#

cool, that's already factored into the test plan

#

will relay to the tech

#

[SWDEV-562676]

toxic mesa
#

like can I ask our technicians to just clear caches via adrenalin

tiny valve
#

If things are not changed, your techs should check these locations manually

#

@keen saddle

#

Come here and tell if that is true or not

#

🐸

toxic mesa
#

that's fine, this destination is all handled by that aforementioned control in rsx

#

cool, as long as they don't generate in funny places, should be good

tiny valve
keen saddle
toxic mesa
#

na have fun

toxic mesa
keen saddle
#

So

#

I finally got around to downloading Dying Light 1

#

I'm running Pytorch Preview drivers, branch 25.20

#

I deleted shader cache from "c:\Users%username%\AppData\Local\AMD". Also clicked the "Reset Cache" from Adrenaline. Also deleted "DirectX" cache from Window's Disk Cleanup. Restarted PC.

#

Booted up the game, regular DX11: It's smooth as butter, no driver stutters from shader compilation. Weird

#

I then add regular DXVK 2.7.1

#

Game boots up in Vulkan, it's smooth as butter, same as DX11, no stutters

#

I am at a loss for words

#

Installing Jedi Fallen Order now

keen saddle
#

@toxic mesa @oak carbon uploaded Jedi Fallen Order Saves

#

The problem manifests here

#

DXVK GPLAsync is smooth

#

Regular DXVK stutters significantly

#

As if GPL is not present

#

Again, DXVK GPLAsync is smooth because it uses a different method to get the shaders compiled, not based on GPL. Meanwhile regular DXVK that should use GPL, stutters

toxic mesa
#

can you verify with something earlier than 25.8.1?

keen saddle
#

I need to retest to be specific

keen saddle
#

Seems GPL was added with 24.2.1 (so I had my timeline off by a bit xd) and it was then fully functional by 24.6.1.

#

Now to find out when it breaks

toxic mesa
#

@keen saddle issue has been reproduced, peeling back commits now to identify the regression point

#

thanks bubs

keen saddle
#

Amazing work ❤️

toxic mesa
#

no u

tiny valve
#

Noice

keen saddle
#

Hey there @toxic mesa , any news about this topic?

toxic mesa
#

Unfortunately not, I've sent a nudge on the topic

grand remnant
toxic mesa
#

it may be worth asking my colleague @cloud garden if they've seen anything along those lines

#

and if not, please consider making a post for it

tiny valve
#

Wishing for a world that every game ( including id Software ones ) uses d3d so AMD can handle them

grand remnant
errant mica
#

https://forums.guru3d.com/threads/dx9-dxvks-shader-compilation-seems-broken-in-rdna-4-gpus.459451
I've been following this post on guru3d please have a read through.
tldr:
VK_EXT_graphics_pipeline_library apparently worked on RDNA 2 but the user switched to RDNA 4 and it was broken specifically on DX9 games.
It had the same issues with RDNA 3, and today, they disabled LLPC ||went back to the old proprietary compiler|| on RDNA 3 and all of a sudden all the stutter was completely gone.

errant mica
#

Info from Guru3D:

In dxvk we have this code: https://github.com/doitsujin/dxvk/blob/v2.7.1/src/dxvk/dxvk_graphics.cpp#L1358-L1364

Code:
    VkPipeline pipeline = VK_NULL_HANDLE;
    VkResult vr = vk->vkCreateGraphicsPipelines(vk->device(), VK_NULL_HANDLE, 1, &info, nullptr, &pipeline);


    if (vr && vr != VK_PIPELINE_COMPILE_REQUIRED_EXT)
      Logger::err(str::format("DxvkGraphicsPipeline: Failed to create base pipeline: ", vr));


    return pipeline;```

With LLPC compiler on Windows (the default one) [**vkCreateGraphicsPipelines**](https://docs.vulkan.org/refpages/latest/refpages/source/vkCreateGraphicsPipelines.html) returns VK_PIPELINE_COMPILE_REQUIRED_EXT (success) but pipeline is VK_NULL_HANDLE instead of a valid handle as it should be in case of successful operation. It could be VK_NULL_HANDLE in case of an error but then the return code should have a proper error value.
This happens just for some shaders, not for all.

Here is a similar bug report for an Intel driver: [vkCreatePipeline returns VK_SUCCESS but doesn't return a valid pipeline handle with some shaders](https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/1222).


With "AMD proprietary shader compiler" on Windows (manually set), vkCreateGraphicsPipelines returns VK_PIPELINE_COMPILE_REQUIRED_EXT (success) with a valid pipeline handle as expected by specification. The same way it works on Linux with MESA Vulkan driver.
oak carbon
toxic mesa
keen saddle
#

@toxic mesa Ignore Dying Light 1.

That seems to work fine for whatever reason

#

Jedi Fallen Order is a way better test case

#

And a save is present above

toxic mesa
#

ah right, i think we have that one already

keen saddle
#

Hey @toxic mesa , hope you're well.

Do you have updates on this?

I know devs are rewriting massive parts of the Windows compiler, getting FSR4 ready for RDNA 3-2 / Vulkan, preparing Shader Model 6.9-6.10 support and various future FSR improvements for PC and future consoles.

However we're getting close to 1 year on this VK extension being broken 🥲

toxic mesa
#

There are some relatively recent developments on this

#

I can't make the 3D UMD meetings any more but I'll reach out to the khronos api dev mgr to see what's up