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

Re: [Public WebGL] Re: WEBGL_get_buffer_sub_data_async

On Fri, Sep 29, 2017 at 3:56 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Sat, Sep 30, 2017 at 12:49 AM, Kenneth Russell <kbr@google.com> wrote:
On Fri, Sep 29, 2017 at 3:36 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Sat, Sep 30, 2017 at 12:25 AM, Kenneth Russell <kbr@google.com> wrote:
1) The browser guarantees that the Promises resolve in order, and that even if all the Promises use the same ArrayBufferView, inside the promise's resolve callback, the data is the correct value with respect to the OpenGL command stream at the time that iteration of getBufferSubDataAsync was called. Multiple frames can be queued up without needing separate destination ArrayBufferViews. The polling-based API requires a new ArrayBufferView for each readback, if the application expects to have multiple frames in flight.
That sounds implausible to me. Underneath chrome would use mapbuffer and fences to implement the required functionality (if it doesn't it has no synchronization i.e. couldn't call back a promise, or would be mapbuffer synced), which afaik does not guarantee client memory not to be overwritten by a subsequent comment in the stream once the fence signals for a previous one.

The memory copy from shared memory between the renderer and GPU processes into the client's ArrayBufferView happens just before the Promise is going to be resolved. We have tested this thoroughly and talked with the implementers of Promises in Chrome. It is guaranteed to work.

The transfer of data from the GPU to client memory happens as a DMA, the fence just makes the guarantee about the GPU-side command buffer having reached at least that point in execution, it does not guarantee the GPUs command buffer (and hence DMA) hasn't exceeded that fence. Memory that's reused in subsequent invocations of asynchronous read map buffers isn't guaranteed to be coherent.

Different regions of shared memory between Chrome's renderer and GPU processes are used if there are multiple pipelined calls to getBufferSubDataAsync. From the standpoint of _javascript_, however, all of the invariants are maintained to allow reuse of the same ArrayBufferView for multiple pipelined requests to the API, since a copy is made from shared memory to that client buffer, and the Promise is resolved immediately afterward with no yielding to the event loop.

The implementing code is available for study at http://crbug.com/616554 .