2017 was a complete game changer for the Gfx-rs project. After searching for a good programming model, wondering about the API design, we decided to take course on full Vulkan. Good bye
gfx-core, welcome the new king of the hill -
gfx-hal, standing for Hardware Abstraction Layer. Not only we are shaping up the HAL API to match Vulkan as close as possible, we are also implementing a Vulkan Portability layer (for linking with C libraries using
vulkan.h) in https://github.com/gfx-rs/portability .
Hardware Abstraction Layer
HAL brings a lot of goodies to the table:
- Backend support for Vulkan, D3D12, Metal, and even GL is coming. Windowing is now part of the backend as opposed to external crates, providing stronger abstraction and easier user workflows.
- Single shader entry point - SPIRV, translated automatically into backends with the platform differences taken care.
- Compute support and a pretty ocean demo.
There’s been some brewing of frame graphs in Rust gamedev community lately. We hope to see some (potentially competing) implementations on
gfx-hal in 2018. Meanwhile, Amethyst is full steam onto the renderer port to
In the other infrastructure sections, we’ve been working on a compatibility layer to the old
gfx API within
gfx-render crate, which should ease the transition of users to the new HAL. In order to prevent functional regressions, we’ve introduced
warden test framework that loads scenes from text descriptions (in RON).
Vulkan is our future, but having a solid basis with existing users is our present. We’ve just released a long-awaited
gfx-0.17 featuring numerous fixes and improvements, including the WebGL2 support via
wasm32-unknown-emscripten target. We are happy to see Gfx-rs applications, and continue our commitment to support and improve
2017 has been a wild year for our community. We saw the maturing of ggez, steady growth of Amethyst, sudden emergence of three-rs as well as smaller libraries like gfx_glyph. Special welcome to Zemeroth and Gaia. Keep on rocking, folks!