TextureFormat::Depth24PlusStencil8 no longer supported in 0.14.0

[relrelb]

Description
Before 0.14.0, wgpu::TextureFormat::Depth24PlusStencil8 was supported without a need to request any wgpu::Features. Since 0.14.0, it requires wgpu::Features::DEPTH24PLUS_STENCIL8, which is not supported on all platforms.
Together with the fact that wgpu::Depth32FloatStencil8 requires a feature as well (albeit it has slightly wider support), this means stencil textures cannot be used reliably anymore.

Repro steps
Not an ideal repro, but while upgrading to wgpu 0.14.0 in Ruffle, the following error happened:

[2022-10-15T08:01:27Z ERROR wgpu::backend::direct] Handling wgpu errors as fatal by default
thread 'main' panicked at 'wgpu error: Validation Error

Caused by:
    In Device::create_texture
    Texture format Depth24PlusStencil8 can't be used due to missing features.
    Features DEPTH24PLUS_STENCIL8 are required but not enabled on the device

As a solution, wgpu::Features::DEPTH24PLUS_STENCIL8 was added to the list of required features: https://github.com/ruffle-rs/ruffle/pull/8226/files#diff-d2d6e71ebcd52c28fa4e4c89c8249dfe5b9deb974415e86181856aef3331eb76R594.
However, it turned out that wgpu::Features::DEPTH24PLUS_STENCIL8 is unsupported on some platforms, where the following error happens:

[2022-10-15T07:40:03Z ERROR wgpu::backend::direct] Error in Adapter::request_device: unsupported features were requested: DEPTH24PLUS_STENCIL8
Error: Couldn't create wgpu rendering backend

See ruffle-rs/ruffle#8295 for more context.

Note that before upgrading to 0.14.0, wgpu::TextureFormat::Depth24PlusStencil8 did work on those now-unsupported machines, arising the question whether the requirement of wgpu::Features::DEPTH24PLUS_STENCIL8 is precise.

Expected vs observed behavior
I'd expect one of the following scenarios:

1. wgpu::TextureFormat::Depth24PlusStencil8 will work without wgpu::Features::DEPTH24PLUS_STENCIL8, as it used to be before 0.14.0.
2. wgpu::Features::DEPTH24PLUS_STENCIL8 will still be required, but it will be supported on said machines that supported wgpu::TextureFormat::Depth24PlusStencil8 before 0.14.0.

Extra materials
I suspect the behavioral change is caused by bf5fe3d. Maybe it can be reverted as a quick fix?

Platform
On Windows 11, Intel UHD Graphics 770, Vulkan backend, wgpu::TextureFormat::Depth24PlusStencil8 is known to work both before and on 0.14.0.
On Arch Linux, RX 580, Mesa 22.2.1, it is known to be working before 0.14.0 but no longer works on 0.14.0.

[Dinnerbone]

Prior to this change, D24 was silently converted to D32 on unsupported systems - that code is still in place now, even though it's somewhat redundant.

wgpu/wgpu-hal/src/vulkan/conv.rs

Lines 53 to 66 in cdf6ee0

	Tf::Depth24Plus => {
	if self.texture_d24 {
	F::X8_D24_UNORM_PACK32
	} else {
	F::D32_SFLOAT
	}
	}
	Tf::Depth24PlusStencil8 => {
	if self.texture_d24_s8 {
	F::D24_UNORM_S8_UINT
	} else {
	F::D32_SFLOAT_S8_UINT
	}
	}

[cwfitzgerald]

So this feature isn't even part of webgpu anymore, so I think we just are weirdly out of sync with upstream: https://gpuweb.github.io/gpuweb/#feature-index

Now that I say that I'm not even sure where this feature came from?

[maxammann]

I tried to switch from Depth24PlusStencil8 to Depth32FloatStencil8. But at least on Linux Firefox/Chrome that format is not supported:

Error in Adapter::request_device: unsupported features were requested: DEPTH32FLOAT_STENCIL8 [module.js:14988:15](webpack://demo/../lib/dist/esbuild-esm/module.js?)

[maxammann]

@relrelb does DEPTH32FLOAT_STENCIL8 work in WebGL for you? Maybe support for webgl is a distinct issue.

[cwfitzgerald]

I believe all the logic for D24S8 -> D32S8 fallback is already implemented (should double check) but we should be able to just yank the feature.

Will work on this next week if no one else gets to it, and will push a patch release which keeps the feature, but enables it on all devices.

[maxammann]

I could give it a try, but I don't really understand what the bug is. Like you said the fallback is already implemented.

I suppose that somehow the feature detection is broken in browsers. My chrome does support D32S8 (reported in about:flags), but wgpu is not detecting that.

[adrian17]

I suppose that somehow the feature detection is broken in browsers

I have reports of unsupported features were requested: DEPTH32FLOAT_STENCIL8 issue on native (at least on Linux) builds too.

For the record, we're starting to consider reverting to 0.13.x, given currently we have a choice of either regressing "depth24-only" or "depth32-only" users.

[cwfitzgerald]

Fix published in wgpu-hal and wgpu-types 0.14.1