Re: RFC: Features to cull for MVP / v1

Corentin,

These all look reasonable to me for exclusion from MVP scope.

It would also be great if we can reach the consensus on the multiple queues
and their types for MVP.
Mozilla's position is that getting the design right for multiple queues
(especially with regards to synchronization) is essential from the start.
Supporting different queue types may not seem like a requirement for MVP,
but it would be useful given how much hardware out there supporting one
universal + a few compute queues.

Regards,
Dzmitry

On Tue, Aug 15, 2017 at 4:22 PM, Corentin Wallez <cwallez@google.com> wrote:

> 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
>