[Public WebGL] Re: WEBGL_get_buffer_sub_data_async

Maksims Mihejevs [email protected]
Wed Jan 4 05:07:52 PST 2017

>From PlayCanvas side, we express a need for async glReadPixels path too. We
and our users have been using it in many ways, some of the ways:
1. GPU picking: ID encoded in unique colour, reading pixel under mouse.
2. GPU screen to world: reading pixel from depth texture, and using frustum
with math reconstructing world position.
3. Render Target to another Canvas. In Editor we have thumbnail previews
for materials, models, cubemaps and other assets. We render them into
render target in main context and then reading pixels to create ImageData
so it can be put to another canvas using putImageData.
4. Some custom algorithms to generate large amounts of computation heavy
data saved into texture, then read on CPU - this depends per case.
Sometimes async approach is viable there, sometimes it is not.

In many cases glReadPixels is called per each frame, like for picking, and
easily can drop frame rate due to blocking nature.

I've noticed that PBOs are mentioned in WebGL 2.0 spec, but not much info
apart of just that mention:
PBOs would allow to get render target data into buffers without stalling
GPU pipeline, and then read them.

How does getBufferSubDataAsync relates to PBOs?


On 4 January 2017 at 05:27, Kenneth Russell <[email protected]> wrote:

> 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.
> -Ken
> 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/20170104/15b88197/attachment.html>

More information about the public_webgl mailing list