Skip to content

Conversation

@kainino0x
Copy link
Contributor

@kainino0x kainino0x commented Mar 8, 2023

My suggestion to use overloads with null didn't work (there's no null type in WebIDL), so I just did the simplest thing and we can bikeshed from here. Alternatives:

  • Name as "bind" and some other type like GPUBindGroup?/GPUBuffer? in the overloads and explicitly throw a TypeError if not null (weird)
  • Name as "bind" and write the overload so it just doesn't have a second parameter (why not rename it then?)
  • Name as "unbind" (straightforward)
  • Instead of an overload, just make the parameter optionalnullable (weird because extra parameters are thrown away; do we validate them?)

Fixes #3787
Fixes #2749
Closes #3788 (this PR includes that commit)

litherum and others added 3 commits March 7, 2023 19:05
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.
@kainino0x kainino0x added tacit resolution candidate Editors may be able to resolve and move to tacit resolution queue needs-cts-issue This change requires tests (or would need tests if accepted), but may not have a CTS issue filed yet labels Mar 8, 2023
@kainino0x kainino0x added this to the V1.0 milestone Mar 8, 2023
@kainino0x kainino0x requested review from litherum and toji March 8, 2023 03:34
@greggman
Copy link
Contributor

greggman commented Mar 8, 2023

@kainino0x
Copy link
Contributor Author

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.

@kainino0x
Copy link
Contributor Author

That 4th option was also the suggestion we resolved was OK at the F2F, so we could just go ahead and do it.

@kainino0x
Copy link
Contributor Author

kainino0x commented Mar 14, 2023

[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 (, 0, undefined or , 0, 0 for setVertexBuffer, , [] for setBindGroup) will be valid anyway.

I'll revise soon.

@Kangz
Copy link
Contributor

Kangz commented Mar 14, 2023

Wasn't the consensus from the F2F that there would be no validation for these optional arguments if the buffer of bindgroup is null?

@kainino0x
Copy link
Contributor Author

kainino0x commented Mar 14, 2023

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.

Copy link
Member

@toji toji left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@kainino0x
Copy link
Contributor Author

kainino0x commented Mar 17, 2023

Editors meeting again for:

  • validation of offset/size/dynamicOffsets
  • when the validation occurs (set time vs draw time)

@kainino0x kainino0x marked this pull request as draft March 20, 2023 20:45
@kainino0x
Copy link
Contributor Author

  • validation of offset/size/dynamicOffsets

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.

@Kangz
Copy link
Contributor

Kangz commented Mar 21, 2023

That sounds good, and we can always relax validation later if we find it is a problem, so better to start this way.

@jimblandy
Copy link
Contributor

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.

@github-actions
Copy link
Contributor

github-actions bot commented Mar 28, 2023

Previews, as seen when this build job started (22ff782):
WebGPU webgpu.idl | Explainer | Correspondence Reference
WGSL grammar.js | wgsl.lalr.txt

@kainino0x
Copy link
Contributor Author

kainino0x commented Apr 3, 2023

EDIT: comment moved to correct thread: #3938 (comment)

@kainino0x kainino0x force-pushed the maxBindGroupsPlusVertexBuffers-with-unbind branch from ee3c3db to cd8ad7f Compare April 4, 2023 19:02
@kainino0x kainino0x requested a review from toji April 4, 2023 19:15
@kainino0x kainino0x added copyediting Pure editorial stuff (copyediting, *.bs file syntax, etc.) and removed for webgpu editors meeting tacit resolution candidate Editors may be able to resolve and move to tacit resolution queue labels Apr 17, 2023
@kainino0x kainino0x marked this pull request as ready for review April 17, 2023 20:48
Copy link
Member

@toji toji left a 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,
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link

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?

Copy link
Contributor Author

@kainino0x kainino0x Aug 4, 2023

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.

@kainino0x
Copy link
Contributor Author

I'll land this but leave it on the for webgpu editors meeting label to touch on the question above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

copyediting Pure editorial stuff (copyediting, *.bs file syntax, etc.) needs-cts-issue This change requires tests (or would need tests if accepted), but may not have a CTS issue filed yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

It should be possible to unbind a bind group / vertex buffer Combined limit for max vertex stage bind groups + vertex buffer bindings

7 participants