Sorry, I think I spoke inaccurately. To clarify:Without special SABs, data is fetched the usual way with getBufferSubData, which does a memcpy from the the CPU-side shadow copy of the readback buffer into the ArrayBuffer. In multi-process, the shadow copy would be allocated in IPC shared memory. (2 copies for both single- and multi-process.)With the special mapped-buffer-SAB, the CPU-side shadow copy can actually be a SharedArrayBuffer. That SAB is fetched by gl.MapBuffer/Range. (1 copy for both single- and multi-process.) Note, the SAB is persistent, so it doesn't generate garbage. ArrayBufferView garbage might be generated in some cases by a MapBufferRange, but I think could be avoided with a MapBuffer.Finally, single-process browsers might be able to back the mapped-buffer-SAB with an actual glMapBufferRange pointer. (0 copies for single-process.) However, it's not clear yet how unmapping would behave with SABs - SABs cannot be neutered and their backing store cannot be swapped out.On Fri, Dec 22, 2017 at 4:31 AM Florian Bösch <email@example.com> wrote:On Thu, Dec 21, 2017 at 11:07 PM, Kai Ninomiya <firstname.lastname@example.org> wrote:* We should be able to eventually eliminate a memcpy by, in (a) multi-process browsers, using SharedArrayBuffers backed by IPC shared memory, and in (b) single-process browsers, using SharedArrayBuffers backed by glMapBuffer memory. It might essentially be exposed to WebGL like a read-only MapBuffer operation, maybe for GL_*_READ buffers only. Ideally in both cases, the SharedArrayBuffer would be read-only, which is not a concept that currently exists.Afaik you cannot simultaneously create IPC shared memory and have it be the memory region mapped by glMapBuffer.