RE: RFC: Features to cull for MVP / v1

I agree that these should be out of scope for an MVP.

From: Kirill Dmitrenko [mailto: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<mailto: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