I agree, I'm saying we would do a memcpy from the mapped range to the IPC shmem, which would be two different buffers.
glMapBufferRange returns a memory pointer you can treat as usual memory into the buffer. IPC Memory sharing in any of its flavors requires you to use some functionality to specially allocate that memory (mmat, shmat, etc.). That means that you can never have a mapped buffer range and an IPC shared memory pointing to the same location. There are some workarounds you can try, but they will not work (no shared memory is established, some of the functions crap out with an error code, or segfault).I don't see fundamentally why it shouldn't work, because all of these just use the memory manager to do their bidding. It just seems to be the case that each implementor of the respective functions never thought of a case where they might be used in conjunction.On Fri, Dec 22, 2017 at 7:49 PM, Kai Ninomiya <firstname.lastname@example.org> wrote: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.
Description: S/MIME Cryptographic Signature