The story of WebGPU — The successor to WebGL

I was working the other day on an .obj file parser and wanted to test it. An .obj file just contains a collection of vertecies and faces, that together compose a 3D object. Anyways I wanted to test it by rendering the final result. I thought that it would be easy enough to do so with a bunch of divs that use 3D CSS transformations. After all it’s just a simple object, right? Long story short, this is the best I could pull off:

I know, it’s upside down.. But hey at least it uses pure HTML! Anyways I could have kept working on it, but the juice just wasn’t worth the squeeze. I was looking into a more suitable rendering solution, and obviously WebGL came to mind. As for today this is the only, proper method for rendering 3D objects. It’s been a while since last time I used WebGL, so I had to do a little research about its API. This is when I stumbled upon WebGPU.

WebGPU is the successor to WebGL. It is still a bleeding edge technology, and it’s turned off by default in all browsers (if available at all). The API is very unstable as it keeps changing with each browser release.

Here’s what I was thinking initially:

• What does WebGL lack?
• What is WebGPU?
• Why is it better?

In this article I would like to answer these questions, as well as discuses about:

• The history of WebGL.
• The future of graphics on the web.

The history of WebGL

At 2009 a non profit organization called Khronos group started a WebGL working group, where representative from Apple, Google, Mozilla and Opera were also involved. The purpose of WebGL was to support native 3D capabilities on the browser. Like the name implies, it runs on the web and uses OpenGL as its API. Vladimir Vukićević, the mind behind the initial prototype of WebGL, was targeting OpenGL because there were already OpenGL developers outside the web ecosystem, and finding them would be relatively easy. He also claimed that “the web is not good at adopting large specs”, thus he was aiming for something familiar. Here’s a video from 2009 showing Vladimir elaborating about WebGL:

Note that WebGL doesn’t necessarily run on OpenGL, it actually varies based on the platform. On Linux / MacOS it runs on OpenGL, and on windows it runs on DirectX. On Edge, WebGL content will be converted to DirectX equivalents to display it; the WebGL renderer converts WebGL calls into DirectX equivalents, and the transpiler converts GLSL shaders to HLSL shaders (GPU stuff). The ANGLE project — as used in Chrome and Firefox — has similar functionality. See Microsoft’s blog post for further info about that.

Thoughts on Flash (ft. Steve Jobs)

For a while there was a debate on whether people should keep using Flash or WebGL. Flash was used across many websites; it was reliable but required an external plugin installation and wasn’t native to the web. In a sense it also gave Adobe all the power, since it wasn’t based on an open specification. In 2010 Steve Jobs published an open letter called “Thoughts on Flash”. TL;DR: he was very against it, and absolutely was not willing to support it on any of Apple’s devices. The letter is a few pages long, but Jobs knew that I’m gonna write this article and prepared a conclusion statement in advance (sarcasm):

Conclusions.

Flash was created during the PC era — for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open web standards — all areas where Flash falls short.

The avalanche of media outlets offering their content for Apple’s mobile devices demonstrates that Flash is no longer necessary to watch video or consume any kind of web content. And the 250,000 apps on Apple’s App Store proves that Flash isn’t necessary for tens of thousands of developers to create graphically rich applications, including games.

New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind.

Steve Jobs

April, 2010

This letter alone could have possibly shaped the entire graphics ecosystem on the web. Fast forward, on 31 December 2020, Adobe completely dropped Flash support.

What went wrong?

I believe that back in 2006 when Vladimir was adopting the OpenGL specification he had good intentions. OpenGL was not platform specific and sounded like a viable option, because it was available on any platform, unlike its competitor, DirectX. However, things didn’t turn out as expected.

I would like you to read a quote from Dzmitry Malyshau’s personal blog, who is an active member in Khronos group:

OpenGL drivers on both desktop and mobile were poor. It was wild west: full of bugs and hidden secrets on how to convince the drivers to not do the wrong thing. Most games targeted Windows, where at some point D3D10+ was miles ahead of OpenGL in both the model it presented to developers, and the quality of drivers. Today, Web browsers on Windows don’t run on OpenGL, even though they accept WebGL APIs, and Firefox has WebRender on OpenGL, and Chromium has SkiaGL. They run that all on top of Angle, which translates OpenGL to D3D11.

To put it simple, game developers were actually seeing DirectX as a more viable option, as opposed to OpenGL. WebGL was never intended to use DirectX’s API and for a good reason, it doesn’t promote exclusivity to any company. This put WebGL at a disadvantage. Not only it’s slower, but it also doesn’t know how to run DirectX code.

Introducing — Vulkan (aka OpenGL Next)

In 2013, AMD developed a low level rendering API named Mantle in cooperation with DICE, designed as an alternative to DirectX and OpenGL. The implementation was later donated to Khronos group in 2016, with the intent of giving Khronos a foundation on which to begin developing a low-level API that they could standardize across the industry. Khronos started working on a new API which was derived from and built upon components of AMD’s Mantle API, and named it Vulkan. A group named “Vulkan Portability” was then created with the intent of layering Vulkan on top of DirectX 12 and Metal — Apple’s version of DirectX.

Compared to OpenGL, DirectX 11 and Metal, Vulkan is intended to offer higher performance and more balanced CPU/GPU usage. Other major differences from DirectX 11 and OpenGL is Vulkan being a considerably lower-level API and offering parallel tasking. In addition to its lower CPU usage, Vulkan is designed to allow developers to better distribute work among multiple CPU cores.

WebGPU to the rescue

This is where it all comes down to. WebGPU will be based on Vulkan, which will result in greater performance, and will make it an inseparable part of the native ecosystem due to Vulkan’s standardized API. WebGPU is still in very early stages of development, but it’s a huge stepping stone. The implementation status of WebGPU can be seen in gpuweb’s Github repo.

For reference, I prepared a few charts that compare OpenGL to Vulkan in the following aspects: CPU load, GPU load, and FPS. These are the improvements you should be expecting to see on WebGPU:

It’s easy to see the great performance boost of Vulkan at a much less CPU cost. The benchmarks above are based on the following demo video:

The future of graphics on the web

For a change, Unreal engine 4, one of the most popular game development engines alongside Unity, might become available again on the web again. As of Unreal Engine 4.24 (31 May, 2019), support for the HTML5 platform has been migrated out of the engine. This really tells us that the potential of WebGL is at its peak and we aren’t gonna see anything new from it.

Games and graphic intensive software development is expected to be much cheaper with availability on much more platforms — Linux, Mac, SteamOS, XBOX, Playstation, Android, iPhone, Windows, and of course, Web. Windows will no longer have exclusivity.

WebGPU has the potential to be the go-to choice for amateur developers, students, indie professionals, mobile game studios, and many other groups. It could be the default GPU API, if it can deliver on its promises of safety, performance, and portability. If you’re a developer like me, who’s looking to learn something new that will last long into the future — WebGPU might be the right answer for you.

And here’s a picture of a fully rendered teapot if it makes you feel any better: