Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

toji
Copy link
Member

@toji toji commented Aug 12, 2020

Also fixes an error I made with a previous PR where I mistakenly compared GPUDevices against GPURenderPassEncoders instead of the GPUDevice the render pass encoder was created with.


Preview | Diff

@toji toji requested review from kvark and kainino0x August 12, 2020 22:16
Copy link
Contributor

@kainino0x kainino0x left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@kvark kvark left a comment

Choose a reason for hiding this comment

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

Thank you, good stuff!

- |bindGroup|.{{GPUObjectBase/[[device]]}} is |this|.{{GPUObjectBase/[[device]]}}.
- |index| < {{GPULimits/maxBindGroups|GPULimits.maxBindGroups}}.
- dynamicOffsets.length is
|bindGroup|.{{GPUBindGroup/[[layout]]}}.{{GPUBindGroupLayout/[[dynamicOffsetCount]]}}.
Copy link
Contributor

Choose a reason for hiding this comment

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

we also need to check that the binding offset + dynamic offset + minimumBufferSize is <= buffer size, for each binding with dynamic offset.

Copy link
Member Author

Choose a reason for hiding this comment

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

Right, forgot that we can validate this here rather than during the draw call.

I took a stab at it but... wow. There's just no clean way to document this validation! Feedback on how to help it read better is very welcome.

Copy link
Contributor

Choose a reason for hiding this comment

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

Since this is a newly written rule, added it to the test plan: https://hackmd.io/@webgpu/H1MwoqqAU#encodingcmdsprogrammable_passspects

|index|: The index to set the bind group at.
|bindGroup|: Bind group to use for subsequent render or compute commands.
|dynamicOffsetsData|: Array containing buffer offsets in bytes for each entry in
|bindGroup| with marked as {{GPUBindGroupLayoutEntry/hasDynamicOffset}}.
Copy link
Contributor

Choose a reason for hiding this comment

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

ok, here comes the fun part: what is the order?
In Vulkan, dynamic offsets need to be provided in the order of binding, which can be different from the order of either BindGroupLayoutEntry or BindGroupEntry. I suggest to follow this route and specify that the offsets are taken in the order of increased binding number

Copy link
Member Author

Choose a reason for hiding this comment

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

Oof, I have no idea what's going to be best here. Gonna let the editors work this one out. 😅

Copy link
Contributor

Choose a reason for hiding this comment

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

I definitely think it should be the binding number order. BindGroup(Layout)Descriptor.entries should be treated as an unordered map from binding => entry.

@toji
Copy link
Member Author

toji commented Aug 13, 2020

Oops! Forgot to push when I made my previous changes. Code is updated now.

Copy link
Contributor

@kvark kvark left a comment

Choose a reason for hiding this comment

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

Thank you!

@kvark
Copy link
Contributor

kvark commented Aug 13, 2020

CI is sad

@toji
Copy link
Member Author

toji commented Aug 13, 2020

Weird. I had fixed that, wonder what sort of git-goof I did to lose it. 🤷 Fixed (again) now.

@kvark kvark merged commit cf0645f into gpuweb:main Aug 13, 2020
@toji
Copy link
Member Author

toji commented Aug 13, 2020

Well crumb, my ability to git properly is wildly off today. I accidentally added code that was intended for a separate PR to the final commit of this one. Specifically: aeaf777

The change was applying a suggestion from @kainino0x in a previous PR to move the repeated checks for |object| is [=valid=] && |object|.device is |this|.device into a separate algorithm that can be reused everywhere. The change was "done", and I was going to upload it for review just now what I noticed the error.

I apologize for the mistake, as this was certainly not something I intended to slip in unnoticed. Depending on what the editors would prefer I'm happy to:

  • Revert this PR entirely and re-post it without the accidental addition.
  • Submit a change to only revert the accidentally added code and post it again as a separate PR.
  • Leave it be if the code looks good. (It's not a particularly complicated change.)

@kvark
Copy link
Contributor

kvark commented Aug 13, 2020

I think we should leave it. The spec is still heavily a draft, let's fix it as we go.

@toji toji deleted the setBindGroup-validation branch August 13, 2020 22:36
- |bindGroup|.{{GPUObjectBase/[[device]]}} is |this|.{{GPUObjectBase/[[device]]}}.
- |index| &lt; {{GPULimits/maxBindGroups|GPULimits.maxBindGroups}}.
- dynamicOffsets.length is
|bindGroup|.{{GPUBindGroup/[[layout]]}}.{{GPUBindGroupLayout/[[dynamicOffsetCount]]}}.
Copy link
Contributor

Choose a reason for hiding this comment

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

Since this is a newly written rule, added it to the test plan: https://hackmd.io/@webgpu/H1MwoqqAU#encodingcmdsprogrammable_passspects

|index|: The index to set the bind group at.
|bindGroup|: Bind group to use for subsequent render or compute commands.
|dynamicOffsetsData|: Array containing buffer offsets in bytes for each entry in
|bindGroup| with marked as {{GPUBindGroupLayoutEntry/hasDynamicOffset}}.
Copy link
Contributor

Choose a reason for hiding this comment

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

I definitely think it should be the binding number order. BindGroup(Layout)Descriptor.entries should be treated as an unordered map from binding => entry.

|dynamicOffsetsData|[|dynamicOffsetIndex| + |dynamicOffsetsDataStart|].
- |bufferBinding|.{{GPUBufferBinding/offset}} + |bufferDynamicOffset| +
|minBufferBindingSize| &le;
|bufferBinding|.{{GPUBufferBinding/buffer}}.{{GPUBuffer/[[size]]}}.
Copy link
Contributor

Choose a reason for hiding this comment

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

minBufferBindingSize is optional, and this rule should only apply if it's provided.

Copy link
Member Author

Choose a reason for hiding this comment

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

In the definition of the GPUBindGroupLayoutEntry it says that minBufferBindingSize defaults to 0 for buffer types. If that's the case then this works out regardless of if it's provided or not, right?

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmmm, I think this was unintentional. It looks like it was effectively a merge conflict between #874 and #919. minBufferBindingSize should not have a default (undefined is a special/sentinel value that says the size will be checked at draw time instead of createBindGroup time).

</div>
</dl>

<div algorithm>
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps we should pre-bake the list of dynamically-offset buffer bindings in createBindGroupLayout. I think it would just be a sorted list of binding numbers like [1, 3, 4] and you could use those to index back into the bind group (layout) entries

- If the [=device=] that owns an object is lost, the object becomes invalid.
</div>

<div algorithm>
Copy link
Contributor

Choose a reason for hiding this comment

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

This refactor looks excellent.

ben-clayton pushed a commit to ben-clayton/gpuweb that referenced this pull request Sep 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants