Re: NXT design for memory barriers and buffer mapping.

Hey Markus,

This is correct, NXT defers building the native API command buffer until
queue submit. There are pros and cons to it. Examples pros are being able
to work around more bugs, and have more flexibility in the implementation,
cons that it could increase latency (for VR).

Cheers,

Corentin

On Fri, Nov 17, 2017 at 11:15 AM, Markus Siglreithmaier <
m.siglreith@gmail.com> wrote:

> Hi,
>
> I'm having a small question regarding the implementation of memory
> barriers. In the proposal the previous resources states (D3D12) or access
> masks (Vulkan)  are unknown at command buffer recording time and only known
> on actual queue submission if I understand it correctly. Would this require
> then to cache all commands internally and defer the actual command buffer
> calls until queue submission?
>
> Cheers,
> Markus
>
> Am 15.11.2017 um 05:51 schrieb Corentin Wallez:
>
> 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
>
>
>