WebGL in Web Workers(blog.mozilla.org)
blog.mozilla.org
WebGL in Web Workers
https://blog.mozilla.org/research/2014/07/22/webgl-in-web-workers-today-and-faster-than-expected/
6 comments
what would also be nice is shared read-only Canvas, etc. available in Web Workers so image processing (specifically analysis steps) can be paralellized without copying the entire canvas (or parts of it) through message passing.
If you use Web Workers, you are going to have to use message passing. There is no other way to communicate with a Worker. There are no truly shared objects between js threads.
However, it is still possible to post binary data to a worker and back again without making a copy of it, by using Transferable Objects [1].
You simply have to provide an array of the arraybuffers to move as the second paramter to postMessage(). The caveat is that the data is no longer available to the posting thread after the postMessage call (TypedArray length will be zero).
[1] http://updates.html5rocks.com/2011/12/Transferable-Objects-L...
However, it is still possible to post binary data to a worker and back again without making a copy of it, by using Transferable Objects [1].
You simply have to provide an array of the arraybuffers to move as the second paramter to postMessage(). The caveat is that the data is no longer available to the posting thread after the postMessage call (TypedArray length will be zero).
[1] http://updates.html5rocks.com/2011/12/Transferable-Objects-L...
i'm aware of transferable objects, but it really defeats the purpose of parallelizing analysis of the same thing if that thing becomes unavailable to read after transfer. it would be great to just tell a worker to read a specific bounding box from an existing canvas without having to give up the canvas entirely or copying the bounding box contents into it.
Yeah, that would be awesome. Probably not going to happen with actual DOM objects anytime soon.
I feel like there needs to be a gamejam / instant runoff election of features for webworkers, so much opportunity is being squandered by what could be an elegant solution to many peoples' problems.
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.
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.
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.
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?
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?
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'.
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'.
This is quite lame.
webgl webgl, webgl! webgl? webgl.
Does it achieve parity with native code?
In general, WebGL can't be as efficient as a good native implementation because it has to do more validation for security reasons. However, the quality of OpenGL drivers differs so much in the real world across vendors and operating systems, that the difference to WebGL is lost in the noise (e.g. a WebGL app on Windows can be close to a native GL app on OSX, I'm not even joking).
I know. It remains to be seen if WebGL won't join VRML in a few years.
WebGL is pretty far from VRML. VRML was doomed from the onset. 20 years later 3D does not have an generally agreed-upon standard markup. (Collada is a de-facto common editor format because of the lack of competition. Not because anyone likes it. And, it's explicitly not a content delivery format.)
WebGL is an implementation layer for creating your own content delivery system in the same way that OpenGL is for desktop apps. OpenGL's approach has worked in practice for over 20 years.
WebGL has done a good job of maintaining parity with iPads. As in, you can expect top-of-the-line iPad games to run at parity on decent PCs with decent WebGL implementations.
WebGL is an implementation layer for creating your own content delivery system in the same way that OpenGL is for desktop apps. OpenGL's approach has worked in practice for over 20 years.
WebGL has done a good job of maintaining parity with iPads. As in, you can expect top-of-the-line iPad games to run at parity on decent PCs with decent WebGL implementations.
Unlikely, WebGL has gained much more momentum in a very short time then any other 3D API. Other APIs may be more efficient (a bit more or a bit less, depending on the specific scenario), but no other 3D API runs on so many devices (including Flash). I think WebGL has a very bright future ahead, both on mobile and what we call 'desktop' today.
How do you see that happening?
The WebGL standard is supported in all major browsers, including Internet Explorer, Safari on iOS, and Chrome and Firefox on Android.
The WebGL standard is supported in all major browsers, including Internet Explorer, Safari on iOS, and Chrome and Firefox on Android.
And most stuff I see done with it reminds me of late 90's games, while driving my fan full speed.
Only a few selected mobile devices are able to run WebGL. Those that do, have a tendency to drain the battery quite fast.
Only a few selected mobile devices are able to run WebGL. Those that do, have a tendency to drain the battery quite fast.
It's not so much a question of which device, but which browser. Chrome and Firefox provide WebGL well for Android, and once i0S 8 comes into the fold support will be pretty widespread.
I, and a few others, use it for leading edge instructional design. http://www.vizitsolutions.com/portfolio/gausslaw/
http://caniuse.com/webgl
I, and a few others, use it for leading edge instructional design. http://www.vizitsolutions.com/portfolio/gausslaw/
> Chrome and Firefox provide WebGL well for Android
Most users stick to their system browsers.
Chrome still hides WebGL behind flags in devices that don't have any problem doing OpenGL ES 3.0.
> i0S 8 comes into the fold support will be pretty widespread.
In countries where the average income is above 400€.
Most users stick to their system browsers.
Chrome still hides WebGL behind flags in devices that don't have any problem doing OpenGL ES 3.0.
> i0S 8 comes into the fold support will be pretty widespread.
In countries where the average income is above 400€.
Keep in mind that all Apple mobile devices will support WebGL starting with the next version of iOS. "A few selected" won't be true for long :)
enough with this thought terminating question!
In a browser environment (and other event driven platforms like iOS or Android) it is usually a bad idea to block the main thread (aka UI/browser/event thread) for more then a couple dozen milliseconds because the application would feel unresponsive. If the blocking goes on for seconds, the application will be terminated by the operating system or browser. For a game this means that the game 'cannot own the game loop' like on game consoles or Windows, instead all execution must happen in small per-frame-slices.
As a workaround it is a good idea to move the actual game loop into a thread, and keep the main/UI/browser thread free for UI/input event handling, and other stuff that needs to happen on the app's main thread (varies by platform, in the browser, calls to WebGL currently must happen on the main thread).
In emscripten this was difficult to implement because WebWorkers have a different threading model then traditional 'pthreads' (or may be it was always possible but no-one dared going there). Alon's work may show that it is feasable also in JS+WebGL to move the main loop into a worker thread (I haven't read the code yet whether the worker can actually run completely decoupled from the main thread).
Before Google Native Client was able to call GL from threads I implemented something similar (wrap all GL function calls and write them to a command buffer, and then on the main thread read the command buffer and issue the calls to GL). It worked but I wasn't very happy with it because: all GL calls which return a result would stall the producer thread, and GL is very chatty/verbose, lots of very small calls (e.g. glVertexAttribPointer, glUniform...), and each call now had some tiny additional overhead. In the end I wrote an engine-specific message protocol which was more abstract, thus reducing the number of commands drastically (by 10x or so). But the latency problem is still there (for instance in Chrome, all WebGL calls are encoded again into a command buffer, and decoded in another process), so in my current experimental/minimalistic 3D engine I'm back to not doing any threading at all (good for latency, bad for making use of available CPU resources).