Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design a sideband output for HLL -> SPIR-V #701

Open
johnkslang opened this issue Jan 26, 2017 · 4 comments

Comments

@johnkslang
Copy link
Member

commented Jan 26, 2017

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

This comment has been minimized.

Copy link

commented Jan 26, 2017

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

@dneto0

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Mar 8, 2017

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

This comment has been minimized.

Copy link
Member Author

commented Mar 8, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.