WebGPU post

Author: kvark

_posts/2019-03-06-wgpu.md

@@ -0,0 +1,48 @@
+---
+layout: post
+title: The rise of WebGPU
+---
+
+[gfx-rs](https://github.com/gfx-rs/gfx) is a Rust project aiming to make graphics programming more accessible and portable, focusing on exposing a universal Vulkan-like API targeting all platforms. Over the past 2 years we've put a lot of effort into making gfx-rs API compatible with Vulkan and wrapping it in the [Vulkan Portability bindings](https://github.com/gfx-rs/portability). We optimized the Metal backend, nailed down hundreds of issues revealed by [Vulkan Conformance Test Suite](https://github.com/KhronosGroup/VK-GL-CTS), contributed our expertize to the [standardization process](https://github.com/KhronosGroup/Vulkan-Portability). What didn't go entirely smooth was the integration into Rust ecosystem: building libraries and applications on top of gfx-hal proved to be extremely challenging due to the low-levelness and unsafety of the API.
+
+The main community driving gfx-hal adoption today is Amethyst, and they produced a nice helper library called [Rendy](https://github.com/omni-viral/rendy). As they call it, a "collection of crates to build your own renderer". The concept has a reminiscent of LLVM ("build your own compiler") and overall fits nicely into Amethyst philosophy. The project has recently [been released](https://community.amethyst-engine.org/t/rendy-is-released/459), and we encourage everyone to check it out.
+
+## WebGPU
+
+[WebGPU](https://www.w3.org/community/gpu/) is a new graphics/compute API developed by the browser vendors (and Intel) within W3C:
+> The goal is to design a new Web API that exposes these modern technologies in a performant, powerful and safe manner.
+
+Don't be confused by the "Web" part here - both us (gfx-rs team) and Google are trying to make it feasible to run on native platforms as well. Typically, Web as the platform has different priorities from native: a lot of focus is placed on the security and portability (in a wider and stronger sense). Coincidentally, these are qualities we are currently missing in gfx-rs ecosystem: security means safety (in Rust sense), and portability means that people can use it and run everywhere, without worrying about thousands of potential configurations at run-time, or diverging behavior between platforms due to timing or loosely defined behavior.
+
+With these goals in mind, we'd like to announce our new project: [wgpu-rs](https://github.com/gfx-rs/wgpu).
+
+## wgpu-rs
+
+wgpu-rs is a safe, portable API which reduces the complexity of working with low-level graphics APIs. It has a layered implementation:
+
+- The `wgpu-native` layer which exposes a C API. `wgpu-native` implemented on top of gfx-hal which allows it to work with the same platforms that gfx-hal already supports. The idea is that `wgpu-native` will have a compatible C API with Google's [Dawn](https://dawn.googlesource.com/daw) implementation so they can be used interchangeably for applications compiled in other languages.
+- The `wgpu-rs` layer which is an idiomatic safe Rust API. It uses `wgpu-native` internally when targetting the native targets. It will use Web APIs (from WASM host bindings) directly when targetting the Web in the future.
+
+Let's dive into the mentioned qualities of the API:
+
+### Simple
+
+Writing straight Vulkan code for an application can easily challenge users sanity. It's a great API, it's well documented, but still very complex, and it's made with the focus on engines as opposed to direct users. You have to think about the memory allocations, pipeline stages, resource states and lifetimes, all the time. Just rendering a textured rectangle out there without triggering any validation warnings is an achievement.
+
+WebGPU automates some of the aspects of low-level graphics APIs which have high complexity but low return on investment. It still has the core pieces of the next-gen APIs, such as command buffers, render passes, pipeline states and layouts. Because the complexity is reduced, users will be able to direct more focus towards writing efficiently application code.
+
+### Safe
+
+WebGPU is designed from the ground up to have all the validation built-in. In our case, `wgpu-native` is responsible for sanitizing the inputs, capturing invalid usages, and reporting back to the user. This means that our `wgpu-rs` wrapper can be entirely safe in the Rust sense. We don't even rely on Rust syntax and features for safety, since it's handled at the lower level, so we can have as much type-safety as we want to feel comfortable, or as little as needed to be flexible.
+
+### Portable
+
+The code runs on a variety of platforms from a single source: Vulkan, Metal, D3D12/D3D11, and eventually the Web (when the browsers gain support for the API, which is also in our scope of work). And it's expected to behave exactly the same, independent of the exposed hardware queues, image format capabilities, or memory types.
+
+## Picking up the flag
+
+In a way, WebGPU is trying to accomplish all the goals we set for ourselves originally at the start of gfx-rs project. And that's why we are so enthusiastic about it: it's more modern, it's more safe, it's more portable, and there is a working group behind it with strong momentum which will eventually become widespread. Today we are releasing [wgpu-0.2](https://crates.io/crates/wgpu/0.2.0) for the community to try out. It's still largely incomplete (e.g. no validation or error reporting yet), but it reached a point of being usable:
+
+![WGPU shadow](/img/wgpu-shadow.png) ![WGPU asteroid](/img/wgpu-asteroid-giger.png)
+
+We are looking forward to see what the community is able to accomplish with it, and I myself (@kvark) have a number of projects using gfx pre-ll that have been waiting for this moment to upgrade. With `wgpu-rs` we can finally deprecate the old gfx and have a solid recommendation for people getting starting with graphics in Rust.