[Public WebGL] Re: WEBGL_get_buffer_sub_data_async

Kenneth Russell [email protected]
Thu Jan 5 16:02:12 PST 2017

They're linked from http://crbug.com/616554 .


On Thu, Jan 5, 2017 at 8:33 AM, Florian Bösch <[email protected]> wrote:

> Could you link to the changesets that implement getBufferSubDataAsync in
> google chrome?
> On Wed, Jan 4, 2017 at 7:55 PM, Kai Ninomiya <[email protected]> wrote:
>> Max,
>> In my demo [1] there are 3 different possible readback paths:
>> * readPixels to CPU [2]
>> * readPixels to PBO + getBufferSubData [3]
>> * readPixels to PBO + getBufferSubDataAsync [4]
>> As you said, getBufferSubData(/Async) can be used for reading back any
>> buffer data (such as transform feedback or GPGPU shader results). PBO is
>> necessary (AFAIK) for async readback from framebuffer data (note: an async
>> readPixels wouldn't be as useful as it would block any operation which
>> writes to the framebuffer).
>> -Kai
>> [1] https://github.com/kainino0x/getBufferSubDataAsync-Demo/
>> [2] https://github.com/kainino0x/getBufferSubDataAsync-Demo/
>> blob/master/index.html#L245
>> [3] https://github.com/kainino0x/getBufferSubDataAsync-Demo/
>> blob/master/index.html#L261
>> [4] https://github.com/kainino0x/getBufferSubDataAsync-Demo/
>> blob/master/index.html#L280
>> On Wed, Jan 4, 2017 at 5:09 AM Maksims Mihejevs <[email protected]>
>> wrote:
>>> 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: https://www.khronos.o
>>> rg/registry/webgl/specs/latest/2.0/#4.2
>>> PBOs would allow to get render target data into buffers without stalling
>>> GPU pipeline, and then read them.
>>> How does getBufferSubDataAsync relates to PBOs?
>>> Cheers,
>>> Max
>>> 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/20170105/7379e58d/attachment.html>

More information about the public_webgl mailing list