Add provisional key to grammar #464
Conversation
spencer-lunarg
force-pushed
the
spencer-lunarg-provisional
branch
2 times, most recently
from
75ce22d
to
cfe070f
Compare
tools/buildHeaders/header.cpp
Outdated
| virtual std::string enumProvisionalStart(const std::string& name) const { return ""; }; | ||
| virtual std::string enumProvisionalEnd(const std::string& name) const { return ""; }; |
There was a problem hiding this comment.
| virtual std::string enumProvisionalStart(const std::string& name) const { return ""; }; | |
| virtual std::string enumProvisionalEnd(const std::string& name) const { return ""; }; | |
| virtual std::string guardIfProvisionalStart(const std::string& name) const { return ""; }; | |
| virtual std::string guardIfProvisionalEnd(const std::string& name) const { return ""; }; |
just to convey better the function checks before emitting, otherwise it would be better to hoist the check out of the function
|
Thinking about this for a night, I realize maybe the To my knowledge what is breaking people is not so much having some Maybe the simpler first step is to just add the |
Make sense and I agree. We only generated enums and utils against this enum. So if a user of the generated headers needs to guard a provisional spec they'll need one on their side anyway. |
spencer-lunarg
force-pushed
the
spencer-lunarg-provisional
branch
from
cfe070f
to
3981367
Compare
|
Everything related to SPV_KHR_untyped_pointers is also provisional. |
good catch, added |
|
We discussed this PR in the November 13th teleconference. Everything looks reasonable, but it'd be nice to have an example using these provisional additions to the grammar before merging to increase confidence it has everything that we need and so we don't make changes again. @spencer-lunarg do you plan to use the provisional key in the validation layers? If not, maybe we should resurrect the header changes? |
|
This docs for the JSON grammar should be updated too. Although I'm having trouble finding the source for that (!) |
|
What exactly does "provisional" mean, and what is going to act on it? I feel it's a little loose.
oh, it's in the Khronos-internal SPIR-V spec repo under specs/MachineReadableGrammar.asciidoc |
Good question. The name "provisional" comes from "provisionally ratified", but I think it's being used to mean "hey this isn't final, so it might change or go away". If we update the header generation scripts to act on it we could add preprocessor guards around the "provisional" features, to provide a way for compilers or tools to opt-out of the features that are likely to break compatibility for example (see #460). Maybe we should use a different name instead?
Yep, agreed, and @Naghasan already filed a Khronos issue so this doesn't slip through the cracks. Thanks for caling this out though! |
closes #460
The idea is like
VK_ENABLE_BETA_EXTENSIONSthe consumer of the headers can now consume the SPIR-V if they desire ( by adding something likeadd_compile_definitions(SPV_ENABLE_BETA_EXTENSIONS)to their build)Open to suggestions on other ways to go about this