- From: Kirill Dmitrenko <dmikis@yandex-team.ru>
- Date: Wed, 31 Jan 2018 22:58:15 +0300
- To: Corentin Wallez <cwallez@google.com>, Dzmitry Malyshau <dmalyshau@mozilla.com>
- Cc: Kenneth Russell <kbr@google.com>, public-gpu <public-gpu@w3.org>
When promise-based interface was proposed to the WebGL community, there're some concerns about generating garbage (thread: https://www.khronos.org/webgl/public-mailing-list/public_webgl/1701/msg00001.php). However, maybe those concerns need some qualitative analysis. 25.01.2018, 22:01, "Corentin Wallez" <cwallez@google.com>: > On Wed, Jan 24, 2018 at 9:41 PM, Dzmitry Malyshau <dmalyshau@mozilla.com> wrote: >> === Shape of the API for data transfers === >> >> One of the benefits of having poll-like interface (with fences or something similar) is that it maps cleanly to C and thus maps perfectly to WASM. >> If we choose to have promises instead, how would they be accessible from WASM? I don't see anything immediately related in the Host Bindings Proposal. > > I assume you meant the WASM Host Bindings Proposal. I'm not sure about direct bindings to promises but implementing a poll-like interface on top of a promise interface would be easy to do with a shim. That said I agree that it isn't clear how to make it work with minimal overhead in WASM. Something important for Chrome is that the range of data that will be accessed be explicit, because otherwise we would have to send all of the buffer's content through the GPU command buffer. It's easy to see how a promise interface could have explicit bounds, but it is less clear how to do it with a poll API. -- Kirill Dmitrenko Yandex Maps Team
Received on Wednesday, 31 January 2018 19:59:12 UTC