Synchronization section of the spec #557

kvark · 2020-02-24T21:55:33Z

It's very rough, hoping to get feedback to make it better. It's supposed to cover the important missing bits about what the actual usage scopes are, and how the validation is done.

Preview | Diff

Kangz

Looks good!

Kangz · 2020-02-25T13:36:55Z

spec/index.bs

+at the [=usage scope=] boundaries.
+
+This specification defines the following [=usage scopes=]:
+  1. an individual copy command on a {{GPUCommandEncoder}}, such as {{GPUCommandEncoder/copyBufferToTexture()|GPUCommandEncoder.copyBufferToTexture}}.


or just "an individual command on a ..."

Kangz · 2020-02-25T13:37:28Z

spec/index.bs

+
+This specification defines the following [=usage scopes=]:
+  1. an individual copy command on a {{GPUCommandEncoder}}, such as {{GPUCommandEncoder/copyBufferToTexture()|GPUCommandEncoder.copyBufferToTexture}}.
+  2. an individual command inside a {{GPUComputePassEncoder}}, such as {{GPUProgrammablePassEncoder/setBindGroup(index, bindGroup, dynamicOffsets)|GPUProgrammablePassEncoder.setBindGroup}}.


Actually isn't it just dispatch and dispatch indirect that are usage scopes? The rest are just setting state for these two commands.

This is a great question to raise. The reason I went for any command here is apposed to just the draws, is because it would be awkward to allow bad state to be bound even if it's not used.

So, first, I think we are going to be specifying the exact resources used by a dispatch as those that are covered by the bind groups attached to slots expected by the layout of the active pipeline. So there might be bindings not included/used by a dispatch, and similarly for the draws.

What happens if, for example, the user is recording a render pass, and they bind a group that uses one of the current render targets as STORAGE? It seems to me that making this an error versus non error based on the dependencies of a draw() would make up for a weaker API. It would be nice to specify that, in particular, everything you bind within a render pass becomes part of the usage scope for this pass.

Thanks for the detailed explanation. It makes a lot of sense for the render pass. For the dispatch we'd want to consider the resources used by that dispatch and only this one so the wording might get a bit more complicated.

What happens if the user does setBindGroup() with one that is self-conflicting? I.e. it has different mutable bindings for the same resource? If we spec the usage scopes for dispatch only, we'd be ignoring these bindings, potentially.

I'm not sure what's best here. Both validating the setBindGroup by itself and not doing it seem weird.

Would be nice to be somewhat consistent between the compute and render passes wrt the usage scopes, even if the scopes are different. I.e. it would be good to say that the usage scope of a render pass is the union of the usage scopes of its commands, and for the compute pass it's just not a union.

So the same kind of problem can be seen in render passes: if the user calls setVertexData we have a choice (in how we define the usage scopes):

Every command by itself is a usage scope, and the render pass considers the union of all usage scopes of its commands. This is what the current PR has (or at least aims to). The consequence here is that we consider the vertex buffer to be used by the pass (regardless of what the draw calls would do).

Only draws, dispatches, and copies are considered to be the usage scopes (and a render pass is a union of its draw usage scopes). This means that on each draw() we would have to traverse the dependencies and consider the usage scopes. In this case, it will be up to the active render pipeline layout at the next draw() to decide whether the vertex buffer is considered to be used.

I have a slight preference towards (1) for making the validation simpler, which may allow us to have higher draw call throughput in the end.

I think it makes sense that calling setVertexBuffer will mark the buffer as used for that pass even if it's not actually accessed by the draw call. It's up to the developer to prevent that from happening if they want to use a vertex buffer as something else during that pass.

Kangz · 2020-02-25T13:39:17Z

spec/index.bs

+For example, it can check if all the bindings inside a single {{GPUBindGroup}} make a valid usage scope
+that would be considered every time {{GPUProgrammablePassEncoder/setBindGroup(index, bindGroup, dynamicOffsets)}} is called.
+
+Issue: Should a created bind group then be considered invalid?


TBH I don't think it's useful for implementations to do early validation like this because it only optimizes the error case, not the success case.

Yeah, I don't have strong feelings about this. Will remove the issue.

JusSn · 2020-03-02T22:30:37Z

