Editing

Author: unconed

_posts/2019-03-06-wgpu.md

@@ -3,18 +3,16 @@ layout: post
 title: The rise of wgpu
 ---
 
-[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.
+[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 smoothly was the integration into Rust ecosystem: building libraries and applications on top of gfx's hardware abstraction layer (hal) proved to be extremely challenging due to the low-levelness and unsafety of the API. There is a serious demand for an API that has the capabilities of Vulkan but is easier to work with.
 
-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.
-
-This is all still very experimental: Amethyst hasn't fully switched to gfx-hal yet, Rendy is version 0.1.1, and gfx itself may surprise with missing features, although your mileage may vary per backend. But we're having a lot of fun with it already!
+The main community driving `gfx-hal` adoption today is the Amethyst game engine, 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 is reminiscent of LLVM ("build your own compiler") and overall fits nicely into the Amethyst philosophy. The project has recently [been released](https://community.amethyst-engine.org/t/rendy-is-released/459), and is worth checking out despite being experimental. Amethyst hasn't fully switched to gfx-hal yet, Rendy is version 0.1.1, and gfx's mileage may vary per backend. We're having a lot of fun with it already, but that's not all.
 
 ## 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.
+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, the Web as a 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 the gfx-rs ecosystem: security means safety (in the 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 differences 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).