Constant Sampler in shaders

The *Metal* shader language allows the use of compile-time samplers. Thanks to them, it is possible not to rely on the state of the samplers from the client API, and the GPU can optimize texture sampling operations in advance. An extension for *SPIR-V* would allow to take advantage of the listed features when using various client graphics APIs. However, there are several ways to implement such an extension in my opinion:

1. **Option №1**: Using the `OpConstantSampler` *instruction*. This *instruction* is already provided in *SPIR-V* and is a direct analogue of compile-time samplers from the *Metal* shader language in terms of a set of parameters. The only drawback is the lack of the ability to fine-tune the sampler. For example, you cannot use different magnification and minification filters, and there is no border color setting.

2. **Option №2**: Create new *instruction(-s)* in which fine-tuning of the sampler will be available. This is feasible, since most of the sampler settings are the selection of one parameter from a set (for example, the filter is either the closest, linear, or cubic, but we only choose one thing), so some sampler parameters can be merged into a single *instruction* parameter.

3. **Option №3**: Using the *decoration instructions*. Each sampler parameter will have its own *decoration*, so it will also be possible to fine-tune the sampler parameters.

Is it possible to implement such an extension in SPIR-V? From my point of view, since OpenCL supports constant samplers, then there should be no problems for graphics APIs either, especially as part of the extension.

P.S. I am expanding this question to *Vulkan* and *GLSL*.
For *GLSL*, in my opinion, it is worth using layout qualifiers to specify the sampler parameters and instead of using the `uniform` keyword, use `const` to emphasize the constancy of the sampler.

No repository file or test is identified. Start by reviewing the SPIR-V sampler instructions and the Vulkan/GLSL extension context described here; done would require a settled, implementable extension direction rather than choosing among options.

Written by the indexing model from the issue text.