[Public WebGL] Re: WEBGL_get_buffer_sub_data_async

Florian Bösch [email protected]
Thu Jan 5 08:33:18 PST 2017


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.org/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/eda8b330/attachment.html>


More information about the public_webgl mailing list