Gfx-rs nuts and bolts

Gfx-rs is a low-level graphics abstraction layer in Rust. This blog supposedly hosts the major milestones, concepts, and recaps of the project.


Release of v0.9 and the Future of wgpu

16 Jul 2021

gfx-rs community’s goal is to make graphics programming in Rust easy, fast, and reliable. Our current main projects are:

  • 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 ES.
  • naga translates the shaders between languages, including WGSL. Also provides validation and processing facilities on the intermediate representation.
  • wgpu is built on top of gfx-rs and gpu-alloc/gpu-descriptor. It provides safety, accessibility, and strong portability of applications.

Following our release cadence every few months, we rolled out the 0.9 version through all of the gfx projects! See gfx-rs changelog, wgpu changelog, and naga changelog for the details.

naga has matured significantly since the last release.

  • wgsl parsing has improved incredibly, targeting an up-to-date spec.
  • spirv parsing support has had numerous bugs fixed.
  • glsl support is starting to take shape, though still in an alpha state.
  • Validation has gotten more complete and correct.

wgpu validation has continued to improve. Many validation holes were plugged with the last release. Through the combined work in wgpu and naga, validation holes have been sured up, and new features have been implemented. One such feature is getting the array length of runtime-sized arrays, which is now properly implemented on metal.

wgpu performance is still a vital target for us, so we have done work on improving the overhead of resource tracking. We’ve reduced unnecessary overhead through only doing stateful tracking for resources that have complex states. These changes were made from benchmarks of Gecko’s WebGPU implementation which showed that tracking was a bottleneck. You can read more about it #1413.

wgpu Family Reunion, Relicense, and the Future

wgpu has had a number of large internal changes which are laying the future for wgpu to be a safe, efficient, and portable api for doing cross-platform graphics.

wgpu has been relicensed from MPL-2.0 to MIT/Apache-2.0. Thank you to all 142 people who replied to the issue and made this happen. This relicense is an important change because it allows the possibility of adding backends targeting APIs which are behind NDAs.

For a while, we acknowledged that having different essential parts of the project living in different repositories was hurting developers productivity. There were objective reasons for this, but the time has come to change that. Feedback from our friends at the Bevy game engine gave us the final push and we launched an initiative to make wgpu easier to contribute to. We moved wgpu-rs back into the wgpu repo. This means that PRs that touch both the core crate and the rust bindings no longer need multiple PRs that need to be synchronized. We have already heard from collaborators how much easier the contribution is now that there is less coordination to do. Read more about the family reunion.

As a part of our family reunion, 0.9 is going to be the last release that will use gfx-hal as its hardware abstraction layer. While it has served us well, it has proved to not be at the exact level of abstraction we need. We have started work on a new abstraction layer called wgpu-hal. This new abstraction has already had Vulkan, Metal, and GLES ported, with DX12 landed in an incomplete state, and DX11 to come soon. To learn more about this transition, you can read the whole discussion.

Finally, we have brand new testing infrastructure that allows us to automatically test across all backends and all adapters in the system. Included in our tests are image comparison tests for all of our examples and the beginnings of feature tests. We hope to expand this to cover a wide variety of features and use cases. We will be able to run these tests in CI on software adapters and our future goal is to setting up a distributed testing network so that we can automatically test on a wide range of adapters. This will be one important layer of our in-depth defences, ensuring that wgpu is actually portable and safe. Numerous bugs have already been caught by this new infrastructure thus far and it will help us prevent regressions in the future. Read more about our testing infrastructure.

Thank You!

Thank you for the countless contributors that helped out with this release! wgpu’s momentum is only increasing due to everyone’s contributions and we look forward to seeing the amazing places wgpu will go as a project. If you are interested in helping, take a look at our good-first-issues, our issues with help wanted, or contact us on our matrix chat, we are always willing to help mentor first time and returning contributors.

Additionally, thank you to all the users who report new issues, ask for enhancements, or test the git version of wgpu. Keep it coming!

Happy rendering!