Subject: General Tech | January 27, 2017 - 03:55 PM | Scott Michaud
Tagged: webgl, webgl2, firefox, chrome, google, mozilla, Opera
After quite a bit of anticipation, both Mozilla and Google have just shipped compatible implementations of WebGL 2. This feature was unlocked to the public in Firefox 51 and Chrome 56 for the desktop, both released this week, while Opera will push it out to desktop and mobile on their next version, Opera 43. Microsoft currently has the API “under consideration” for Edge.
As we’ve highlighted in the past, this new version of the graphics API pushes the platform up to OpenGL ES 3.0, with a few exceptions that are typically made for security reasons. This update allows quite a few new features like off-screen render targets, which is useful for deferred rendering. The shading language is also significantly larger, and can now operate natively on integer types and 3D textures.
WebGL 2.0 does not include compute shaders, however, which is a bit unfortunate. That said, it is (at least last I checked) a highly-requested feature and the browser vendors are interested in providing it.
Subject: General Tech | June 10, 2016 - 01:50 AM | Scott Michaud
Tagged: Basemark, webgl, webgl2
Basemark has just released Basemark Web 3.0, which includes WebGL 2.0 tests for supporting browsers. No browsers support the standard by default yet, although it can be enabled on Firefox and Chrome with a command-line flag.
WebGL 1.0 has become ubiquitous, but it is based on quite an old version of OpenGL. OpenGL ES 2.0 was specified all the way back in March 2007. While it simplified development by forcing everyone down a programmable shader pipeline, it has quite a few limitations. OpenGL ES 3.0 remedied many of these, such as allowing multiple render targets and texture compression. OpenGL ES 3.1 added compute shaders, which brings us pretty much to today. In fact, Vulkan targets OpenGL ES 3.1 hardware (should the hardware vendor provide a driver).
WebGL targeted OpenGL ES 2.0. WebGL 2 targets OpenGL ES 3.0.
Of course, this means that the WebGL 2.0 base standard does not support compute shaders, which is a bit of a drag. It's something that they really want to incorporate, though, but they still can't seem to decide whether it will align with a new version of WebGL (such as WebGL 2.1) or be incorporated in a multi-vendor extension.
So where are we today?
Well, WebGL 2.0 is still a little ways off from being everywhere. As we mentioned, only Firefox and Chrome support the standard, although WebKit is working on it, too. Microsoft has WebGL 2.0 listed as “Under Consideration” with a “Roadmap Priority” of Medium, “Development is likely for a future release.” One major hold up was its shader support. Again, OpenGL ES 3.0 shaders are much more complex than OpenGL ES 2.0 ones, and many WebGL browsers convert OpenGL ES 2.0 shaders to HLSL for DirectX on Windows. This circumvents lackluster graphics drivers, and it adds an extra, huge layer of complexity for someone who wants to write malware. It's not sufficient to know of a driver bug with a specific shader string -- you need to trick the transpiler into outputting it, too.
But, again, we're slowly inching our way there.
Subject: General Tech | December 31, 2015 - 10:25 PM | Scott Michaud
Tagged: webgl2, webgl, mozilla, firefox
The next step is WebGL2. OpenGL ES 3.0 adds a bunch of new features that are sorely needed for modern games and applications. For instance, it allows drawing to multiple render targets, which is very useful for virtual cameras in video games (although the original WebGL software could access this as an optional extension when supported). The addition of “Uniform Buffer Objects” is a better example. This allows you to store a bunch of data, like view transformation matrices, as a single buffer that can be bound to multiple applications, rather than binding them one at a time to every draw that needs them.
It's hard to describe, but demos speak a thousand words.
The news today is that Mozilla Nightly now ships with WebGL2 enabled by default. It was previously hidden, disabled by default, behind an option in the browser. This doesn't seem like a big deal, but one of the largest hurdles to WebGL2 is how the browsers actually implement it. The shading language in WebGL was simple enough that most browsers convert it to DirectX HLSL on Windows. This is said to have the added advantage of obfuscating the ability to write malicious code, since developers never directly writes what's executed. GLSL in OpenGL ES 3.0 is much more difficult. I'm not sure whether the browsers will begin to trust OpenGL ES 3.0 drivers directly, or if they finally updated the GLSL translator, but supported implementations means that something was fixed.
Unfortunately, OpenGL compute shaders are not supported in WebGL2. That said, the biggest hurdle is, again, to get WebGL2 working at all. From my talks with browser vendors over the last year or so, it sounds like features (including compute shaders) should start flying in easily once this hurdle is cleared. From there, GPGPU in a website should be much more straightforward.