Current WebGL developers constitute a large part of our target audience. While we've been putting emphasis on the value of supporting existing HLSL shaders (by WHLSL), we haven't nearly considered (except for the last sentence of #44) the value of supporting existing GLSL. I believe we could produce a GLSL extension (by following GL_KHR_vulkan_glsl steps) that modernizes GLSL to the point of being usable with WebGPU:

• require binding layouts, e.g. layout(group = 1, binding = 2) uniform texture2DArray t_Shadow;
• separate bindings for samplers and textures, joined only at the place where sampling happens, e.g. sampler2DArrayShadow(t_Shadow, s_Shadow)
• carefully define the behavior for out-of-bounds accesses and other sources of confusion

Having the developers rewrite sampler bindings and annotate the uniforms/storage buffers with the explicit group/binding semantic is significantly easier than rewriting all the shader code into the unknown syntax. I imagine, in a lot of cases the porting could be done with just a few preprocessor branches in the header files:

#ifdef WEBGPU
layout(group = 1, binding = 2) uniform texture2DArray t_Shadow;
layout(group = 1, binding = 3) uniform samplerShadow s_ShadowImpl;
#define s_Shadow sampler2DArrayShadow(t_Shadow, s_Shadow)
#else
uniform sampler2DShadow s_Shadow;
#endif

Imagine ShaderToy as a potential customer of the API. Since they control the bindings, they can technically re-implement the backend in WebGPU without breaking any of the shaders uploaded by the users.

Now, as to how we can support (Web)GLSL. If the implementation digests WHLSL, we'll need some sort of a translation WASM library doing the work. Presumably, we'd have the user providing the extra information on what bind groups and indices the resources are, including the separation of textures and samplers. Would this be on your roadmap to implement for WHSL ecosystem?

If we digest WebSPIRV, then we can have a quick start by using the existing GLSL to SPIRV converters, like glslang. We'd just host it as a WASM module and make sure that the produced SPIRV is compatible with WebGPU, or otherwise caught by our validation.