Repository navigation
How do Compat extension structs work on output? #547
Description
For Compat extension structs we have this special behavior:
Special: implementations that don't support Compatibility Mode must ignore any chained structs with @ref WGPUSType values in this block, instead of erroring. This block must only be used for Compat additions that can be ignored without affecting the semantics of a non-erroring program.
However for output structs I'm not sure how this should work. (Pretty sure there is just one case of this, the Compat extension to the WGPULimits struct - #470.)
- Should the struct remain unpopulated (as this would imply)?
- Should we never put output-able compat structs in that SType block, keep them in core and require them to be implemented?
I think 2 makes the most sense to me.
Activity
eliemichel commentedon Jun 11, 2025
Option 1. would mean that the Compat extension is populated if and only if the adapter is Compat, so users that want to check this output should not forget to check that the adapter is Compat? For the case of limits it feels ok because the init macro would set the limits of the Compat extension to the undefined sentinel value, so in the case of a non-Compat adapter the result is just "limit is undefined", which makes sense w/o checking that the adapter is Compat.
That being said, if it is only 1 case, it might be better to go for Option 2. so that we don't add an extra rule just for 1 case.
Kangz commentedon Jun 11, 2025
Could we alternatively add compat atomically to webgpu.h at some point (when it lands and sticks in the WebGPU spec) and then request that all implementations of webgpu.h support all of compat at a time? After the initial addition there should be no more additional compat additions no?
Kangz commentedon Jun 11, 2025
Ah it would break API stability after webgpu.h v1 is stable so that's a bad idea nvm.
kainino0x commentedon Jun 18, 2025
+1 to both. @cwfitzgerald, WDYT?
kainino0x commentedon Feb 13, 2026
These limits are always present in the WebGPU spec because they have to be implemented for portability, even when not implementing Compat (see gpuweb/gpuweb#5295). The equivalent choice here is option 2, so barring any objection (@cwfitzgerald?) that's what I think we should do in #580.
Resolve questions about Compat extensions
De-register Compat enum namespace (webgpu-native#584)