Re: RFC: Features to cull for MVP / v1

Agreed that we shouldn't remove these features forever and will want to
reconsider after the MVP.

Dzmitry: Note that multiple queues were not listed :) We should revisit the
multiple queues topic in conjunction with the synchronization / memory
barrier topic as it extremely tied together.

On Mon, Aug 21, 2017 at 2:37 PM, Myles C. Maxfield <mmaxfield@apple.com>
wrote:

> These look good to us too.
>
> I wanted to reiterate a point previously made: these don’t need to be part
> of the MVP, but one day I fully expect that we will tackle some subset of
> these. So we shouldn’t totally 100% ignore them; just defer them (some
> perhaps permanently).
>
>
> On Aug 18, 2017, at 11:52 AM, Ben Constable <bencon@microsoft.com> wrote:
>
> I agree that these should be out of scope for an MVP.
>
> *From:* Kirill Dmitrenko [mailto:dmikis@yandex-team.ru
> <dmikis@yandex-team.ru>]
> *Sent:* Friday, August 18, 2017 5:41 AM
> *To:* Corentin Wallez <cwallez@google.com>
> *Cc:* public-gpu@w3.org
> *Subject:* Re: RFC: Features to cull for MVP / v1
>
> Seems OK to me.
>
> If we're talking about web apps, those features aren't available to them
> anyway. So their lack in the first version won't block early adoption of
> the API as another rendering backend for existing WebGL apps and libs.
>
> 15.08.2017, 23:23, "Corentin Wallez" <cwallez@google.com>:
>
> Hey all,
>
> There are a number of feature of native API that seem like they could be
> culled, at least from the MVP and v1 of WebGPU, which would help make the
> API surface smaller and easier to specify.
>
> *Transform feedback / Stream-out*: in most cases it could be replaced by
> compute kernels or code in the VS that writes to a buffer. Also based on
> our experience with WebGL 2, it looks extremely hard to specify this
> tightly and test all corner cases.
>
> *Sparse resources: *it is a very useful feature for high-end applications
> but also somewhat new, it would be hard to specify in a reproducible manner
> and the security implications are unclear. Also as far as I can tell Metal
> doesn't have sparse resources.
>
> *Tessellation: *Metal handles it very differently from D3D12 and Vulkan
> so we'd need a lot of studying to make a portable version of it. That's why
> I think it shouldn't be in the MVP, and maybe only as a v2 / extension on
> v1.
>
> *Predicated rendering: *Metal doesn't have it.
>
> What do you think?
>
> Cheers,
>
> Corentin
>
>
>
> --
> Kirill Dmitrenko
> Yandex Maps Team
>
>
>