Internal usage flags and rules #994
Conversation
spec/index.bs
Outdated
| - {[=copy-source=] | [=input=] | [=uniform=] | [=storage-read=]} - in any combination | ||
| - [=copy-destination=] - singular usage | ||
| - {[=storage=] | [=storage-read=]} - in any combination | ||
| - [=attachment=] - singular usage |
There was a problem hiding this comment.
Are we going to have a separate rule that disallows using a subresource for multiple attachments in the same pass?
There was a problem hiding this comment.
Since doing that doesn't match any of the allowed sets, the current spec automatically disallows this
spec/index.bs
Outdated
| - {[=copy-source=] | [=input=] | [=uniform=] | [=storage-read=]} - in any combination | ||
| - [=copy-destination=] - singular usage | ||
| - {[=storage=] | [=storage-read=]} - in any combination | ||
| - [=attachment=] - singular usage |
There was a problem hiding this comment.
Since doing that doesn't match any of the allowed sets, the current spec automatically disallows this
spec/index.bs
Outdated
| - {[=internal usage/input=] | [=internal usage/constant=] | [=internal usage/storage-read=]} - in any combination | ||
| - {[=internal usage/storage=] | [=internal usage/storage-read=]} - in any combination | ||
| - [=internal usage/attachment=] - singular usage | ||
| - {[=internal usage/attachment-read=] | [=internal usage/storage-read=] | [=internal usage/constant=]} - in any combination |
There was a problem hiding this comment.
Why not bundle this line with the first one? They seem to be split just because one talks about buffers and on about textures?
There was a problem hiding this comment.
Yeah, we can merge them. But it kinda nice to have separate cases for buffers and textures...
There was a problem hiding this comment.
I think it's good to have them separate for buffers and textures. Maybe the two lists of sets should actually be separate: a buffer binding must be in one of these sets: (...), a texture binding must be in one of these sets: (...) (not separating the usages, just the lists of sets)? I think there would be fairly minimal duplication between the two lists.
There was a problem hiding this comment.
LGTM except for the attachment issue (continued below).
I can't figure out how to reply to this thread (github why) so starting it again:
Are we going to have a separate rule that disallows using a subresource for multiple attachments in the same pass?
Since doing that doesn't match any of the allowed sets, the current spec automatically disallows this
I'm confused, doesn't using it for multiple attachments mean the set is set(['attachment', 'attachment']), which is set(['attachment']), which is a subset of this allowed set?
is "singular usage" supposed to imply that this doesn't happen?
we can certainly have less classes. I'm not sure if we should strive to the minimum though? The rules don't make any simpler because of that, but the ease of understanding could be different. For example, I find the "input" and "constant" distinct in my mind, even though they are not handled differently by the rules. I'm open to other opinions, of course :)
No strong preference. On the one hand, naming both "input" and "constant" in the compatibility set is a bit more explicit/self-documenting (though I don't think the meaning of the names is SO apparent that it helps that much with self-documentation). On the other, it kind of makes sense to merge all of the readonly usages into one, so they're simplified.
|
Thanks @kainino0x ! |
|
Not sure why CI isn't happy, it's passing for me locally |
|
As discussed offline, we should probably disallow |
|
@Kangz this is already in this PR fwiw |
|
Discussed at the 2020-08-24 meeting. |
Closes #745
Closes #296
Likely conflicts with #972 (sorry!)
We describe the internal set of flags an implementation considers to track the resource usage, how they map to the descriptor flags provided by the user, and how they are validated. The "mutable"/"immutable" usage distinction is gone, and instead we have a list possible sets of compatible usages, as mentioned in #972 (comment). It also includes clarifying the notion of a "subresource" as outlined in #972 (comment)
This PR needs more work on naming and editing, so that it looks better. Input is invited!
Preview | Diff