[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL2 and no mapBuffer/mapBufferRange
I've thought about this problem a bit, and I think the IPC JS-thread <-> GPU process and it being blocking is very similar to the issue of client <-> GPU being blocking. In both instances a call (buffer[Sub]Data) blocks because the action needs to complete in order to ensure all bytes are transferred before the client gets a chance to deallocate/change the data at that memory address.
I think it's clear that non blocking buffer transfers are a desirable functionality, no matter if they're from the JS-thread or from the GPU-process. The GPU process itself has for this very reason the ability to use address space mapping and defer the work (to shuffle the bytes to where they need to go) to the virtual memory manager.
This option is not open to the JS-thread <-> GPU-process interaction in this case. Although it would be possible to establish a shared memory region between a tabs process and the GPU-process and so achieve a non-blocking transfer, it is not possible to have that region also be at the address location that a glMapBuffer[Range] returns.
Nevertheless it is possible to achieve a similar functionality in the JS-thread <-> GPU-process interaction because the mechanism does not need to be tied to the virtual memory manager. Essentially the mechanism would just need to ensure that the bytes are transferred eventually at its convenience, and before gl.unmapBuffer is called.
The mechanism by which a non blocking transfer can happen between the JS-thread and the GPU-process could be either:
- A transfer thread that picks up reads/writes while JS executes and starts shuffling bytes around as they arrive
- For next-frame semantics transfers can be initiated after JS has executed.
Both cases would allow the JS-thread to perform computing intensive tasks or emit further rendering commands while a transfer of the data happens in the background.
And so the benefit of non-blocking buffer transfer could be transported to JS, even though it does involve copying data between the JS-thread and GPU-process.