It seems like using wgpu_hal's existing pipeline cache feature would actually fix this for Vulkan. Even if you just create an empty pipeline cache, Vulkan says:

Pipeline cache objects allow the result of pipeline construction to be reused between pipelines and between runs of an application. Reuse between pipelines is achieved by passing the same pipeline cache object when creating multiple related pipelines. Reuse across runs of an application is achieved by retrieving pipeline cache contents in one run of an application, saving the contents, and using them to preinitialize a pipeline cache on a subsequent run.

The dx12 backend supplies only a dummy implementation. I don't know if Direct3D has anything that behaves the way Vulkan's pipeline cache objects do. cc @cwfitzgerald @magcius

There is ID3D12PipelineLibrary but what I heard this was focusing on serializing between runs not deduplicating within a run. D3D12 does have implicit pipeline caches, though our biggest cost on d3d12 is compiling HLSL -> DXIL/DXBC which is a user space operation, so we'd need to cache those.

I gotta ask, what is the use case for pipeline caching? I create mine once (or recreate on shader reload). Meaning, what is this caching used for if one shouldn't keep recreating pipelines each frame anyway?

Vulkan says: The big advantage of a pipeline cache is that the pipeline state can be saved to a file to be used between runs of an application

Is this something different? (Please explainer assume I know nothing)

One of the unity demos (https://vfx-demo.cds.unity3d.com) also stutters occasionally due to DxcCompiler::Compile being too slow (profile: https://share.firefox.dev/4kx1wq2). Looking at its API calls (trace.zip):

• 13 calls to CreateComputePipeline
• 163 calls to CreateRenderPipeline
• 39 calls to CreateShaderModule
  • entry points in those modules:
    • 13 @compute
    • 12 @fragment
    • 14 @vertex

though our biggest cost on d3d12 is compiling HLSL -> DXIL/DXBC which is a user space operation, so we'd need to cache those.

I think some cache keyed off the shader module (and codegen-relevant state) would prevent a lot of duplicate work here.

I also think we can try caching just the bytecode (to avoid calling into FXC/DXC), that will probably get us far enough. Caching pipelines is more involved since we'd also need to cache everything else that makes up a pipeline.

Regarding the Marching Cubes demo, this is what it's calling every frame: https://github.com/tcoppex/webgpu-marchingcubes/blob/e464ccf192dcd9ded794dae5593a0e4cbedf487a/js/utils.js#L296

P1 for Firefox because it blocks Marching Cubes.