Add feature float32-filterable

[almarklein]

Connections

• Add missing webgpu features wgpu-native#322
• Further spec compliance #2170
• Make use of float32-filterable webgpu feature pygfx/pygfx#618

Description

The float32-filterable is currently the only remaining webgpu feature not supported by wgpu-core (and wgpu-native).

(BTW: bgra8unorm-storage has been added recently and can be ticked in #2170.)

Testing

I compiled wgpu-native with this change included, ran a volume rendering example in pygfx (via wgpu-py). The example works when I activate this feature, and does not when I don't. (We've been using TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES as a workaround).

Maybe this also needs a unit test?

Checklist

• Run cargo fmt.
• Run cargo clippy. If applicable, add:
• Run cargo xtask test to run tests.
• Activate/check feature on each gfx-hal backend:
  • Metal
  • Vulkan
  • dx11
  • dx12
  • gles
  • Need checking.
• Unit test(s)
• Add change to CHANGELOG.md. See simple instructions inside file.

[teoxoy]

gles. Looks like it's automatically enabled when TEXTURE_FLOAT_LINEAR ext is available. Is that correct?

I think it is.

This should always be available on d3d12. Vulkan needs a check (for SAMPLED_IMAGE_FILTER_LINEAR).

Background: gpuweb/gpuweb#3601 (comment) & gpuweb/gpuweb#3556 (comment)

[crowlKats]

Deno part LGTM

[almarklein]

I implemented setting the adapter feature for all hal backends. These really need double-checking - I have no idea whether this is right (e.g. dx11?).

[teoxoy]

I implemented setting the adapter feature for all hal backends. These really need double-checking - I have no idea whether this is right (e.g. dx11?).

Thanks! The d3d11 backend is not currently working, and it's unclear if we need it anymore now that OpenGL is also working on Windows without Angle.

@cwfitzgerald is there still value in keeping the d3d11 backend around?

[cwfitzgerald]

@teoxoy #4797 no :)

[Fancy2209]

@teoxoy #4797 no :)

You mean wgpu isn't removing DX11?

[teoxoy]

@teoxoy #4797 no :)

You mean wgpu isn't removing DX11?

This was in response to:

@cwfitzgerald is there still value in keeping the d3d11 backend around?

[teoxoy]

@almarklein I think the implementation looks good but I think the tests are still failing because we might allow usage of features even if they have not been explicitly enabled by users...

I'll look into it a bit more and put up a PR for it.

[almarklein]

That's what I thought too. I am just prepping a Windows machine to investigate this further and see where I can best add a check for this (suggestions are welcome).

[teoxoy]

Actually that will only happen in the case of the OpenGL ES backend.

wgpu/wgpu-core/src/device/resource.rs

Lines 3207 to 3215 in 4184932

	let using_device_features = self
	.features
	.contains(wgt::Features::TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES);
	// If we're running downlevel, we need to manually ask the backend what
	// we can use as we can't trust WebGPU.
	let downlevel = !self.downlevel.is_webgpu_compliant();
	if using_device_features || downlevel {
	Ok(adapter.get_texture_format_features(format))

If you could figure out why Windows and Vulkan are failing that would be great.

[almarklein]

So it look like for the GL and DX12 backends downlevel is true, causing it to use get_texture_format_features and thus bypassing the checks that I added in guaranteed_format_features 😄

If I add checks here (in the code you referred to) all tests pass on my Windows machine. Does this mean it makes more sense to just apply the checks here instead? Or do we still need them in sample_type()?

[almarklein]

Does this mean it makes more sense to just apply the checks here instead? Or do we still need them in sample_type()?

In retrospect I don't think it makes sense. Instead I made the device_features arg optional, so the code that provides the Features::empty() can pass None instead, which feels less awkward.

CI is green!

[teoxoy]

Great stuff!

[teoxoy]

CI is running into #4573 (comment), not related to this PR.