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

Skip to content
Merged
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 24 additions & 12 deletions spec/index.bs
Original file line number Diff line number Diff line change
Expand Up @@ -596,24 +596,36 @@ Issue(gpuweb/gpuweb#296): Consider merging all read-only usages.
Textures may consist of separate [=mipmap levels=] and [=array layers=],
which can be used differently at any given time.
Each such <dfn dfn>subresource</dfn> is uniquely identified by a
[=texture=], [=mipmap level=], and
(for {{GPUTextureDimension/2d}} textures only) [=array layer=].
[=texture=], [=mipmap level=],
(for {{GPUTextureDimension/2d}} textures only) [=array layer=],
and [=aspect=].

The **main usage rule** is that any [=subresource=]
at any given time can only be in either:
<dfn dfn>atom resource</dfn> means a whole buffer or a single subresource of a texture.

The **main usage rule** is that any [=atom resource=]
at any given time within [=usage scope=] can only be in either:
- a combination of [=read-only usage=]s
- a single [=mutating usage=]

The only exception is that a combination of writeonly-storage-texture usages, or a combination
of storage-buffer usages upon the same [#atom resource#] in render pass is allowed.

Note that all invisible usages and overwritten usages should be counted, for example:
- a resource binding attached to a shader stage with visiblity none
Copy link
Contributor

Choose a reason for hiding this comment

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

we should talk about whether this makes any sense to allow at all, it's just a useless footgun

Copy link
Author

Choose a reason for hiding this comment

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

Agreed. We can discuss about this if needed.

- a resource binding attached to compute shader stage in render pass, or vice versa
- a collection of bindings are set by a bind group but being overwritten within current [=usage scope=]
- index or vertex buffer being overwritten within current [=usage scope=]
Copy link
Contributor

Choose a reason for hiding this comment

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

similarly here. "overwriting a vertex buffer" is confusing, since users may read this as the contents are overwritten, while you mean the bindings

Copy link
Author

Choose a reason for hiding this comment

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

Done


Enforcing this rule allows the API to limit when data races can occur
when working with memory. That property makes applications written against
WebGPU more likely to run without modification on different platforms.

Generally, when an implementation processes an operation that uses a [=subresource=]
Generally, when an implementation processes an operation that uses a [=atom resource=]
in a different way than its current usage allows, it schedules a transition of the resource
into the new state. In some cases, like within an open {{GPURenderPassEncoder}}, such a
transition is impossible due to the hardware limitations.
We define these places as <dfn dfn>usage scopes</dfn>:
each [=subresource=] must not change usage within the [=usage scope=].
each [=atom resource=] must not change usage within the [=usage scope=].

For example, binding the same buffer for {{GPUBufferUsage/STORAGE|GPUBufferUsage.STORAGE}} as well as for
{{GPUBufferUsage/VERTEX|GPUBufferUsage.VERTEX}} within the same {{GPURenderPassEncoder}} would put the encoder
Expand Down Expand Up @@ -648,18 +660,18 @@ Issue(gpuweb/gpuweb#514): Document read-only states for depth views.

### Synchronization ### {#programming-model-synchronization}

For each [=subresource=] of a [=physical resource=], its set of
For each [=atom resource=] of a [=physical resource=], its set of
[=usage flags=] is tracked on the [=Queue timeline=].
<dfn dfn>Usage flags</dfn> are {{GPUBufferUsage}} or {{GPUTextureUsage}} flags,
according to the type of the subresource.
according to the type of the [=atom resource=].

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

On the [=Queue timeline=], there is an ordered sequence of [=usage scopes=].
Each item on the timeline is contained within exactly one scope.
For the duration of each scope, the set of [=usage flags=] of any given
[=subresource=] is constant.
A [=subresource=] may transition to new usages
[=atom resource=] is constant.
A [=atom resource=] may transition to new usages
at the boundaries between [=usage scope=]s.

This specification defines the following [=usage scopes=]:
Expand All @@ -676,7 +688,7 @@ regardless of whether the indexed draw calls are used afterwards.

The [=usage scopes=] are validated at {{GPUCommandEncoder/finish()|GPUCommandEncoder.finish}} time.
The implementation performs the <dfn dfn>usage scope validation</dfn> by composing
the set of all [=usage flags=] of each [=subresource=] used in the [=usage scope=].
the set of all [=usage flags=] of each [=atom resource=] used in the [=usage scope=].
A {{GPUValidationError}} is generated in the current scope with an appropriate error message
if that union contains a [=mutating usage=] combined with any other usage.

Expand Down Expand Up @@ -1682,7 +1694,7 @@ interface GPUMapMode {

Issue: define <dfn dfn>texture</dfn> (internal object)

Issue: define <dfn dfn>mipmap level</dfn>, <dfn dfn>array layer</dfn>, <dfn dfn>slice</dfn> (concepts)
Issue: define <dfn dfn>mipmap level</dfn>, <dfn dfn>array layer</dfn>, <dfn dfn>aspect</dfn>, <dfn dfn>slice</dfn> (concepts)

## <dfn interface>GPUTexture</dfn> ## {#texture-interface}

Expand Down