[Public WebGL] Re: WEBGL_get_buffer_sub_data_async
Wed Jan 4 10:55:04 PST 2017
In my demo  there are 3 different possible readback paths:
* readPixels to CPU 
* readPixels to PBO + getBufferSubData 
* readPixels to PBO + getBufferSubDataAsync 
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).
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:
> 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.
> On Mon, Jan 2, 2017 at 2:27 PM, Maksims Mihejevs <[email protected]>
> 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
> 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
> 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4845 bytes
Desc: S/MIME Cryptographic Signature
More information about the public_webgl