-
Notifications
You must be signed in to change notification settings - Fork 828
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Design a sideband output for HLL -> SPIR-V #701
Comments
like a summary of all the IO variables defined and where they are bound? |
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? |
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. |
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. |
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. |
One interesting new thing to do is design a sideband mechanism, where an HLL -> SPIR-V emits two outputs:
The sideband would contain things like
A somewhat standard form for all HLLs would be good.
The text was updated successfully, but these errors were encountered: