4 ms·
> Threads won't be able to share FBO's or VBO's, but we're working on SharredArrayBuffer, which will allow multiple threads to share data (more like C style arr
by constexpr 11y ago
> Threads won't be able to share FBO's or VBO's, but we're working on SharredArrayBuffer, which will allow multiple threads to share data (more like C style arrays than JS style lists, they still would have to be glBufferData'd to VRAM from RAM).
It would be amazing to have fast GPU-GPU transfer. Is it the case in Firefox that using texImage2D/texSubImage2D on a main thread context with a worker <canvas> will result in a guaranteed GPU-GPU transfer? Or does that download the pixels to the CPU and re-upload them?
> Isn't that the case for all applications?
Yes, but I haven't been following GPU tech recently so I wasn't sure if that still applies universally. Maybe some day we'll get preemptive multitasking on GPUs :)
- ndesaulniers 11y ago> It would be amazing to have fast GPU-GPU transfer. Is it the case in Firefox that using texImage2D/texSubImage2D on a main thread context with a worker <canvas> will result in a guaranteed GPU-GPU transfer? Or does that download the pixels to the CPU and re-upload them? I didn't write the patch, but let me ask who did.
- jdashg 11y agotexImage(canvas) isn't gpu->gpu yet. texImage(video) is the only gpu->gpu right now. Because of the shape of the API though (support for arbitrary unpack format/type requests), depending on the underlying pixel formats, gpu->gpu blit isn't guaranteed. We're looking into ways to provide a reliable fast-path.