-
Notifications
You must be signed in to change notification settings - Fork 353
maxBindGroupsPlusVertexBuffers and unbinding #3938
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
maxBindGroupsPlusVertexBuffers and unbinding #3938
Conversation
Fixes gpuweb#2749 On an implementation on top of Metal that chooses to use argument buffers, bind groups and vertex buffers use the same metal resource (vertex buffer slots). This limit allows the site to trade-off bind groups and vertex buffers themselves, as long as the total sum of them don't exceed a limit. This will be a bit tricky to implement on Metal if it's possible to unbind vertex buffers or bind groups (see gpuweb#3787) but I think it's possible and worth the tradeoff to not expose the complexity to the web, but to instead just handle it in the browser.
|
WebGL uses |
|
sorry, right, I meant "nullable", not "optional". That's the 4th option above, it just doesn't work as well as WebGL because of the dynamicOffsets and offset/size parameters that come along with these calls. |
|
That 4th option was also the suggestion we resolved was OK at the F2F, so we could just go ahead and do it. |
|
[Editors] agreed to make the parameters optional. For validation, treat null as if it's an empty buffer or empty bind group, such that only the defaults ( I'll revise soon. |
|
Wasn't the consensus from the F2F that there would be no validation for these optional arguments if the buffer of bindgroup is null? |
Technically yes but we didn't really talk about it. Editors had some discomfort with it (ambiguity of how many sanity checks there would be on the extra parameters, [EDIT] and accepting clearly-nonsense input from the user), so this was what we decided to draft. |
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.
LGTM
|
Editors meeting again for:
|
Editors still prefer to keep this validation so we can tell the user when they did something that clearly doesn't make sense. Plan to tacit-resolution-queue it when this PR is ready, but @Kangz please comment anytime if you think we shouldn't do it this way. |
|
That sounds good, and we can always relax validation later if we find it is a problem, so better to start this way. |
I agree with this. |
|
Previews, as seen when this build job started (22ff782): |
|
EDIT: comment moved to correct thread: #3938 (comment) |
ee3c3db to
cd8ad7f
Compare
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.
LGTM with one question.
| optional sequence<GPUBufferDynamicOffset> dynamicOffsets = []); | ||
|
|
||
| undefined setBindGroup(GPUIndex32 index, GPUBindGroup bindGroup, | ||
| undefined setBindGroup(GPUIndex32 index, GPUBindGroup? bindGroup, |
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.
Does this overload need the bind group to be nullable? I remember we talked about how to interpret these values earlier, and I forget where we landed, but it seems like we only really need one variant of the function (the one with the default value for dynamic offsets) to accept null here.
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.
Strictly speaking we only need one, but it makes just as much sense in both: both can specify zero dynamicOffsets. So for example WASM bindings could exclusively use the Uint32Array overload instead of having to call the other when bindGroup is null.
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.
Thanks for keeping an eye out for Wasm. This indeed makes it easier to implement.
Do WebGPU implementations care here if user calls encoder.setBindGroup(i, undefined, ...); versus encoder.setBindGroup(i, null, ...); ? I find that it would be simpler from marshalling perspective to call encoder.setBindGroup(i, undefined, ...); to unbind a bind group, but is that guaranteed to work all the same as passing null?
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's guaranteed to accept both null and undefined. Per WebIDL spec for conversions from ECMAScript values into a nullable type T?:
2. Otherwise, if V is undefined, and T includes undefined, return the unique undefined value.
3. Otherwise, if V is null or undefined, then return the IDL nullable type T? value null.
T here is GPUBindGroup, which doesn't include undefined.
|
I'll land this but leave it on the |
…indGroup() and setVertexBuffer(). gpuweb/gpuweb#3938
My suggestion to use overloads with
nulldidn't work (there's nonulltype in WebIDL), so I just did the simplest thing and we can bikeshed from here. Alternatives:GPUBindGroup?/GPUBuffer?in the overloads and explicitly throw aTypeErrorif not null (weird)optionalnullable (weird because extra parameters are thrown away; do we validate them?)Fixes #3787
Fixes #2749
Closes #3788 (this PR includes that commit)