spec/index.bs

+Timeline could be split into a sequence of [=usage scope=]:
+within each scope the usage of the [=subresource=] stays unchanged,


Suggested change

Timeline could be split into a sequence of [=usage scope=]:

within each scope the usage of the [=subresource=] stays unchanged,

The [=Queue timeline=] is split into a sequence of [=usage scope=]s.

Within each scope the usage of the [=subresource=] stays unchanged,

In multiqueue, there's one queue timeline per queue, right? Hard to say now, but there needs to be at least some synchronization at the device timeline.

I think it would be up to the multi-queue proposal to specify.

JusSn · 2020-03-02T22:40:18Z

spec/index.bs

 {{GPUQueue/submit(commandBuffers)}} does nothing and produces an error if any of the following is true:

 - Any {{GPUBuffer}} referenced in any element of `commandBuffers` isn't in the `"unmapped"` [=buffer state=].
+ - Any of the [=usage scopes=] contained in the command buffers fail the [=usage scope validation=].


Suggested change

- Any of the [=usage scopes=] contained in the command buffers fail the [=usage scope validation=].

- Any of the [=usage scopes=] contained in the command buffers fail [=usage scope validation=].

I wonder why the shouldn't be here?

I agree it shouldn't be there, but kind of okay either way: "if any X fail validation." vs "if any X fail the validation."

JusSn · 2020-03-02T22:42:12Z

spec/index.bs

+which have been validated for correct resource usage during recording on the [=Content timeline=],
+results in the resource usage also being valid at the [=Queue timeline=].
+
+The implementation does the <dfn dfn>usage scope validation</dfn> by composing


Suggested change

The implementation does the <dfn dfn>usage scope validation</dfn> by composing

The implementation performs <dfn dfn>usage scope validation</dfn> by composing

JusSn · 2020-03-02T22:42:38Z

spec/index.bs

+
+The implementation does the <dfn dfn>usage scope validation</dfn> by composing
+the union of all usage flags of the [=subresources=] used by the [=usage scope=].
+The {{GPUValidationError}} is generated in the current scope with appropriate error message


Suggested change

The {{GPUValidationError}} is generated in the current scope with appropriate error message

A {{GPUValidationError}} is generated in the current scope with appropriate error message

kainino0x

Looks pretty good so far.

kainino0x · 2020-03-09T20:17:04Z

spec/index.bs

+Timeline could be split into a sequence of [=usage scope=]:
+within each scope the usage of the [=subresource=] stays unchanged,


In multiqueue, there's one queue timeline per queue, right? Hard to say now, but there needs to be at least some synchronization at the device timeline.

kainino0x · 2020-03-09T20:21:27Z

spec/index.bs

+if the union contains a [=mutating usage=] combined with any other usage.
+
+Note: an implementation is likely to validate the usage scopes earlier
+than at {{GPUQueue/submit()|GPUQueue.submit}} time, where the [=Queue timeline=] is defined.


Suggested change

than at {{GPUQueue/submit()|GPUQueue.submit}} time, where the [=Queue timeline=] is defined.

than at {{GPUQueue/submit()|GPUQueue.submit}} time (which occurs on the [=Queue timeline=]).

kainino0x · 2020-03-09T20:23:34Z

spec/index.bs

+For example, it can check if all the bindings inside a single {{GPUBindGroup}} make a valid usage scope
+that would be considered every time {{GPUProgrammablePassEncoder/setBindGroup(index, bindGroup, dynamicOffsets)}} is called.


I don't understand what this is saying; we can talk about it on the editors call.

resolved: We don't need this particular bit. But we should move the validation from submit() to finish().

kainino0x · 2020-03-09T20:28:40Z

spec/index.bs

        {{GPUBindingType/"sampled-texture"}}, |view|'s texture's {{GPUTextureDescriptor/usage}}
-        must include {{GPUTextureUsage/SAMPLED}}.
+        must include {{GPUTextureUsage/SAMPLED}}. The texture's [=subresources=] seen by the |view|
+        are considered to be [=used=] by the resulting bind group as {{GPUTextureUsage/SAMPLED}}.


We could make this more formal (put the subresource usages in a list, or something), but it can definitely be done later

