4 ms·

noooooo It's seriously like the web folks are discovering all of the sad mistakes we ran into in native graphics like a decade ago. Threading in OpenGL is sub

noooooo It's seriously like the web folks are discovering all of the sad mistakes we ran into in native graphics like a decade ago. Threading in OpenGL is subgood--you have to be fairly clever (and lucky with drivers) to do anything useful.

flohofwoe 12y ago
This solution isn't talking to GL from different threads, instead it builds a command list on one thread, for the 'render thread' (here: actually the main thread) to consume. Only one thread creates and talks to the GL context.
- angersock 12y ago
  Correct, which is exactly what's wrong with it. Having a dedicated thread for rendering isn't bad, but using the (already likely overloaded) main event thread for a website instead of being able to spawn a dedicated WebGL thread is bad--being unable to easily handle image loading and shader compilation and whatnot is worse. Also, WebGL could've finally fixed the broken shader compilation model on GL, but didn't--why do we still have to compile shaders every time?
  - flohofwoe 12y ago
    I think whether this is good or bad actually depends on the WebGL implementation. In Chrome for instance, the actual GL rendering already happens in a separate process, and the main thread only writes to a command buffer, which is already as cheap as it gets (but may increase latency). As for the shader compilation, I guess there's just as many argument for as against a DirectX-style byte code model, and the situation in the GL world is more complicated because GPU vendors have more freedom (to introduce their own GLSL extensions for instance). GL implementations already do a lot of under-the-hood magic to hide the parsing and compilation overhead, like caching compiled shaders, deferring shader compilation, and compiling shaders in a separate thread (not necessarily WebGL implementations, but they're free to). I'm not saying this is perfect, or preferable over a byte code model, but it's not 'broken'.

flohofwoe 12y ago

This solution isn't talking to GL from different threads, instead it builds a command list on one thread, for the 'render thread' (here: actually the main thread) to consume. Only one thread creates and talks to the GL context.

angersock 12y ago
Correct, which is exactly what's wrong with it. Having a dedicated thread for rendering isn't bad, but using the (already likely overloaded) main event thread for a website instead of being able to spawn a dedicated WebGL thread is bad--being unable to easily handle image loading and shader compilation and whatnot is worse. Also, WebGL could've finally fixed the broken shader compilation model on GL, but didn't--why do we still have to compile shaders every time?
- flohofwoe 12y ago
  I think whether this is good or bad actually depends on the WebGL implementation. In Chrome for instance, the actual GL rendering already happens in a separate process, and the main thread only writes to a command buffer, which is already as cheap as it gets (but may increase latency). As for the shader compilation, I guess there's just as many argument for as against a DirectX-style byte code model, and the situation in the GL world is more complicated because GPU vendors have more freedom (to introduce their own GLSL extensions for instance). GL implementations already do a lot of under-the-hood magic to hide the parsing and compilation overhead, like caching compiled shaders, deferring shader compilation, and compiling shaders in a separate thread (not necessarily WebGL implementations, but they're free to). I'm not saying this is perfect, or preferable over a byte code model, but it's not 'broken'.