New issue
Advanced search Search tips

Issue 770381 link

Starred by 2 users
Status: WontFix
Owner:
kainino@chromium.org
Closed: Apr 2018
Cc:
kainino@chromium.org
zmo@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Feature

Blocked on:
issue 616554
Blocking:
issue 785415
issue 828135



Sign in to add a comment

Update WEBGL_get_buffer_sub_data_async prototype to new proposal

Project Member Reported by kbr@chromium.org, Sep 29 2017 
Back in February when WEBGL_get_buffer_sub_data_async was discussed on the public mailing list, there were concerns about phrasing the API in terms of Promises. There was a suggestion to implement the API with more C-like semantics here:

https://www.khronos.org/webgl/public-mailing-list/public_webgl/1702/msg00002.php

The basic idea is that getBufferSubDataAsync would return immediately, with a void return value. The app would have to call gl.fenceSync(gl.SYNC_GPU_COMMANDS_COMPLETE) and poll that fence at the beginning of each requestAnimationFrame callback using gl.getSyncParameter(sync, gl.SYNC_STATUS). Once it returns gl.SIGNALED then the data can be consumed.

See these two thread lists for the bulk of the conversation to date:
https://www.khronos.org/webgl/public-mailing-list/public_webgl/1702/threads.php
https://www.khronos.org/webgl/public-mailing-list/public_webgl/1709/threads.php

We should consider making this change. It would be more compatible with Emscripten use cases, for example.

Comment 1 by kbr@chromium.org, Sep 29 2017

Summary: Consider prototyping WEBGL_get_buffer_sub_data_async using sync objects or queries rather than promises (was: Consider prototyping WEBGL_get_buffer_sub_data_async using sync objects rather than promises)
After more discussion, an earlier suggestion was revisited, namely using query objects. The advantage of using a query object is that they can be preallocated. This suggestion was detailed here:

https://www.khronos.org/webgl/public-mailing-list/public_webgl/1702/msg00000.php

It sounds like there was no strong feeling about using queries rather than sync objects. Sync objects would have a cleaner semantic.

Comment 2 by kbr@chromium.org, Sep 29 2017

Blockedon: 616554

Comment 3 by kainino@chromium.org, Nov 15 2017

Blocking: 785415

Comment 4 by kainino@chromium.org, Nov 15 2017

Owner: kainino@chromium.org
Status: Assigned (was: Available)
Summary: Update WEBGL_get_buffer_sub_data_async prototype to new proposal (was: Consider prototyping WEBGL_get_buffer_sub_data_async using sync objects or queries rather than promises)
I've been working on a new proposal for WEBGL_get_buffer_sub_data_async in the WebGL WG. This issue is really to update our prototype and prove out the implementation.

Comment 5 by kainino@chromium.org, Apr 2 2018

Status: Started (was: Assigned)
Summary: WebGL asynchronous readback implementation (was: Update WEBGL_get_buffer_sub_data_async prototype to new proposal)
The WEBGL_get_buffer_sub_data_async proposal has been rejected in favor of implementation changes to allow asynchronous readback using the synchronous primitives + fences.

https://www.khronos.org/webgl/public-mailing-list/public_webgl/1712/msg00009.php
https://github.com/jdashg/misc/blob/master/remoted-readback.md

I'm working on that implementation now.

* Remove old prototype code
* Make fences asynchronous (no round trip) similar to the way queries work
* Maintain a shadow copy of buffers allocated with GL_*_READ usage, update it according to Jeff's proposal, use it for readbacks
* WebGL CTS tests if possible (gl_tests if not)
* Spec addition (may have to be non-normative)

Comment 6 by kainino@chromium.org, Apr 2 2018

Status: WontFix (was: Started)
Summary: Update WEBGL_get_buffer_sub_data_async prototype to new proposal (was: WebGL asynchronous readback implementation)
Actually I should make a new bug for this.

Comment 7 by kainino@chromium.org, Apr 2 2018

Blocking: 828135
►

Sign in to add a comment