Re: NXT design for memory barriers and buffer mapping.

Hi Corentin,

As promised on the call, here is some feedback. This is only about memory
barriers.

> Image swizzling and transitions between different types of swizzling.

I'm confused why you call them "swizzling". Swizzling is changing order of
elements in a vector.
Resource transitions can imply many things, but I don't think swizzling is
involved, unless you meant some broader sense of the word?

> Each command has an immediate version as well as a buffered version.

Having two different ways to transition resources feels redundant and
confusing to me.
As a user (or better, code reviewer), how do I reason about the code? Say,
I want to know what a resource state is at some point of the execution.
Somehow, not only I need to be aware of all the associated transitions in
the command buffers that are executing or executed (this is what
Vulkan/D3D12 do, anyway), but I also have to consider all the "buffered"
transitions. These are especially hard, given that they can happen in one
of the 3 mentioned spots (instantly, at the end of some command buffer, at
some queue submission).

The outcome would be users calling transitions "just in case, to be sure"
for everything they do, effectively questioning if they should be
responsible for transitions in the first place (basically, proving the
Apple's position). And on the other hand, if it *is* clear for the user
what is the resource state at some particular point, then they should have
no trouble specifying it in the API (encoding the assumption without
guessing), like what they do on Vulkan/D3D12 today.

> No usage transition can happen in a render pass

This restriction, combined with a single mutable state allowed for a
resource, would prevent a case like this:
  subpass A: write to UAV buffer
  subpass B: uses it as an index/vertex buffer for one of the calls
  dependency: A -> B

> If WebGPU has Vulkan style tile control, usage transitions inside render
passes won’t be possible because they semantically apply instantly.

I don't understand this part. Could you elaborate?

> Vulkan-style memory barriers without validation
> Would be expensive to add back validation.

I could argue that adding validation is easier than inferring the
transitions in the first place. I'll work on a concrete algorithmic
proposal to track resource transitions in order to support that hypothesis.

> Implicit memory barriers (like Metal)
> Arguably no simpler than what’s presented here

Hmm, I disagree. It is much simpler when API exposes no concept of
transitions.

> Implementation overhead increases a lot on D3D12 and Vulkan

I wish we had any quantitative metric to support that.

Cheers,
Dzmitry

On Tue, Nov 14, 2017 at 11:51 PM, Corentin Wallez <cwallez@google.com>
wrote:

> Hey all,
>
> We wrote some document to help everyone reason about NXT's proposals for
> memory barriers and resource upload /download. Unfortunately we still don't
> have a fleshed out proposal that minimizes the number of copies on UMA.
> Instead the docs focus on explaining our current design for resource
> upload/download and for memory barriers since they are very tied.
> Eventually we'll have these docs in MarkDown in some repo, either WebGPU's
> or NXT's.
>
>    - NXT "memory barriers"
>    <https://docs.google.com/document/d/1k7lPmxP7M7MMQR4g210lNC5TPwmXCMLgKOQWNiuJxzA>
>    <- Please read this first as buffer mapping depends on it.
>    - NXT buffer mapping
>    <https://docs.google.com/document/d/1HFzMMvDGHFtTgjNT0j-0SQ1fNU9R7woZ4JuNJdAXBjg>
>
> Cheers,
>
> Corentin
>