Extension enum numbering: block 0 core vs block 1 multi-vendor

[kainino0x]

Yet another question on the minutiae of these blocks :)
Over in #482 (comment) we've been discussing the relation between enum value block 0x0000_???? "Core"/"required to implement" and block 0x0001_???? "Multi-Implementation Extension"/"optional to implement".

The particular issue arises because (1) both of them are unprefixed and (2) "multi-implementation" extensions could be promoted to "required". We thought of 4 strategies for handling this:

1. Allow things in block 1 to become required in the future.

• Potentially we could do this in the future with implementation-specific extensions too (WGPUSType_DawnNewThing = 0x0005_000a), at which point it would make sense to add an unprefixed name, but we could still use a prefixed enum value (WGPUSType_NewThing = 0x0005_000a.

2. Just merge blocks 0 and 1 into block 0, and have some extensions be required and some be optional.
3. Give block 1 a prefix so we can have duplicate things (WGPUSType_ExtNewThing = 0x0001_000a) into block 0 (WGPUSType_NewThing = 0x0000_0015`).

• These can mean the same thing, or be two incompatible versions of the extension, but that's kind of hazardous; various problems have arisen from doing so in GL, though sometimes it's not really avoidable when taking an implementation-specific extension and making it multi-implementation or core.

4. When making something optional (WGPUSType_NewThing = 0x0001_000a) required, have the header renumber it into core (WGPUSType_NewThing = 0x0000_0015) while having implementations (that accepted both values) keep accepting the old value (0x0001_000a, which could be, but does not necessarily have to be, named in the header)

TBH it doesn't really matter because the point of numbering blocks is really just so that implementations have namespaces to work with, so with that in mind I think option 2 makes the most sense, but option 1 is also totally fine.

cc @lokokung @cwfitzgerald

[kainino0x]

I forgot again that I should look at Vulkan to see what it does. It was a little tricky to find the documentation, but it's here:
https://registry.khronos.org/vulkan/specs/latest/styleguide.html#extensions-assigning-token-values

In short, IIUC:

• Everything in block 0 is from vulkan 1.0 and they're not adding new things? Kinda unclear about this
• Everything else (extensions and Vulkan 1.1+) is in blocks by extension number and uses the (decimal) block 1_EEE_EEE_VVV where EEE_EEE is the extension number (minus 1) and VVV is the enum value.
  • We are a library, not a driver, so there's no reason for us to have a registry of every extension, we only need a registry so each implementation gets its own block.

[kainino0x]

Jan 9 meeting:

• KN: What should we do when an optional/multi-vendor extension becomes core?
• KN: Maybe we should just put them all in 0x0000 anyways?
  • CF: Seems fine?
  • KN: Makes it easier w.r.t the generator.
  • Merge 0x0001 into 0x0000
• KN: In Vulkan, every extension has to be a document which is in the registry. They reserve both positive and negative values. VkResult has negative values for errors and positive values for success. We don’t treat our enums as signed.
• CF: Down to do this later on in the future if needed.
• Reserve all negative enum values for future use, then we can do this later
• KN: Vulkan also has a system for bitmasks. Effectively require extensions to reserve exactly the bits it wants. For us, maybe we can just say if bits are being added to existing bitmasks, they need to register with our repository. Otherwise, just make a new bitmask.
  • all: SGTM

[kainino0x]

Will be resolved once the open PRs #492 and #493 are landed.

[kainino0x]

Just for the investigation record, there was one more thing I wanted to check: Vulkan does alias stype values, for example:

• KHR -> core:
  VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE_KHR = VK_STRUCTURE_TYPE_SUBPASS_DESCRIPTION_DEPTH_STENCIL_RESOLVE,
  The value of which is 1000199001 which means it's part of extension 200, VK_KHR_depth_stencil_resolve. So they did not renumber it when moving KHR to core.
• NV -> KHR:
  VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEATURES_NV = VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_COMPUTE_SHADER_DERIVATIVES_FEATURES_KHR,
  Same here, the value is 1000201000: extension 202, VK_NV_compute_shader_derivatives.