Mozilla has submitted a proposal to the the Khronos Group, the stewards of the OpenGL and the more recent Vulkan graphics APIs, for a next-generation web graphics API it calls Obsidian.
This submission comes a month after Apple submitted its proposal for WebGPU, a similar project that it intends to prototype directly into the WebKit browser project.
If Mozilla’s idea accrues interest, it could set the stage for a clash over the future of web graphics between two standards-setting bodies, one that oversees the web generally and another that governs cross-platform graphics APIs.
Mozilla’s master plan
WebGL, the current standard for rendering graphics on the web, has been ripe for a successor that better exploits recent advances in GPUs. Khronos has been talking up the need for a unified, next-generation graphics API that transcends platforms and recently provided a GitHub repository where one could submit proposals for a WebGL standard that meets those criteria.
The draft proposal for Obsidian is exactly that: a draft that spells out high-level concepts for a graphics API that’s “designed for WebAssembly, modern GPUs, and multithreaded environment[s],” and that “provides [the] maximum feature set of the GPU to the web applications.”
According to Mozilla’s proposal, most of the previous discussions have fallen into two possibilities. One was simply porting the existing Vulkan API—a workable idea, since Vulkan is already a platform-neutral API designed for multithreaded environments. The other was to use Apple’s Metal API as the basis for a new API, “due to [its] simpler and higher level abstraction, which is easier to provide safely on the web.”
With Obsidian, Mozilla elected to create “a reduction of Vulkan that would make sense for the web” and could be implemented in Apple’s Metal and Microsoft’s Direct3D 12, as well as Vulkan itself. Mozilla also recommends using SPIR-V as the language for programming shaders since Vulkan already uses it.
Obsidian diverges from Vulkan in making sure that the result is safe to use with web applications—a major concern with an API as powerful as Vulkan—and can function well in a memory-managed, garbage-collected environment like WebAssembly. “That means no GC allocations during the rendering loop in order to avoid the garbage collection pauses,” writes Mozilla.
Apple’s alternative
By contrast, Apple’s WebGPU concept isn’t meant to be tied to a particular GPU library. In theory it’s “generic enough to be implemented on top of modern GPU libraries,” according to the group’s charter document. Vulkan is one of many such libraries, but there’s no particular dependency on it.
The biggest contrasts between Mozilla’s and Apple’s options may not be in the proposals themselves, but the venues through which they’re presented. WebGL was developed at Khronos with input from Mozilla, Apple, Google, Opera, and other bodies; Mozilla submitted Obsidian directly to Khronos. For WebGPU, Apple proposed setting up a community group at the W3C, called the GPU on the Web Community Group. Google also has its own offering to that group, a prototype called NXT.
It’s easy to see why Apple would execute an end run around Khronos. It chose not to support Vulkan on MacOS, sticking instead with Metal, and is proposing a standard that allows its proprietary work to be used side by side with what’s available on other platforms.
Right now, the proposals on the table are extremely raw, no more than a couple of months old. But there’s a risk of future confusion over which standards-setting body will have the most say in the matter: the long-established Khronos, a body widely associated with graphics standards, or a newly formed group at the W3C with members seeking in part to protect a competitive interest.