fix(gles): set sampler max anisotropy with glSamplerParameterf - #10874

Connections

No wgpu issue. The same Chromium refusal was reported outside wgpu in emscripten-core/emscripten#4514 and KhronosGroup/WebGL#2006 (both 2016).

Description

The GLES backend's create_sampler sets TEXTURE_MAX_ANISOTROPY with glSamplerParameteri. Chromium's validating command decoder, which Android WebView still uses, has no case for that pname in Sampler::SetParameteri (gpu/command_buffer/service/sampler_manager.cc), so the call fails with GL_INVALID_ENUM and the sampler keeps an anisotropy of 1. Its Sampler::SetParameterf accepts the pname, as does Texture::SetParameteri, so only the integer call on a sampler is refused.

The EXT_texture_filter_anisotropic WebGL extension says that in WebGL 2 samplerParameterf and samplerParameteri both accept TEXTURE_MAX_ANISOTROPY_EXT, so this is Chromium's bug. The WebGL conformance suite only exercises samplerParameterf on samplers, which is probably why it has survived since 2016. ANGLE accepts both forms.

This sends the value with glSamplerParameterf instead. The parameter is float-valued in the extension, and create_sampler already uses sampler_parameter_f32 for TEXTURE_MIN_LOD and TEXTURE_MAX_LOD, so the float entry point is available on every GL path wgpu-hal supports (GLES 3.0, desktop GL, and WebGL 2).

On an Android phone's WebView (Chromium 156, Adreno 730), a WebGL 2 context gave:

In a wgpu app on the same phone, every sampler created with anisotropy_clamp: 16 logged that error and read back 1. With those calls rewritten to samplerParameterf, which is what this change sends, there were no errors and every sampler read back 16.

Testing

• Added SAMPLER_ANISOTROPY, which creates samplers with anisotropy clamps 2, 4, 8, and 16 on adapters that report DownlevelFlags::ANISOTROPIC_FILTERING. No existing test reached this branch of create_sampler. On native GL, an error from the call reaches the validation canary and fails the test.
• The test cannot reproduce the Chromium refusal: native drivers, Mesa included, accept both forms, and the WebGL backend does not read getError(). Only Chromium's validating decoder refuses the integer call.
• To check that the test watches this call, I temporarily sent 0.5, which the extension makes GL_INVALID_VALUE. The test then failed on GL llvmpipe with Mesa's GL_INVALID_VALUE in glSamplerParameterf(param=0.500000) and still passed on Vulkan.
• On Linux with Mesa 26.0.8 (GL llvmpipe and Vulkan lavapipe) and the Vulkan SDK 1.4.357.0 that CI installs, cargo xtask test passed all 1,651 tests. bind_group_with_max_binding_index ran by itself on both adapters, because on GL llvmpipe it needs more memory than this machine's cap allows alongside other tests. cargo fmt --check, cargo clippy --all-targets --all-features, cargo clippy --target wasm32-unknown-unknown --tests --all-features, and cargo test -p wgpu-hal also passed.

Squash or Rebase?

Squash. The second commit only fills in the changelog entry's link to this PR.

LLM Use?

An agent (Claude Code) traced the fault on the phone, wrote the change and the test, ran the checks above, and wrote this description. I reviewed the change before opening this PR.

Checklist

• I self-reviewed and fully understand this PR.
• CHANGELOG.md entries for the user-facing effects of this change are present.
• The PR is minimal, and doesn't make sense to land as multiple PRs.
• Commits are logically scoped and individually reviewable.
• The PR description has enough context to understand the motivation and solution implemented.
• (If applicable) WebGPU implementations built with wgpu may be affected behaviorally.
• (If applicable) Validation and feature gates are in place to confine behavioral changes.
• (If applicable) Tests demonstrate the validation and altered logic works.
• This PR was automatically created by an Agent.
• The description was automatically written by an Agent.

🤖 Generated (in part) with Claude Code