We discussed this before at #769 and #657. PTAL. Thanks!

We have different opinions, but I really appreciate your review, @kvark . 👍

OK. To summarize the discussions above, it looks like there are 3 issues to address for resource usage tracking and validation . The latter two issues should be not that controversial though, and I'd like to propose a solution:

1. We claimed that multiple instances of a single [=mutating usage=] is valid. However, looks like that race condition upon storage buffer/texture in render pass is valid. What about in compute pass? What about race condition upon the same render target (multiple color attachments with the same texture view)?
2. Do we need to track those resource usages with invisible bindings and/or being replaced by another setBindGroup/setVertexBuffer/setIndexBuffer before issuing any draw/dispatch. I tend to do so because filtering those unused bindings and not track them is expensive from the perspective of implementation. And the validation failure can remind WebGPU devs to remove those useless code.
3. In addition to mip level and array layer, can we add aspect (dpeht/stencil) as another factor to define different texture subresource when we do resource usages tracking and validation? This means we can track depth and stencil aspect separately. I tend to do so because this is aligned with native graphics like D3D12 and Vulkan from 2 perspectives: 1) texture subresource definition, 2) resource usage tracking via barriers. But I am not sure about the situation in Metal.

Alternatively, we can leave any one of these 3 issues being open before MVP/v1 and discuss them after MVP/v1 if you think it is a corner case.

What about in compute pass?

A whole render pass is a usage scope, but not a whole compute pass. In compute, just a single dispatch is a usage scope; we insert necessary synchronization between dispatches.

Do we need to track those resource usages with invisible bindings and/or being replaced by another setBindGroup/setVertexBuffer/setIndexBuffer before issuing any draw/dispatch.

IMHO yes, it adds implementation complexity to skip unused bindings, and doesn't provide value except for badly behaved applications.

In addition to mip level and array layer, can we add aspect (dpeht/stencil) as another factor to define different texture subresource when we do resource usages tracking and validation?

Probably, even though right now WebGPU doesn't support any usecase where depth and stencil would have different usages. (read only depth or stencil has to match because of Vulkan 1.0/1.1 limitations)

What about in compute pass?

A whole render pass is a usage scope, but not a whole compute pass. In compute, just a single dispatch is a usage scope; we insert necessary synchronization between dispatches.

Yeah. I meant to say compute scope (per each dispatch call).

That means a resource is used twice in the same dispatch, and that's not any worse than using the resource once in the dispatch (since it can already be written from multiple threads of the dispatch).

@Richard-Yunchao sorry about the lack of clarity on what is expected here.

Would you mind removing the "atom" related naming changes from this PR, only leaving the following points in it:

• add aspect (in addition to array layer and mip level) for subresource
• race condition of writable storage buffer/texture in render pass is allowed
• invisible usages and overwritten usages should be tracked

The synchronization scopes are being clarified in #994 in the meantime. Please free to review it and/or follow-up with better description of what's going on.

Done, with one minor change that combine two readonly usages you added at #994 into one. Sorry for the late response, @kvark.

Discussed at the 2020-08-24 meeting.

Addressed feedback from CG meeting and spec editors' meeting on Monday. PTAL. Thank you!