Skip to content

Enable FLOAT32_BLENDABLE on Metal, in Deno, and separate from filtering#9032

Merged
andyleiserson merged 3 commits intogfx-rs:trunkfrom
andyleiserson:jj-push-ruvv
Feb 24, 2026
Merged

Enable FLOAT32_BLENDABLE on Metal, in Deno, and separate from filtering#9032
andyleiserson merged 3 commits intogfx-rs:trunkfrom
andyleiserson:jj-push-ruvv

Conversation

@andyleiserson
Copy link
Contributor

@andyleiserson andyleiserson commented Feb 10, 2026

According to the Metal feature tables, this is always available.

I've also added it to the Deno bindings, and removed a check that conflated blendability with filterability, which I believe reflected a spec error that was fixed some time ago in gpuweb/gpuweb#3920.

Testing
The CTS test webgpu:api,validation,render_pipeline,float32_blendable:* is already enabled. Since this is an optional feature, the CTS test will pass whether or not it is available. But with this change, subcases change from SKIP to PASS.

Squash or Rebase? Squash

Checklist

  • If this contains user-facing changes, add a CHANGELOG.md entry.

Copy link
Member

@jimblandy jimblandy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to update wgpu_core::Device::get_texture_format_features as well?

Copy link
Member

@jimblandy jimblandy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than the question I asked just above, this looks good to me.

@ErichDonGubler
Copy link
Member

@jimblandy: I posted #9103. 😀

@andyleiserson
Copy link
Contributor Author

Do we need to update wgpu_core::Device::get_texture_format_features as well?

Good question. I think it is okay. Initially I wanted to say that the logic in that function related to FLOAT32_FILTERABLE is unnecessary. But I'm not sure that's true -- I think it ought to be the case that HAL's texture_format_capabilities always reports precisely the hardware capabilities, and since get_texture_format_features is used when Features::TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES is active, it should be fine to pass along the exact hardware capabilities without consideration of the enabled WebGPU features. But from a few minutes with the Metal backend, I'm worried we might need that check in get_texture_format_features in order to correctly report (lack of) float32 filtering support in some cases.

But regardless of FLOAT32_FILTERABLE, the logic in the backends for FLOAT32_BLENDABLE is a bit simpler, I believe that texture_format_capabilities will correctly report support, and get_texture_format_features is intended to be reporting actual hardware support which may be in excess of what the WebGPU features promise.

@ErichDonGubler
Copy link
Member

nitpick: Let's try to keep the same order as the WebGPU spec. for features. I pushed c810992 to correct this.

@andyleiserson andyleiserson merged commit 3dfa9af into gfx-rs:trunk Feb 24, 2026
58 checks passed
@andyleiserson andyleiserson deleted the jj-push-ruvv branch February 24, 2026 22:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants