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

Re: [Public WebGL] Re: WEBGL_get_buffer_sub_data_async



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.