> This technique would be really powerful if the worker thread could pass a buffer of the rendered results off to the main thread efficiently for use by the main thread.
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). See also: https://www.youtube.com/watch?v=XvoBR9K3ZmE
> Also, what does this mean for GPU use on the worker? Can heavy GPU use in the worker still lock up the GPU and impact the GPU use of the main thread and the windowing system in the OS?
> 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 :)
> 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?
texImage(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.
That's great! At the same time, it's unrealistic to expect 200% output from a gfx card. If one thread is maxing out the capability of the gfx card, operating at 100%, isn't it ridiculous to expect everything else to stay responsive? Can I have my cake and eat it, too?
I would think it's ridiculous to expect a thread to be able to grab 100% of the GPU, personally. If a game isn't fullscreen, I'm not prioritizing its framerate; it should (be forced to) play nice with my desktop.
> I would think it's ridiculous to expect a thread to be able to grab 100% of the GPU, personally.
Folks that spend big bucks on dedicated hardware might disagree.
> If a game isn't fullscreen, I'm not prioritizing its framerate; it should (be forced to) play nice with my desktop.
That's fair. That was also Microsoft's reason for not implementing WebGL for a long time, IIRC. "DoS." Thing is, either you want a thread to take everything (like when you play a game fullscreen), or you can just close a demanding application (or tab on a site with misbehaving/straining WebGL).
"You can just close a demanding application" assumes your system isn't crawling and unresponsive in a way that prevents you from finding the offender, though. As GPUs become increasingly utilized for not-graphics, we'll increasingly see badly-written programs doing synchronous waits on the results of GPGPU calculations, and thus increasingly see GPU hogs stalling the CPU threads (and thus the event loops) of those programs.
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). See also: https://www.youtube.com/watch?v=XvoBR9K3ZmE
> Also, what does this mean for GPU use on the worker? Can heavy GPU use in the worker still lock up the GPU and impact the GPU use of the main thread and the windowing system in the OS?
Isn't that the case for all applications?