[Public WebGL] Re: WEBGL_get_buffer_sub_data_async

Kenneth Russell [email protected]
Tue Jan 3 21:27:54 PST 2017

Apologies for not discussing this extension on public_webgl before
introducing it as a draft in the WebGL extension registry.

The cost of synchronous glReadPixels has been a longstanding problem in
WebGL. The Chrome browser specifically has a particularly deep graphics
pipeline, and draining it with a synchronous call each frame imposes a
too-great performance penalty. This has forced applications to rewrite
certain algorithms when porting to WebGL.

getBufferSubDataAsync is a direct parallel to getBufferSubData, and solves
these performance pitfalls in Chrome. We've gathered data from two test
cases so far, a GPU-based picking algorithm and a GPGPU global illumination
algorithm, and the results look good. We will present this data on
public_webgl soon, when making a case for moving the extension forward.


On Mon, Jan 2, 2017 at 2:27 PM, Maksims Mihejevs <[email protected]> wrote:

> Worth mentioning that promises are extremely bad for GC and real-time
> applications, they do not provide a developer enough control to structure
> logic so to avoids any allocations.
> Promises - are not good for real-time at all, and lead to issues with GC.
> Any API in WebGL that is meant to be used in real-time applications should
> not be based on API's that are not real-time friendly.
> On 2 January 2017 at 20:49, Florian Bösch <[email protected]> wrote:
>> Upon thinking about this extension, I don't think it should exist at all.
>> Ideally the mapBuffer semantic would be exposed. But even if it isn't, it
>> shall not be that an extension is required to express functionality already
>> found in the core functionality of the underlying ES specification.
>> Furthermore, getBufferSubDataAsync does not adequately express the
>> reality of map/flush/unmap, and hides the fact that unmap/flush are still
>> synchronizing calls happening. However getBufferSubDataAsync obstructs
>> appropriate code dealing with proper insertion of synchronization points.
>> In addition, it would lead to allocating promises once or many times per
>> frame, and since tracking would be required in some instances, would also
>> lead to allocating a closure once or many times a call. An issue that map
>> buffer range does not exhibit.
>> Due to the lack of discussion of this feature, I believe a great
>> disservice is done to WebGL 2 by the introduction of these ideas/APIs and I
>> strongly suggest to withdraw this from draft immediately and go back to the
>> drawing board.
>> On Mon, Jan 2, 2017 at 5:48 PM, Florian Bösch <[email protected]> wrote:
>>> This extension https://www.khronos.org/registry/webgl/extensions/
>>> WEBGL_get_buffer_sub_data_async/ has been introduced and elevated to
>>> draft without any public discussion.
>>> In a nutshell it proposes a new WebGL2 function called
>>> getBufferSubDataAsync which returns a promise that will be called
>>> eventually with the buffer data.
>>> I think there are several problems:
>>>    1. The extension process states that "*Extensions move through four
>>>    states during their development: proposed, draft, community approved, and
>>>    Khronos ratified**"*. This extension never moved through the
>>>    proposal stage.
>>>    2. The extension introduces promises to the WebGL API. This requires
>>>    a more fundamental discussion.
>>>    3. A discussion if this extension is required if WebWorkers can
>>>    access the same context as the main thread has not happened.
>>> This extension should be in proposal status, and the necessary
>>> discussions should happen first.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170103/4b12b6c3/attachment.html>

More information about the public_webgl mailing list