Rewrite the usage validation section to tell that it happens at finish() time. Add "usedBuffers" and "usedTextures" internal slots to "GPUBindGroup".

kvark · 2020-03-11T13:56:40Z

I addressed the changes we discussed and rebased this. The validation is described to happen at finish() time now. I also added the usageBuffers and usageTextures internal slots to the bind group as a "pilot" thing. We will probably need to evolve it in the following ways:

define an internal object with all the usages, so that we can have it as internal slot for things like bind groups, bundles, or render passes.
clearly define an internal object for a texture subresource (i.e. a "(texture, mipmap level, slice)" tuple).

We can do this as a follow-up.

kainino0x

I'll open a PR with some small nits.

kainino0x · 2020-03-13T03:30:50Z

spec/index.bs

+
+Issue: This section will need to be redacted to support multiple queues.
+
+The [=Queue timeline=] could be split into a sequence of [=usage scopes=]:


Is this supposed to be part of the Issue? If not, then "could" doesn't make sense here

no, it's not a part of the issue. I was trying to say that we can consider the queue timeline to be seen as a sequence of usage scopes.

Ok, then I think the version I have in the "nits" should be what you intended.

* Syncronization section * Address Kang's notes * Address Kai's comments. Rewrite the usage validation section to tell that it happens at finish() time. Add "usedBuffers" and "usedTextures" internal slots to "GPUBindGroup".

kvark requested review from kainino0x and JusSn February 24, 2020 21:55

kvark force-pushed the sync branch from 1d4006b to 845e9cd Compare February 24, 2020 21:56

Kangz approved these changes Feb 25, 2020

View reviewed changes

JusSn reviewed Mar 2, 2020

View reviewed changes

kainino0x changed the title ~~Syncronization section of the spec~~ Synchronization section of the spec Mar 9, 2020

kainino0x reviewed Mar 9, 2020

View reviewed changes

kvark added 3 commits March 11, 2020 09:51

Syncronization section

4879297

Address Kang's notes

5ef3b6e

Address Kai's comments.

5d52fdd

Rewrite the usage validation section to tell that it happens at finish() time. Add "usedBuffers" and "usedTextures" internal slots to "GPUBindGroup".

kvark force-pushed the sync branch from 401ea36 to 5d52fdd Compare March 11, 2020 13:53

kvark requested a review from kainino0x March 11, 2020 13:53

kvark marked this pull request as ready for review March 11, 2020 20:28

kvark merged commit 82346de into gpuweb:master Mar 13, 2020

kvark deleted the sync branch March 13, 2020 01:26

kainino0x reviewed Mar 13, 2020

View reviewed changes

kvark mentioned this pull request May 12, 2020

validation rules for resource usage tracking #769

Closed

		Timeline could be split into a sequence of [=usage scope=]:
		within each scope the usage of the [=subresource=] stays unchanged,

	- Any of the [=usage scopes=] contained in the command buffers fail the [=usage scope validation=].
	- Any of the [=usage scopes=] contained in the command buffers fail [=usage scope validation=].

	The implementation does the <dfn dfn>usage scope validation</dfn> by composing
	The implementation performs <dfn dfn>usage scope validation</dfn> by composing

	The {{GPUValidationError}} is generated in the current scope with appropriate error message
	A {{GPUValidationError}} is generated in the current scope with appropriate error message

	than at {{GPUQueue/submit()\|GPUQueue.submit}} time, where the [=Queue timeline=] is defined.
	than at {{GPUQueue/submit()\|GPUQueue.submit}} time (which occurs on the [=Queue timeline=]).

		For example, it can check if all the bindings inside a single {{GPUBindGroup}} make a valid usage scope
		that would be considered every time {{GPUProgrammablePassEncoder/setBindGroup(index, bindGroup, dynamicOffsets)}} is called.


		Issue: This section will need to be redacted to support multiple queues.

		The [=Queue timeline=] could be split into a sequence of [=usage scopes=]:

Synchronization section of the spec #557

Synchronization section of the spec #557

Uh oh!

Conversation

kvark commented Feb 24, 2020 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kangz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kainino0x left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kvark commented Mar 11, 2020

Uh oh!

kainino0x left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kvark commented Feb 24, 2020 •

edited by pr-preview bot

Loading