Blade: a layered graphics stack for Rust

A stack, not a library

Blade describes itself as an innovative rendering solution for Rust, and the README explains the shape of it in one long sentence that is worth unpacking.

It starts with a lean low-level GPU abstraction focused on ergonomics and fun. It then grows into a high-level rendering library that uses hardware ray tracing. It is accompanied by a task-parallel asset pipeline and egui support, turning into a minimal rendering engine. And finally the top-level Blade engine combines all of this with Rapier3D based physics and hides them behind a concise API.

So the layers, bottom to top, are a graphics abstraction, a renderer, an asset pipeline and an editor, and then an engine that adds physics. Each layer is a separate crate with its own version, and the workspace members list confirms it: blade-graphics, blade-render, blade-asset, blade-egui, blade-engine, plus blade-particle, blade-helpers, blade-macros and blade-util as supporting pieces.

That structure is the point of the project. A developer who only wants a nice graphics abstraction takes one crate. A developer who wants a ray traced renderer takes two. Only the top-level engine drags in physics, and even that is optional.

The crates are published separately on crates.io under names such as blade-graphics, blade-render, blade-particle and blade-engine, so the layering is not just a directory structure but a distribution decision.

The project is MIT licensed, the top-level package is at version 0.3.0 on edition 2024 with a minimum Rust version of 1.92, and the last push was on 2026-10-20.

What each layer gives you

The individual crates have distinct jobs, and the examples directory shows them being used.

blade-graphics is the abstraction the README calls lean, with the emphasis on ergonomics and fun. It is the layer that talks to the GPU, and the platform list for it is what determines where Blade runs. The particle example lives alongside it, and the particle crate is published separately, so the particle system is treated as a component of the graphics layer rather than of the engine.

blade-render is the high-level library, and the one that uses hardware ray tracing. The sponza scene render in the examples is the classic test scene for a ray traced path, and the ray-query example directory points at the API the renderer exposes for ray queries.

blade-asset is the task-parallel asset pipeline, and there is a conference talk about it, which suggests the parallelism is the interesting part rather than the format support.

blade-egui is the editor layer, and it uses egui for the interface, with a scene editor screenshot in the repository and a talk on the subject.

blade-engine is the top level, and it is where the Rapier3D physics arrives, along with a vehicle example that shows a physics body being driven around, which is the case that makes a rigid body engine necessary rather than decorative.

The examples also include matmul and move, which are the kind of small benchmark programs that tell you whether a graphics abstraction is being pushed hard, and an info example that prints what the library detected about the machine.

Platform support and where ray tracing stops

The platform list for blade-graphics is short and specific.

Linux runs on Vulkan and GLES. Windows runs on Vulkan. iOS, macOS and tvOS run on Metal. Android runs on OpenXR and Vulkan. And the web runs on WebGL2.

That is five platform families across four graphics APIs, and it is the reason the graphics layer exists as a separate crate. Everything above it is written against that abstraction rather than against any one API.

There is one boundary the README states explicitly, and it is the one that decides whether Blade is usable for your project. The full-stack Blade engine supports its rasteriser on WebGL2. The ray-traced renderer remains available only on backends and devices with ray-query support.

So on the web you get the engine, the physics and the rasteriser, but not the ray traced path. The same applies anywhere the device lacks ray query hardware support, which in practice means older GPUs and most mobile hardware.

That is a reasonable design, since ray queries are a hardware capability rather than an API choice, and the layered design means you can use the parts that work rather than being blocked by the parts that do not.

Running the examples and the two test suites

The instructions section is short and uses the usual Rust workflow.

cargo run --release --example bunnymark

The bunny mark benchmark is the traditional first test of a graphics abstraction, since it is simple geometry under heavy transformation, which makes it a measure of the abstraction's overhead rather than of the renderer.

CPU tests run with the default command.

cargo test

GPU integration tests are a separate matter. They are marked with the ignored attribute and have to be requested explicitly.

cargo test --test gpu_examples -- --ignored --nocapture

The ignored marker is the standard Rust mechanism for tests that need something the default environment does not have, and it has two consequences worth knowing. A plain cargo test does not run them, so a green test run says nothing about the GPU paths. And a CI job that wants them has to ask for them by name.

The nocapture flag is there so the output of the GPU examples is visible, which is how you see what the renderer actually printed rather than only the pass or fail result.

