Open jzm-intel opened 2 months ago
That certainly seems reasonable. I think this is the first instance (for WGSL at least) of dependent features.
I was hoping that we won't need an extra feature for this. There are very few devices/drivers that don't support both f16
and subgroups
. Metal and D3D12 won't benefit from a subgroups-f16
feature either.
We are also limited by the nr of feature/limit buckets we can expose.
I agree that it would be nice to get to that point, but while the proposal lists subgroups-f16 it makes sense to make it dependent. We haven't really discussed removing the option yet to my knowledge in meeting.
Currently in the subgroups proposal we have two WebGPU features,
subgroups
andsubgroups-f16
, to enable corresponding WGSL extensionssubgroups
andsubgroups_f16
.Since WebGPU feature
subgroups-f16
is to enable using WGSLsubgroups_f16
to allow using subgroups built-in function withf16
types, it is unreasonable to require this feature when creating devices without also requiring featuresshader-f16
andsubgroups
, and the adapter should report supportingsubgroups-f16
only if it also supportsshader-f16
andsubgroups
features. The same idea also applies to the WGSL extensions, i.e. it is unreasonable to enableshader_f16
extension without also enablingf16
andsubgroups
.If we are going to keep
subgroups-f16
feature and WGSL extension, maybe we can add notes in the subgroups proposal to states e.g.Such validation rule may add a new aspect of features dependency into the validation.
For WGSL shader, maybe we can add notes like