Description
This issue is no longer maintained. Please see https://webgpu-native.github.io/webgpu-headers/Extensions.html instead.
We should have a "registry" of allocated ranges to use for enums, especially WGPUSType and WGPUFeatureName
Per #212 the end of the name of the new values will be the name of the implementation.
In the webgpu.h meeting we agreed to use the top 16 bits for the implementation namespace. I think we can use this for all of the (non-bitflag) enums.
No one really cares about the actual IDs so here's an arbitrary assignment of ranges:
-
0x0000_????
: core, required to implement
Prefix: none.Should be in all implementations, both native and Wasm. Used for features added to WebGPU core after this header stabilizes.
-
0x0001_????
: non-core (multi-implementation) extensions, optional to implement (though maybe they could become required in the future, or maybe we then alias them into block0x0000_????
, TBD)
Prefix: none.May be native-specific or Wasm-specific, both can go in this block.
-
0x0002_????
: WebGPU Compat
Prefix: none? TBD.Special: implementations that don't support compat should ignore these instead of error. This is to be used only for Compat additions that don't affect semantics of a valid program if a non-compat implementation ignores them.
-
0x0003_????
: wgpu-native
Prefix:Wgpu
? (see Naming conventions for extension structs and implementation-specific extensions #212 (comment)) -
0x0004_????
: Emscripten
Prefix:Emscripten
-
0x0005_????
: Dawn
Prefix:Dawn
EDIT: Per #212 (comment) (in which we switched from suffixes to prefixes), prefixes work like so:
wgpuPrefixNewFunction WGPUPrefixNewObject wgpuPrefixNewObjectNewMethod wgpuOldObjectPrefixNewMethod WGPUPrefixNewEnum WGPUPrefixNewEnum_NewValue WGPUOldEnum_PrefixNewValue WGPUPrefixNewStruct WGPUPrefixNewBitflagType WGPUPrefixNewBitflagType_NewValue WGPUOldBitflagType_PrefixNewValue WGPUPrefixNewCallback WGPU_PREFIX_NEW_CONSTANT
EDIT: For bitflags (becoming uint64_t
in #273):
- The least-significant 53 bits are reserved for core - that is, bits defined by the JS API, since it can only represent 53 bits.
- The most-significant 11 bits are for native-only and implementation-specific bits, then overflows into the most-significant end of the least-significant 53 bits if we run out. The allocation of these bits is ad hoc for now.
- Only bits specified in this header will be stable; implementation-specific bits can overlap or change value for now. Eventually for ABI compatibility we'll probably need a registry of these.