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

Re: [Public WebGL] Re: WEBGL_get_buffer_sub_data_async



Kai's written a nice design doc of the various options which is complete and has already been vetted within the working group. He and Corentin are cranking on some work for early next week, but expect to see it mid-next week. It addresses all of the concerns which have been raised.

-Ken


On Thu, Nov 2, 2017 at 3:38 AM, Florian Bösch <[email protected]> wrote:
Is there any progress on clearing the form of the API for asm.js/web-assembly users? I (and as Kenneth mentioned) many others could make good use of the functionality.

On Sat, Sep 30, 2017 at 7:24 PM, Florian Bösch <[email protected]> wrote:
Right, but this is a little weird. So basically it means you're allocating a memory region for use by the async readback upon every invocation. It's usually not a problem, but if you have a pipeline stall you could end up with hundreds of allocated buffers waiting for the GPU to catch up.

The way that's usually done by graphics programmers is to pre-allocate a limited number of such buffers (like 3) and when you're 3 buffers deep and the first not resolved, you don't emit more readbacks. You could emulate that behavior with the async readback extension, but you have to be aware that you have to, and the memory cost is hidden from you.

On Sat, Sep 30, 2017 at 7:04 PM, Kenneth Russell <[email protected]> wrote:
On Sat, Sep 30, 2017 at 5:12 AM, Florian Bösch <[email protected]> wrote:
On Sat, Sep 30, 2017 at 1:17 AM, Kenneth Russell <[email protected]> wrote:
Different regions of shared memory between Chrome's renderer and GPU processes are used if there are multiple pipelined calls to getBufferSubDataAsync.
Effectively a readback buffer cache. How do you know when you can discard those copies you keep around?

As soon as the data is copied out into the client's ArrayBufferView, just before resolving the Promise.