The example directories cover the ground the project cares about: the bunnymark benchmark, the info diagnostic, matmul and move for raw compute, particle for the particle system, ray-query for the ray tracing API, scene for a loaded scene, and vehicle for physics.

A fork of wgpu and a synchronisation model

The workspace dependency list shows the most consequential choice in the project, which is that Blade does not use the published wgpu crate.

Instead it depends on naga from a fork of wgpu, pinned to a specific commit, with a comment in the manifest noting that it comes from a stable branch of that fork. The fork carries the wgsl-in and termcolor features.

That means Blade is not simply a wrapper around wgpu, it is a consumer of a modified version of it, and it will track its own fork rather than the upstream releases.

The reason is stated in the research section of the README, and it is a synchronisation problem. The paper, Global Pass Barriers Without Per-Resource RHI Tracking: A Cross-Vendor Study with Blade, measures Blade's synchronisation model against matched wgpu workloads on AMD, NVIDIA, Intel and Apple hardware.

The idea in the title is the idea. Instead of tracking resource state per resource, Blade uses a global pass barrier, so a pass ends and the next begins without the usual bookkeeping. Doing that requires changes below the level of wgpu's public API, which is presumably why the fork exists.

A copy of the paper is kept in the repository, and a synchronisation guide summarises the resulting design and what an engine built on Blade is still responsible for. That second part matters if you adopt the library, because the library is not the whole story on synchronisation.

The research posture of the project

It is unusual for a rendering library to publish a research paper, and Blade leans into that.

Beyond the synchronisation paper, the README collects four conference talks: In GPU we Rust at a Rust AI meetup in 2024, Blade lean and mean graphics library at a Rust Graphics meetup in 2023, and two Rust Gamedev meetup talks in 2023, one about the asset pipeline and one about the scene editor.

The talk list tells you the shape of the project's development. The graphics layer was presented as a design talk, the asset pipeline and the editor were each presented separately, and the most recent talk is in an AI meetup rather than a graphics one, which suggests a change in direction toward interactive and AI assisted use cases.

The toolchain around it matches. There is a Matrix chat room with the badge for the developer channel, a build status badge, documentation on docs.rs and an arXiv badge pointing at the paper.

The README also shows an architecture diagram and four example renders, the scene editor, a particle scene, a vehicle with colliders and the sponza scene. Reading those images tells you the intended use is real-time interactive graphics with physics rather than offline rendering, which is a different set of trade-offs from a renderer that only has to produce one good frame.

Versions, licensing and what to check first

The version numbers are early and the crates move independently.

The top-level package is at 0.3.0, blade-graphics and blade-egui are at 0.9, blade-render is at 0.6, blade-util at 0.5, blade-helpers and blade-macros at 0.3, blade-asset at 0.2.2, blade-particle at 0.2 and blade-engine at 0.2. Nothing is at 1.0, and the repository has no GitHub releases, so there is no tagged history to pin against.

The licence is MIT, with the LICENSE file at the root of the repository.

Three checks before you build on this.

Whether your platform is on the list with the API you need, and whether the ray traced renderer is available at all on your target, since the web path is rasteriser only.

Whether you are comfortable with a wgpu fork. If your project already depends on upstream wgpu, having two different naga and wgpu versions in the same build is a real integration cost, and the fork's own release cadence is not described in the README.

And whether the synchronisation model suits your engine. Read the guide and the paper rather than assuming, because the paper says the model was measured against matched wgpu workloads on four hardware vendors, and the guide says what an engine using Blade is still responsible for. That is the part that decides whether the abstraction saves you work or hands you a different set of jobs.

Editorial conclusion

Blade suits a Rust developer who wants to own a rendering stack rather than adapt an existing engine, since each layer is a separate crate with its own version and you can stop at the layer you need, from the graphics abstraction to the full engine with physics. It is the wrong choice if you need production stability, because the whole stack is pre-1.0 with an empty feature table and no GitHub releases, and it is the wrong choice on the web, where the ray traced path is unavailable. Verify first that the platform you target is on the supported list with the API you need, read the synchronisation guide and the paper before you build a synchronisation model on top of it, and check that the wgpu fork pinned in the workspace is acceptable for your project.

Frequently asked questions

Official sources

1. Issues
2. kvark/blade on GitHub
3. License: MIT
4. README