DXVK Now Has An On-Disk Shader Cache

[oiaohm]

Thanks for the link. I get that it increases performance (or the consistency of the performance) but what I don't get is why every application would need to implement it's own shader cache when our drivers already have a shader cache. Shouldn't that be enough? Why the duplicate work/effort?

You need a cache of some form at the compiler stages. I don't mean to be mean but applications are stupid at times. With wined3d converting DXBC to GLSL and DXVK DXBC->SPIR-V other doing DXBC conversion to other backend this feature is a driver feature. Ideal would there would be a offload in DXBC straight into the driver stack and allow it to be converted and exploit the shared cache.

Now back to applications are stupid. You will see application send to API the same Shader source thousands of times. Instead of build once use many. Shaders go though quite a heavy compiler process.

DXBC enters wined3d. Wined3d has to process this to GLSL this is not light. Then GLSL is process to a internal IR for GLSL optimisations(that hopefully in future will be replaced with SPIR-V) then is process again to NIR/something the video card driver processes. Then this is processed again to be something the graphics card accepts and then this can be processed again on the video card it self.

Vulkan drivers get to be 1 step shorter. Now working out if something is in shader cache normal end up having to hash the input this is cpu overhead and latency..

Like it or not most of the reason for graphics drivers requiring a cache is that applications are not being smart and reusing the shaders they have already built.

https://www.khronos.org/opengl/wiki/Shader_Compilation

Yes using opengl its possible to do a binary upload of a shader with glProgramBinary. I don't know if you can do this with Vulkan all the design documents suggest not. Yes a binary upload with opengl skips straight over to the binary format for the video card this is magically skip over the LLVM compiler and hashing.

Welcome to nightmare the reality is wined3d using opengl does the functionality to-do a disc cache well with opengl but it not implemented. Vulkan that DXBC and other are using be missing it because that functionality may not be in vulkan yet. If it need functionality they may be needing to talk to khronos to get a Vulkan extension.

The reality here is the wined3d developers might be right this is why if someone had the skilled and could implement out wined3d to use the new opengl functions it might be the fastest solution. Yes vulkan is newer but it does not provide the features to allow coder to 100 percent replace the functionality in opengl at this stage and its why attempting to implement opengl program on top of Vulkan can be hard to impossible at times.

[aaahaaap]

https://dev.wine-staging.com/patches/submission/247/

Its one of the differences between wine staging and mainline that does cause a performance difference. Notice the more interesting one if attempt to guess arguments to allow early building of shaders this does help with stutter.

Wined3d does not use a on disk cache. But Wined3d is using a in memory cache and it is attempting to build as many shaders as it can as early as possible to reduce stutter.

If disk cache will help is a question to be answered. Because the IO from disk may out weight the advantage. In memory caching 100 percent does provide advantages and from what is staging this can be tweaked.

Wined3d might be slow due to not using the best opengl functions out there but its doing some very useful stunts. Some of the things hiding in staging need to go though peer review and be merged. Lot of times the rewrites to merge produce a way better patch.

Thanks for the link. I get that it increases performance (or the consistency of the performance) but what I don't get is why every application would need to implement it's own shader cache when our drivers already have a shader cache. Shouldn't that be enough? Why the duplicate work/effort?

[oiaohm]

I was wondering about this. Why does an application, in this case wine, need to implement it's own shader cache when the drivers already implement one?

https://dev.wine-staging.com/patches/submission/247/

Its one of the differences between wine staging and mainline that does cause a performance difference. Notice the more interesting one if attempt to guess arguments to allow early building of shaders this does help with stutter.

Wined3d does not use a on disk cache. But Wined3d is using a in memory cache and it is attempting to build as many shaders as it can as early as possible to reduce stutter.

If disk cache will help is a question to be answered. Because the IO from disk may out weight the advantage. In memory caching 100 percent does provide advantages and from what is staging this can be tweaked.

Wined3d might be slow due to not using the best opengl functions out there but its doing some very useful stunts. Some of the things hiding in staging need to go though peer review and be merged. Lot of times the rewrites to merge produce a way better patch.

[aaahaaap]

Anyway, this really only helps in case your driver doesn't store its own on-disk pipeline cache already, like RADV does, but it's a good thing nonetheless.

I was wondering about this. Why does an application, in this case wine, need to implement it's own shader cache when the drivers already implement one?

[VikingGe]

RADV doesn't cache SPIR-V shaders (why would it, the application sends them to the driver anyway), it caches compiled Vulkan pipelines (which is exactly what DXVK does).

[shmerl]

Another issue is that the SPIR-V shaders are huge - my Vulkan pipeline cache for Witcher 3 has 3.5MB, the SPIR-V shaders for that game can easily exceed 100MB. Caching that would be unreasonable, and compressing it wouldn't really offer any benefits over doing the translation on the fly.

But radv caches it somewhere? I only found $HOME/.cache/radv_builtin_shaders which isn't that big.

[VikingGe]

shmerl only if the game starts compiling shaders on the fly and actively waits for it to finish. Most games don't do that.

Another issue is that the SPIR-V shaders are huge - my Vulkan pipeline cache for Witcher 3 has 3.5MB, the SPIR-V shaders for that game can easily exceed 100MB. Caching that would be unreasonable, and compressing it wouldn't really offer any benefits over doing the translation on the fly.

[shmerl]

It's fast, but wouldn't it depend on their number? If you are swamped with a huge amount, it will cause a stutter.

[VikingGe]

TemplarGR Here's the thing: It doesn't store the translated DXBC shaders (not HLSL, that's just the source language). Won't help reduce stutter in most games because in D3D11, shaders are typically compiled asynchronously and the DXBC->SPIR-V translation is quite fast already.

[TemplarGR]

Leopard I was communicating with the one who made the patch on said Discord, tested it, did some work on it myself and then merged it. Slight difference, but only slight

Anyway, this really only helps in case your driver doesn't store its own on-disk pipeline cache already, like RADV does, but it's a good thing nonetheless.

Doesn't it help with storing the translated shaders? RADV only stores vulkan shaders, what about HLSL to Vulkan stuff? I think it helps...