[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WEBGL_get_buffer_sub_data_async



With the mechanisms we already have in WebGL 2[1], we can support
no-stall polled-async readback from the GPU. Even in the case of
poorly written content, this cannot incur any worse of pipeline stalls
than we already allow for in WebGL via non-PBO ReadPixels and
getBufferSubData. Note also that checking for stall-less behavior is
fairly (though not entirely) deterministic, since apps must explicitly
poll/wait on a fence before accessing the potentially-in-flight data.
This is what I am implementing in Firefox, since it applies to all
implementations, regardless of whether the implementation remotes
calls.

The key to this is the understanding that buffers with usage=GL_*_READ
are directly mappable client-side buffers, into which (primarily)
copyBufferSubData and readPixels enqueue writes. After the writes are
known to be complete (via FenceSync(GPU_COMMANDS_COMPLETE)), since
these are client-side buffers, they may be immediately mapped and read
from.

I do think there is room for a more ergonomic helper for handling this
behavior, though it's not that complicated for a library to implement
it.

There is room to investigate a solution to eliminating a copy.
MapBufferRange does this, but the naive implementation does create
garbage ArrayBuffer wrappers. Note however, that if you want to copy
the data into some existing ArrayBuffer (like the wasm heap),
getBufferSubData is already copy-optimal. There is only room for
improvement if you want to process the data in-place, which may be
able to save a copy with MapBufferRange or similar in both types of
implementation.

[1]: Since this is only available in WebGL 2, I have proposed
extensions to expose these mechanisms from WebGL 2 to WebGL 1:
https://github.com/KhronosGroup/WebGL/pull/2563

On Wed, Dec 20, 2017 at 11:06 AM, Kai Ninomiya <kainino@google.com> wrote:
> Good point Mark, I'll add that.
>
>
> On Wed, Dec 20, 2017, 10:57 AM Mark Callow <khronos@callow.im> wrote:
>>
>>
>>
>> On Dec 19, 2017, at 17:38, Kai Ninomiya <kainino@google.com> wrote:
>>
>> All,
>>
>> Our new proposal for WEBGL_get_buffer_sub_data_async is finally ready.
>> Please take a look and send along your comments and suggestions. Feel free
>> to request comment access if you want to comment on the doc itself.
>>
>> Note this is a design doc and not a spec, so it will hopefully be easier
>> to read but may not be explicit about every edge case yet.
>>
>> https://docs.google.com/document/d/1f65cGlfLHbKLOuvRSqTvrakNi60Swk6GCyS54v1ImKo/edit?usp=sharing
>>
>>
>> This doc should mention the core reason for this extension: the inability
>> of some WebGL implementations to support glMapBufferRange. And describe how
>> that led to gl.getBufferSubData() and then this proposal. As far as I can
>> see all the use cases listed would be solved if glMapBufferRange was
>> supported.
>>
>> Regards
>>
>>
>>     -Mark

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------