Add BC formats. #812
Add BC formats. #812
Conversation
|
I thought the whole point was to put these inside the extension, rather than in the main document. |
|
Are IDL comments normative? |
|
@litherum I don't think we talked enough about how extensions are going to be represented. In Khronos APIs, you can find the following documents describing the API:
Is this close to what you are thinking? (as a side discussion, extensions can be somewhat elegantly represented as PRs, which makes it clear what version they are written aganst, and how they affect the spec). |
|
IMHO extensions that we expect all vendors to implement could be in the main spec. They are like optional features in Vulkan ("KHR" extensions are essentially core too), or things gated by feature levels in Metal and D3D12. It makes sense to have them along the rest of the spec because they are the extensions people are most likely to use, and will go through this group's standardization process. Vendor or multi-vendor extensions can be in separate document so as to not burden the main spec if someone comes up with a full GLES1 fixed-function style extension for example. |
|
This confusion is the reason I've been talking about calling these optional features "capabilities" or "features" rather than "extensions". I think the word "extension" should be reserved for things which are specified outside of the main spec. BC formats solidly fall into the category of things that should be in the main spec. It is present on all desktop platforms. |
Not really, but there's no super-trivial way to organize this so that the blocks of formats are clearly written. It's better to have something here than nothing, but we should expect the comment to eventually get removed or made non-normative. Not everything we write into the spec right now can be shipping-quality, because editors haven't established the patterns yet. |
* wgsl: Add tests for shared entry point IO structs Test that a structure containing entry point IO attributes can be shared between different shader stages, between shader and non-shader functions, and between entry points and buffers. * Address review comments
+CC @Jiawei-Shao @litherum @kvark