[Public WebGL] Re: WEBGL_get_buffer_sub_data_async

Maksims Mihejevs [email protected]
Fri Jan 6 04:52:54 PST 2017


Why not to use classic callbacks with (err, response) arguments?

On 6 January 2017 at 00:01, Kenneth Russell <[email protected]> wrote:

> On Thu, Jan 5, 2017 at 2:55 AM, Maksims Mihejevs <[email protected]>
> wrote:
>
>> Thank you for answer, this examples make sense.
>>
>> The only concern as mentioned before are: Promises. There is no a single
>> use of promises in WebGL, and there is a reason why they should not be used
>> in real-time applications if they can be avoided (which is the case).
>>
>> If possible Fence (Sync Objects) were involved in design process? Could
>> something like this be achieved by using more generic functionality in GL
>> such as Sync Objects?
>>
>
> Promises were chosen for a particular reason. Even if a primitive like
> mapBufferRange were exposed in WebGL, a typed array would still need to be
> allocated as the return result. There's no provision in the ECMAScript
> specification for "re-pointing" a typed array at a new backing store,
> although Chrome's V8 team proposed this a while back. Mapping a buffer's
> range at the OpenGL ES level returns a void*, and that would need to be
> exposed to ECMAScript. Passing in an already-allocated typed array wouldn't
> work in the current form of the APIs.
>
> Given that an allocation would be needed anyway, returning a Promise is
> much more web-friendly. It avoids the need for the application to deal with
> sync objects, and potentially inconsistent states of the returned typed
> array. getBufferSubDataAsync lets the application specify where it wants
> the returned data to be copied.
>
> -Ken
>
>
>
>> Kind Regards,
>> Max
>>
>> On 4 January 2017 at 18:55, 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/20170106/1ee61c68/attachment.html>


More information about the public_webgl mailing list