4 ms·

This sounds pretty great. This technique would be really powerful if the worker thread could pass a buffer of the rendered results off to the main thread effic

This sounds pretty great. 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. For example, a game has a worker thread to refine lightmaps while the main thread uses those lightmaps for rendering the game (similar to http://madebyevan.com/shaders/lightmap/ http://madebyevan.com/shaders/lightmap/). Does anyone know if this is possible? 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?

ndesaulniers 11y ago
> 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 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?
- 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 ago
      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.
- Sanddancer 11y ago
  > Isn't that the case for all applications? On OpenGL. Since Windows 8, MS has had preemptive multitasking in their driver scheduling model for GPU usage.
  - ndesaulniers 11y ago
    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?
    - derefr 11y ago
      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.
      - ndesaulniers 11y ago
        > 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).
        derefr 11y ago
        "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.

ndesaulniers 11y ago

> 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 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?

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 ago
    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.
Sanddancer 11y ago
> Isn't that the case for all applications? On OpenGL. Since Windows 8, MS has had preemptive multitasking in their driver scheduling model for GPU usage.
- ndesaulniers 11y ago
  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?
  - derefr 11y ago
    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.
    - ndesaulniers 11y ago
      > 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).
      - derefr 11y ago
        "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.