[Public WebGL] Re: WEBGL_get_buffer_sub_data_async

Kai Ninomiya [email protected]
Wed Jan 4 10:55:04 PST 2017


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/20170104/46ad4958/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4845 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170104/46ad4958/attachment.p7s>


More information about the public_webgl mailing list