In order to construct the implicit GPUBindGroupLayout, the implementation needs to choose the GPUTextureSampleType for texture_2d<f32> bindings. This type may either be "float" or "unfilterable-float".

Currently the spec says, "Set textureLayout.sampleType to resource’s component type." with a TODO "Detail how the sampleType is chosen from the binding."

At least a few options:

1. Always use "float"
2. Always use "unfilterable-float"
3. Determine the type based on static analysis of the shader

I think implementing some sort of analysis in (3) would be the least bad solution, though still prone to some fragility.
Here is one possible analysis:

• The sampleType for f32 textures defaults to "unfilterable-float"
• If the texture binding is statically used with one of the WGSL textureSample* calls in any of the GPUProgrammableStages, the sampleType is promoted to "float"

The reasoning behind this analysis is that the "unfilterable-float" GPUTextureSampleType is compatible with all floating-point textures. Floating-point textures are either strictly "unfilterable-float" or include both "unfilterable-float" and "float" as compatible sample types.

However, if the texture is statically used with a textureSample* call in the WGSL shader, we promote it to "float". This is because "float" texture bindings are compatible with both filtering and non-filtering samplers.

This is one example where the analysis fails to do what a developer might intend:
It would be otherwise valid for a shader to perform textureSample(tex, samp, coord) using a strictly unfilterable-float texture ("r32float", "rg32float", and "rgba32float"), and with a non-filtering sampler. However, in this situation, the analysis will unconditionally choose "float" as the sampleType of the texture binding (the type of the sampler is unknown during pipeline compilation).