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

reserve one scope bit for an Intel extension #406

Closed
wants to merge 2 commits into from

Conversation

bashbaug
Copy link
Contributor

Please reserve one "scope" bit for an Intel extension.

This appears to be the first time a non-Khronos extension has needed a scope bit, so this is a new section in the SPIR-V XML file. I tried to follow existing conventions for other bit reservations, but please let me know if I missed something.

Please pay careful attention to:

  1. I've kept the low 16 bits reserved for Khronos use, similar to the other bit reservations. Do we still want to do this?
  2. I did NOT keep the highest bit 31 reserved, since it's not clear how this would work for the scope bits like it would for things like the loop control bitfield or the memory operands bitfield. Is this correct?

@bashbaug bashbaug marked this pull request as draft January 31, 2024 17:37
@bashbaug
Copy link
Contributor Author

We observed in the January 31st telconference that the scope values aren't bits, so calling this a "scope bit" reservation is not correct and I need to update this PR. I have marked this PR as a draft while I make the necessary changes.

Would we want to consider the scopes in their own "namespace" and reserve them via the XML file, similar to what is done in this PR aside from the "bit" naming? Or, since the scopes are values, would we prefer to assign them from vendor-allocated enum blocks, in which case this PR may not actually be required?

I think I'll change this PR assuming the former, then if we prefer the latter we can simply close this PR without merging.

SPIR-V scopes are values and are not bits in a bitfield.
@bashbaug
Copy link
Contributor Author

OK, I've updated this PR so it refers to "scope values" and not "scope bits", but it seems like this shouldn't be necessary and we should just use an enum value from one of our previously allocated blocks for our new scope instead. This could look a little weird since the KHR scope values will be small values (currently, 0 through 6), whereas the vendor scope values will be much larger (>4096), but this should be fine and we already have similar large discontinuities in other areas (e.g. Capabilities, Decorations, Builtins).

I'll keep this PR as a draft since I'm inclined to close it outright, without merging.

@bashbaug
Copy link
Contributor Author

bashbaug commented Feb 7, 2024

Closing - this PR is not needed. See discussion above.

@bashbaug bashbaug closed this Feb 7, 2024
@bashbaug bashbaug deleted the reserve-scope-bit branch February 7, 2024 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants