Sure, I could do that.

But I don't fully understand yet why we would need / want that.
Where do you see the difference between this GL extension and others that we are already using (like GL_EXT_texture_cube_map_array) that would warrant a feature flag?

We don't have any alternatives to using the extension.
The logic in FeaturesManager makes sure that we only require it if absolutely necessary, just like with any other extensions we use.
So we could only throw a backend error again if a potential 'allow_gl_ext_texture_shadow_lod' feature flag was not set.

If we want users to be able to get better error messages (custom ones instead of what their driver ends up reporting for missing extensions), wouldn't that apply to all our used GL extensions, and be out of scope for this PR?

The downlevel flag would still be a good idea since there's one case we can't emulate even with EXT_texture_shadow_lod: samplerCubeArrayShadow on textureGrad.

I kept the backend error that we had before this PR for that case @magcius .

What is the behavior you would like to see instead? (with / without the downlevel flag set)

Thank you for taking a look at this.
I'm glad to see that there's interest in merging this.

You're definitely right that the criteria for using the extension / workaround weren't quite perfect yet.
I updated the code to hopefully fix this, and replaced all the problematic cases with errors, as you suggested.
I would appreciate somebody taking the time to review this again.

There's a conversation to be had here about the exact GL / GLES version requirements of the sampling functions, which currently aren't enforced properly. This is especially problematic since we currently default to GLES 3.1, which lacks some of the features we're using here. While that's potentially out of scope for this PR, I would be willing to work on that.
In the process of fixing the criteria for the extension I already ended up creating the following table by scouring through the documentations.
I'm reproducing it here hoping it may be useful:

Thanks for sharing the table!

The only discrepancy I found was that texture, texture+bias and textureGrad with cube[Shadow] are available since GLES 1.3.

There's a conversation to be had here about the exact GL / GLES version requirements of the sampling functions, which currently aren't enforced properly.

The only restrictions from our base of GLSL 1.3 & GLSL ES 3.0 seem to be:

• textureGather[Offset] available since 4.0 / 3.1
• cubeArray[Shadow] available since 4.0 / 3.2

We seem to check for availability of textureGather[Offset] and we should.
For cube arrays, we have Features::CUBE_TEXTURES_ARRAY which will request the extension. An improvement would be to omit requesting the extension if we are on 3.2 already.

glslangValidator v13.1.0 (released on 2023-10-13) added support for GL_EXT_texture_shadow_lod but CI seems to be on v11.8.0 (released on 2022-01-27).

@cwfitzgerald do you know how we could get v13.1.0 on CI?

Installing the vulkan sdk is a good way of getting an up to date copy of the glsl tooling

#5202 landed; @cmrschwarz could you rebase on top of it to see if the CI failure goes away?

We seem to check for availability of textureGather[Offset] and we should.

textureGather[Offset] before GL 4.0 / GLES 3.1 currently compiles without any errors / extensions used.

Demonstration test:

wgsl:

@group(0) @binding(0) var texture: texture_cube<f32>;
@group(0) @binding(1) var texture_sampler: sampler;

@fragment
fn main() -> @location(0) vec4<f32>  {
    return textureGather(0, texture, texture_sampler, vec3<f32>(0.0));
}

ron:

(
	glsl: (
        writer_flags: (""),
        version: Desktop(140),
		binding_map: {},
		zero_initialize_workgroup_memory: true,
	),
)

output:

#version 140 core
uniform samplerCube _group_0_binding_0_fs;

out vec4 _fs2p_location0;

void main() {
    vec4 _e4 = textureGather(_group_0_binding_0_fs, vec3(vec3(0.0)), vec3(0.0), vec3(0.0), 0);
    _fs2p_location0 = _e4;
    return;
}

An improvement would be to omit requesting the extension if we are on 3.2 already.

Things that currently require an extension for but don't have to:

• any use of cubeArray / cubeArrayShadow in GL 4.0 / GLES 3.2
• textureOffset on 2DArrayShadow in GL 4.3

The only restrictions from our base of GLSL 1.3 & GLSL ES 3.0 seem to be [...]

Maybe not too really relevant, but we currently don't seem to support GL 1.3, only GL 1.4. I assume that's intended.

We seem to check for availability of textureGather[Offset] and we should.

textureGather[Offset] before GL 4.0 / GLES 3.1 currently compiles without any errors / extensions used.

Right, I mistyped, should have been: "We don't seem to check for availability of textureGather[Offset] and we should.".

Damn, sorry for all my mistakes on this.
35dbd9d should address the issues you pointed out.
Thank you for your patience with me @teoxoy .

Regarding thetextureGather situation, would you be fine with a separate PR regarding that?

No worries :)

Thanks for addressing all the feedback!

Regarding the textureGather situation, would you be fine with a separate PR regarding that?

Yeah, that sounds the best.

Ah, I forgot about the downlevel flag request. Would you be able to add a downlevel flag for the GL_EXT_texture_shadow_lod extension? We could do that in a follow-up PR as well.

The role of downlevel flags is letting users know what functionality is available before they use it. The presence of all dowlevel flags also signifies that the device implements the WebGPU API fully.

Oh! When I initially submitted this, I wasn't too familiar with the library, so I was thinking Rust feature flag, not wgpu::DownlevelFlag.

My initial comments regarding this probably didn't make any sense at all 😅 . Sorry for my ignorance.

Since this comment thread is getting pretty long, and as the downlevel flag sort of addresses an issue that was present before this PR, I would prefer doing a follow up PR, if thats ok for you guys.

hey, would it be possible to cut a new release? Using this PR would be super useful for a personal project of mine. If not, no worries. Hope I'm not bugging yall :)

Just landed in 0.19.2 :)

Just landed in 0.19.2 :)

You guys are awesome