gfx-rs nuts and bolts

gfx-rs is a project bringing efficient cross-platform graphics to rust. This blog supposedly hosts the major milestones, concepts, and recaps of the project.

Release of v0.7

02 Feb 2021

gfx-rs community’s goal is to make graphics programming in Rust easy, fast, and reliable. It governs a wide range of projects:

  • gfx-rs makes low-level GPU programming portable with low overhead. It’s a single Vulkan-like Rust API with multiple backends that implement it: Direct3D 12/11, Metal, Vulkan, and even OpenGL.
  • naga translates the shaders between languages, including WGSL. Also provides validation and processing facilities on the intermediate representation.
  • wgpu-rs is built on top of gfx-rs and gfx-extras. It provides safety, accessibility, and even stronger portability of applications.
  • metal-rs and d3d12-rs wrap native graphics APIs on macOS and Windows 10 in Rust.

Today, we are happy to announce the release of 0.7 versions across gfx/wgpu projects!


Overall theme of this release is simplification. We cut off a lot of experimental cruft that accumulated over the years, cleaned up the dependencies, and upgraded the API to be more modern.

For example, last release we made a step towards more generic bounds with ExactSizeIterator on our APIs. In this release, we are taking two steps back by removing not just ExactSizeIterator, but also Borrow from the iterator API. We figured a way to do the stack allocation without extra bounds, using inplace_it.

Having two distinct swapchain models has also come to an end. We removed the old Vulkan-like model, but also upgraded the new model to match “VK_KHR_imageless_framebuffer”, getting the best of both worlds. It maps to the backends even better than before, and we can expose it directly in gfx-portability now.

There is also a lot of API fixes and improvements, one particularly interesting one is aligning to Vulkan’s “external synchronization” requirements. This allows us to do less locking in the backends, making them more efficient.

Another highlight of the show is the OpenGL ES backend. It’s finally taking off based on EGL context and window system integration. There is still a lot of work to do on the logic, but the API is finally aligned to the rest of the backends (see 3.5 year old issue). We are targeting Linux/Android GLES3 and WebGL2 only.

See the full changelog for details.


spaceship cheese

The list of libraries and applications has grown solidly since the last release. A lot of exciting projects and creative people joined our community.

Our goals were to bring the API closer to the stable point and improve validation. There is quite a bit of API changes, in particular with the pipeline descriptors and bind group layouts, but nothing architectural. We also got much nicer validation errors now, hopefully allowing users to iterate without always being confused :)

The highlight of wgpu work is support for WGSL shaders. It’s the emerging new shading language developed by WebGPU group, designed to be modern, safe, and writable by hands. Most of our examples are already using the new shaders, check them out! We are excited to finally be able to throw the C dependencies (spirv-cross, shaderc, etc) out of our projects, and build and deploy more easily.

See the core changelog and the rust API changelog for details.


Naga has seen intensive development in all areas. SPIR-V frontend and backend, WGSL frontent, GLSL frontent and backend, intermediate layer, validation - all got a lot of improvements. It’s still not fully robust, but Naga has crossed the threshold of being actually usable, and we are taking advantage of it in wgpu-rs.

We experimented on the testing infrastructure and settled on cargo-insta. This boosted our ability to detect regressions, and allowed us to move forward more boldly.

The next steps for us are completing the validation, adding out-of-bounds checks, and replacing SPIRV-Cross completely in applications that have known shaders.

See the changelog for details.

P.S. overall, we are in the middle of a grand project that builds the modern graphics infrastructure in pure Rust, and we’d appreciate anybody willing to join the fight!