"Dynamic buffer data is typically written by the CPU and read by the GPU. An access conflict occurs if these operations happen at the same time; [...] For the processors to work in parallel, the CPU should be working at least one frame ahead of the GPU. This solution requires multiple instances of dynamic buffer data"
It's still zero copy, but they're not literally peeking and poking the same buffer at the same time.
So WebGL "just" needs to offer zero-copy access to buffers from JavaScript. That seems at least possible...? TypedArray would be the key component, and that already exists. Whether all those pieces have been put together in the right order yet, I dunno.
Anyway, low-overhead access to the GPU from JavaScript seems possible in principle.
Hmm, looking at the Metal docs, that's not quite how I read it!
Here's Apple's "best practices" doc (https://developer.apple.com/library/content/documentation/3D...):
"Dynamic buffer data is typically written by the CPU and read by the GPU. An access conflict occurs if these operations happen at the same time; [...] For the processors to work in parallel, the CPU should be working at least one frame ahead of the GPU. This solution requires multiple instances of dynamic buffer data"
It's still zero copy, but they're not literally peeking and poking the same buffer at the same time.
So WebGL "just" needs to offer zero-copy access to buffers from JavaScript. That seems at least possible...? TypedArray would be the key component, and that already exists. Whether all those pieces have been put together in the right order yet, I dunno.
Anyway, low-overhead access to the GPU from JavaScript seems possible in principle.