Static samplers are somewhat seldomly used in game engines and games because it's common to have a configurable "MaxAnisotropy" parameter tied to a user preference, and recreating all pipelines is seen as expensive, compared to recreating all samplers instead.

Personally, I don't see much value in static samplers. It's not a major performance consideration or win, and I think it complicates a topic (samplers) which I don't think benefits from more functionality. Especially considering I expect to see bindless samplers for when bindless comes in in the future. If static samplers were supported natively by SPIR-V and HLSL, I would be more accepting of the proposal.

IMHO there can be some nice ergonomics wins when using static samplers and automatic layouts, though I agree it complicates the topic of samplers a bit.

I agree, it's more of a ergonomic feature. It allows you to just define the sampler in WGSL and let WebGPU handle the rest. This simplifies texture sampling and offers some flexibility to the user. I'd say web projects would find this attractive since it's less code and functions the same.

We did receive some feedback from one game engine that they use immutable samplers in Vulkan for convenience as it is simpler to set up, and they don't have to bind descriptor sets. Yes, samplers which change min/max lod, anisotropy need to be bound in Vulkan descriptor sets. However, there are still many of the common samplers for bilinear/trilinear filtering which they use Vulkan immutable samplers for.

We ran some benchmarks comparing static and normal samplers.

Metal

Deferred Rendering Sample from Apple was used to benchmark for Metal. The benchmark ran on M2 Macbook air.
Fragment shader profiling timings:

• Static Samplers max duration varied between 1.67-2.3ms across multiple runs
• Normal Sampler max duration varied between 1.78-2.37ms across multiple runs
  Additionally normal samplers need +1 API call per draw.

Vulkan & D3D12

The following benchmarks were conducted by sampling a 2048x2048 texture to a 4096x4096 render target.
The code is here: https://dawn-review.googlesource.com/c/dawn/+/194102
Timings were retrieved via timestamp queries.

Android Vulkan

Normal samplers: 2.47 ms
Static samplers: 2.45 ms

This is a negligible improvement.

Desktop Vulkan & D3D12

AMD (integrated) hardware on Vulkan saw an improvement of around 0.1 ms for static samplers, but negligible improvement on D3D12. Nvidia hardware did not show any measurable difference on both backends.

Binding time benchmark

This is a minor benchmark that we did to see the CPU performance when binding a large number of bind groups with normal vs static samplers. This was done by binding 216 different bind groups with the same texture but a different sampler.

On Android Vulkan we saw that binding static samplers bind groups are more expensive.

Normal samplers: 68338 ns
Static samplers: 111491 ns

These are measured in nanoseconds and this benchmark is unrealistic in real-world applications. It’s unrealistic to assume 216 different samplers across bind groups in an application.

We also observed a difference in desktop Vulkan of static samplers being 10 000 - 20 000 ns slower. However, D3D12 was consistent and there was negligible difference (~2000 ns). This could be due to its different binding model.

Conclusion

Static samplers do not have a significant advantage over normal samplers. They can be sometimes faster on some hardware, but it is unlikely to be a bottleneck in applications. This concludes that this proposal isn't a performance feature but rather an ergonomic one.

On the specific proposal itself, it requires authors to put the sampler descriptor in both the WGSL text and the binding group layout. Ergonomically, this does not seem great to me. This is caused by the issue where the sampler descriptor is effectively embedded in the binding group layout on D3D12 and Vulkan (the root signature and descriptor set layout, respectively), while it's part of the shader pipeline on Metal.

re: Metal compilation, you say:

If the description is provided at runtime, the implementation has to modify the Metal source or Metal-IR in order to complete the sampler definition. However, we can not require implementations to modify Metal source or Metal-IR because precompiling shaders would not be possible and Metal-IR is not documented.

This is not true. Compilation to MSL code happens during createGraphicsPipeline, at which point the BGL is known. So it would absolutely be possible to put the static sampler in BGL. Apple wanted to opportunistically compile the shader to Metal in createShaderModule if the BGL was known; in this case, the GPUPipelineLayout is already passed as a hint, so this would include static samplers.

If we go down the route of including static samplers, I would encourage us to put them exclusively inside the BGL, and remove the WGSL syntax for specifying samplers. It would be nice to specify static samplers entirely in WGSL, but I can't see any way to make that work for Vulkan or D3D12 unless we give each PSO its own root signature / descriptor set layout, which doesn't feel worth it for such a small ergonomics feature.

This is not true. Compilation to MSL code happens during createGraphicsPipeline, at which point the BGL is known. So it would absolutely be possible to put the static sampler in BGL. Apple wanted to opportunistically compile the shader to Metal in createShaderModule if the BGL was known; in this case, the GPUPipelineLayout is already passed as a hint, so this would include static samplers.

Fair point, I forgot that the hints were needed to compile metal shaders early.

If we go down the route of including static samplers, I would encourage us to put them exclusively inside the BGL, and remove the WGSL syntax for specifying samplers. It would be nice to specify static samplers entirely in WGSL, but I can't see any way to make that work for Vulkan or D3D12 unless we give each PSO its own root signature / descriptor set layout, which doesn't feel worth it for such a small ergonomics feature.

The big benefit of being able to define them in the shader is that "auto" layouts can be generated from the shader so you only have to describe the sampler once. But given the point above, that Metal actually does not require us to have the sampler definition at createShaderModule, we wouldn't have to describe it twice anyway so it's not so bad. Partial-auto layouts would still be very helpful for the opposite reason as before, though - then you could define the static sampler explicitly and have the rest of the bindings be auto.

(I would love if we also had WGSL syntax to be able to use "auto" with the few things that can currently only be done with explicit layouts, and even better if there were a way to write an entire explicit layout in WGSL such that it's not sensitive to static usage so we don't have to set [[exclusivePipeline]].)

Oh, yeah! I suppose you could put them in the shader for auto layout exclusive stuff. Not sure if I think that's worth adding as a feature (it has some drawbacks, like if someone is using static samplers with auto layouts and wants to port away to explicit layouts later, they're in a world of hurt), but it's a possibility.

(I would love if we also had WGSL syntax to be able to use "auto" with the few things that can currently only be done with explicit layouts, and even better if there were a way to write an entire explicit layout in WGSL such that it's not sensitive to static usage so we don't have to set [[exclusivePipeline]].)

Admittedly I stopped using auto layouts early on, but I haven't really enjoyed the ergonomics of them. I have some ideas for how to improve things, but it's probably worth opening a bikeshed "V2" issue for feedback wrt. making the experience of WGSL and auto layouts better.