Design a sideband output for HLL -> SPIR-V

[johnkslang]

One interesting new thing to do is design a sideband mechanism, where an HLL -> SPIR-V emits two outputs:

1. SPIR-V
2. Sideband collection of information

The sideband would contain things like

• cbuffer defaults (uniform initializers)
• literal samplers
• annotations
• more....

A somewhat standard form for all HLLs would be good.

[ratchetfreak]

like a summary of all the IO variables defined and where they are bound?

[dneto0]

Why would the sideband info be outside of the SPIR-V module? If we put into the module with new instructions (and higher level groups) then it can be extracted via introspection. Or am I missing something really important in the use case?

[johnkslang]

Why would the sideband info be outside of the SPIR-V module?

1. So it can be done and used today, with any version of SPIR-V.
2. Weak reason, but It is also not required: for a particular situation the app might already know all it needs to know.
3. So it does not have to be a Khronos standard.

If we put into the module with new instructions (and higher level groups) then it can be extracted via introspection.

I'm not opposed to this, if Khronos wants to standardize it. The potential trade off is time: If the community wants to dive in, we could have a defacto standard quite quickly, which also offloads Khronos.

[johnkslang]

Okay, I'll correct myself here; we can extend SPIR-V in the community, without Khronos, it just seems a higher hurdle. But, that might be the right way to do it. The SPIR-V we have today is perfectly usable and valid without the second blob, so there is also still some separability feeling about it.

[arcady-lunarg]

Rather than designing a new sideband format, it probably makes sense to define new nonsemantic instructions to carry information in the SPIR-V to address these sorts of needs.