[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: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.


2) It still requires allocation of an object (a WebGLSync) -- no way around that.
It's why I suggested a query like semantic because they can be pre-allocated. Usually (because they're integers) you can keep a ring-buffer of integers (something that makes WebAssembly/asm.js/emscripten folks very happy).

I see. I've updated http://crbug.com/770381 . It sounded like there was no strong feeling against using sync objects, and they would have a cleaner semantic, but we'll give this more thought.

-Ken