3 ms·
Good question! Maybe with my side project, I can shed some light on the state of OpenGL exposed through the web: I maintain a Matrix code rain project: https:/
by rezmason 7y ago
Good question! Maybe with my side project, I can shed some light on the state of OpenGL exposed through the web:
I maintain a Matrix code rain project: https://github.com/Rezmason/matrix https://github.com/Rezmason/matrix . The effect is basically a compute shader with post-processing steps applied on top of it. It's built on top of WebGL via ThreeJS, and I can attest that its cross-browser, cross-device support is currently terrible.
That's because ThreeJS's (otherwise nice!) compute shader implementation is written on top of WebGL 1's fragment shaders, rendering to floating point buffers enabled through the "oes_texture_float" extension.
This extension's implementation has been plagued by spec mistakes, made possible (I believe) by ambiguities and tacit assumptions about differences between the speccing process of OGLES 2 and WebGL 1 that proved incorrect. Fixing it has frayed implementors' constitutions and made the API more complicated; WebGL 2 incorporates this extension's behavior into its core, but isn't widely adopted, because (in my opinion) asking a browser maker to double down on their investment in WebGL again after the aforementioned debacle is a tall order. Or maybe there are security implications. Or maybe the only Mobile Safari programmers available decided OpenGL is a weird-shaped API to expose through JavaScript, and have lost interest. One can only speculate.
Anyway! In the meantime, to do any sort of GPU compute across all major browsers (including mobile), you're way better off enabling the "oes_texture_half_float" extension instead. Half floats, or Float16s, are common in the mobile graphics sphere, but not on the desktop, where most web development takes place; it's entirely understandable why a web developer might try and use "oes_texture_float", get it working on their desktop machines, fail to see it working in Mobile Safari, assume that the extension isn't supported, and call it a day. And even if they DO find the Stack Overflow answers that'd prompt them to switch to "oes_texture_half_float", JavaScript has no native Float16Array data view, so they have to make/download a slow JavaScript implementation or spin their own float to half float converter.
This is the state of things with WebGL.
- fulafel 7y agoWebGL 2 is pretty widely implemented. I think Safari is the only remaining laggard now that MS switched to Chrome based Edge? It's true that WebGL support has been slow to mature in browsers, as will WebGPU be I fear...
- Jasper_ 7y agoWebGL 2 practically does not exist on Android. Implementation ranges from "horribly broken" to "barely usable". I've catalogued this before: https://twitter.com/JasperRLZ/status/1208593692203859968 https://twitter.com/JasperRLZ/status/1208593692203859968
- fulafel 7y agoInteresting. The Looking at Chrome tests about WebGL2 conformance (https://cs.chromium.org/chromium/src/content/test/gpu/gpu_tests/test_expectations/webgl2_conformance_expectations.txt https://cs.chromium.org/chromium/src/content/test/gpu/gpu_te...) it would look like Android is no worse than other platforms wrt known failing test cases (with link to relevant bugs) there. Firefox seems similar: https://hg.mozilla.org/mozilla-central/file/tip/dom/canvas/test/webgl-conf/mochitest-errata.ini https://hg.mozilla.org/mozilla-central/file/tip/dom/canvas/t... (The conformance part is maintained by Khronos so there should in theory be less bias than vendors own tests)
- Jasper_ 7y agoChrome on Android passes things through to the system OpenGL driver. This is almost certainly a case of terrible platform drivers, but there's nothing I can really do about that.
- fulafel 7y agoIt'll still have to go through ANGLE or other GL sandboxing layer to be safe, and there are other OpenGL-backed Chrome platforms (Mac, Linux) that also have driver bugs. If vendor GL driver bugs hurt more on Android, maybe it's just for lack of testing which would lead to browsers or ANGLE adding workarounds for driver bugs. (There are amazing heaps of driver bug workarounds in ANGLE that rewrite malfunctioning GL calls) edit: I guess in theory they might just rely on the Android sandbox without going through the ANGLE GLES implementation, since that should nominally be already hardened for untrusted code. But that sounds too risky from a security POV given how a lot of Android devices in practice don't get timely security updates etc.