-
Notifications
You must be signed in to change notification settings - Fork 353
Refactor binding limit validation spec #1689
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
Conversation
7d2bfd4 to
be356c0
Compare
|
PTAL |
kvark
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the idea of having a dedicated mini-section, explaining the binding limits, is a good one.
I'm concerned however about the "cost" term used here. It's associated with something that can fluctuate (e.g. cost of an item in free market). Can we reword this to use more of a "limit" term instead? I.e. "this bindings counts towards Xxx limit", just like Vulkan does it.
|
I think the clarify benefits a lot from having a specific word to define the binding cost. I don't personally think the connotation of "cost" is that important here, it's quite clear that it's a fixed integer value. An alternative might be to define it in terms of the "currency" ("takes N uniformBuffer binding slots"?) instead of the "cost"/"price", though not sure how it would shake out. |
toji
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, thanks!
spec/index.bs
Outdated
| of [=supported limits=] |limits| | ||
| if any of the following are true: | ||
|
|
||
| - Let |cost| be the [=binding cost=] of |entries|. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels just a little weird to use the same cost structure for testing against both layout-level limits and stage-level limits. It's not really a problem, just surprised me at first.
spec/index.bs
Outdated
| </table> | ||
|
|
||
| <div algorithm="binding cost"> | ||
| The <dfn>binding cost</dfn> for a [=list=] |entries| of {{GPUBindGroupLayoutEntry}} values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have the same mental association of "cost" meaning a potentially fluctuating thing that @kvark mentioned, but for whatever reason the term "cost" here still reads awkwardly to me when paired with "limits" of a particular resource. I don't have a good explanation as to why.
Other potential terms that I can think of:
- binding requirements
- binding uses
- binding counts
|
Editors: Try to rephrase this as "uses N slots toward X limit" |
toji
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, thanks!
Preview | Diff