Tracking Issue: MVP `no_std` Bevy

[bushrat011899]

This is a tracking issue for progress on a no_std compatible subset of Bevy. The tasks are ordered roughly in sequence (bevy_app can't be no_std until bevy_ecs is for example).

Overview

Below is a visualisation of the crates planned to be ported to no_std. Edges indicate the primary blocker for a crate being ported. The 🚧 symbol indicates that this crate is in-progress, while ✅ indicates it is now available in no_std.

graph TD;
    bevy_a11y[bevy_a11y ✅]
    bevy_app[bevy_app ✅]
    bevy_asset
    bevy_color[bevy_color ✅]
    bevy_core[bevy_core* ✅]
    bevy_diagnostic[bevy_diagnostic ✅]
    bevy_ecs[bevy_ecs ✅]
    bevy_hierarchy[bevy_hierarchy* ✅]
    bevy_input[bevy_input ✅]
    bevy_input_focus[bevy_input_focus ✅]
    bevy_math[bevy_math ✅]
    bevy_mikktspace[bevy_mikktspace ✅]
    bevy_ptr[bevy_ptr ✅]
    bevy_reflect[bevy_reflect✅]
    bevy_state[bevy_state ✅]
    bevy_tasks[bevy_tasks ✅]
    bevy_time[bevy_time ✅]
    bevy_transform[bevy_transform ✅]
    bevy_utils[bevy_utils ✅]
    bevy_window[bevy_window ✅]

    bevy_ptr-->bevy_ecs;

    bevy_utils-->bevy_ecs;

    bevy_tasks-->bevy_ecs;

    bevy_ecs-->bevy_app;

    bevy_app-->bevy_core;
    bevy_app-->bevy_a11y;
    bevy_app-->bevy_asset;
    bevy_app-->bevy_time;
    bevy_app-->bevy_log;

    bevy_core-->bevy_input;
    bevy_core-->bevy_diagnostic;
    bevy_core-->bevy_hierarchy;
    
    bevy_asset-->bevy_image;
    bevy_asset-->bevy_scene;

    bevy_color-->bevy_image;

    bevy_mikktspace-->bevy_mesh;

    bevy_hierarchy-->bevy_remote;
    bevy_hierarchy-->bevy_state;
    bevy_hierarchy-->bevy_transform;
    bevy_hierarchy-->bevy_input_focus;

    bevy_transform-->bevy_mesh;
    bevy_transform-->bevy_scene;
    
    bevy_math-->bevy_input;
    bevy_math-->bevy_color;

    bevy_input-->bevy_window;

    bevy_input_focus-->bevy_a11y;

    bevy_window-->bevy_input_focus;

    bevy_reflect-->bevy_ecs;

    bevy_image-->bevy_mesh;

Loading

Core Tasks

These tasks must be completed for a no_std Bevy to become usable at all.

Prerequisites ✅

• Add core and alloc over std Lints #15281

bevy_ptr ✅

Done prior to initiative.

bevy_utils ✅

• Minor fixes for bevy_utils in no_std #15463

Provide an appropriate Instant type which can be controlled by the user in no_std contexts, or avoid its use. Move web-time into wasm32-only dependencies (doesn't need to exist outside web anyway!). Make thread_local optional.

Done!

bevy_tasks ✅

• Add no_std support to bevy_tasks #15464

Done!

bevy_macro_utils ✅

• Modify derive_label to support no_std environments #15465

Update derive_label to use Box from alloc (requires wrapping the quoted impl in a const _: () = { ... } so that extern crate alloc wont conflict with the outer namespace).

Done!

bevy_ecs ✅

• Remove petgraph from bevy_ecs #15519
• Remove thiserror from bevy_ecs #15774
• Add no_std support to bevy_ecs #16758

Done!

bevy_app ✅

• Remove thiserror from bevy_app #15779
• Add no_std support to bevy_app #16874

Merged!

bevy_core¹ ✅

• Remove bevy_core #16897

Merged!

bevy_internal / bevy

• Thread std / alloc features from sub-crates through to the final bevy crate.

Blocked on bevy_core.

CI 🚧

• Add compile-check-no-std Command to CI Tool #15843
• Once the other core tasks are completed, a no_std example should be created and tested in CI as well.

Bonus Features

These tasks aren't strictly required, but should be completed to close the gap between no_std and std Bevy. The more functionality we can provide in no_std, the more the community can develop for it.

bevy_a11y ✅

• Add no_std Support to bevy_a11y #17505

Done!

This crate is was blocked on AccessKit's lack of no_std support. @DataTriny pointed out AccessKit 0.17 now supports no_std! This should now be quite straightforward to add no_std support to once the other internal blockers are resolved (bevy_app, etc.)

bevy_asset

• Remove thiserror from bevy_asset #15778

Reliance on filesystem operations will make this interesting, but a lot of the asset functionality exists outside of files and folders (processing, etc.). It's reasonable to consider that a no_std platform could have a custom AssetSource (and accompanying AssetReader/Writer/etc.).

bevy_color ✅

• Add no_std support to bevy_color #16633
• Remove thiserror from bevy_color #15777

Done!

bevy_derive

Should work as-is, but need to test.

bevy_diagnostic ✅

• Add no_std support to bevy_diagnostic #17507

Done!

bevy_hierarchy² ✅

• Add no_std support to bevy_hierarchy #16998

Merged!

bevy_image

• Remove thiserror from bevy_image #15771

Blocked on bevy_asset. Would also require some substantial feature-gating to isolate out the no_std compatible subset.

bevy_input ✅

• Remove thiserror from bevy_input #15770
• Add no_std support to bevy_input #16995

Awaiting merge.

bevy_input_focus ✅

• no_std Support for bevy_input_focus #17490

Done!

bevy_log

Blocked on bevy_ecs.

bevy_math ✅

• Add no_std Support to bevy_math #15810
• Remove thiserror from bevy_math #15769

Done!

bevy_mesh

• Remove thiserror from bevy_mesh #15768

Blocked on bevy_image, bevy_transform, and hexasphere. hexasphere would need upstream changes, but on a first-glance looks like to could be no_std.

bevy_mikktspace ✅

• Add no_std support to bevy_mikktspace #15528

Done!

bevy_reflect ✅

• Add no_std support to bevy_reflect #16256
• Remove thiserror from bevy_reflect #15766

Done!

bevy_remote

Blocked on bevy_hierarchy and a design. Currently built around networking, but could support serial commands instead, and would make debugging on embedded much easier too.

bevy_scene

• Remove thiserror from bevy_scene #15764

Blocked on bevy_hierarchy and bevy_asset.

bevy_state ✅

• Add no_std support to bevy_state #17028

Done!

bevy_time ✅

• Remove thiserror from bevy_time #15759
• Add no_std Support to bevy_time #17491

Done!

bevy_transform ✅

• Remove thiserror from bevy_transform #15761
• Add no_std support to bevy_transform #17030

Merged!

bevy_window ✅

• Add no_std support to bevy_window #17031

Merged!

Not Planned

These crates can't be ported to no_std because they are highly platform specific. If you see something on this list that could be ported, please let me know!

bevy_animation ⚠

Blocked by bevy_render.

• Remove thiserror from bevy_animation #15780
• Replace petgraph with a no_std compatible alternative.

Currently only using the DiGraph type with no edge data and only a single node type AnimationGraphNode (and a serializable alternate SerializedAnimationGraphNode).

bevy_audio ⚠

Currently undergoing a major re-write so this is subject to change. I suspect even with the re-write no_std support would be blocked on a fundamental dependency such as cpal. Like rendering, audio is very platform dependent so there likely isn't a viable API Bevy could provide that would be simultaneously feature-rich enough for use on common platforms (PC, etc.) while being low-level enough for no_std ones too.

bevy_core_pipeline ⚠

• Remove thiserror from bevy_core_pipeline #15775

Blocked by bevy_render.

bevy_dev_tools ⚠

Blocked by bevy_render.

bevy_dylib ⚠

Unfamiliar with the dynamic linking this crate provides. I don't see any reason why it couldn't be supported in no_std, but I would definitely require an SME to assist with getting it working.

bevy_encase_derive ⚠

Exclusively used with encase, which is a part of the rendering side of Bevy.

bevy_gilrs ⚠

• Remove thiserror from bevy_gilrs #15773

Built around gilrs which does not currently have any no_std support. There might be a way to upstream no_std support by relying on something like SDL, but I'm not familiar enough with the project to make a fair assessment on the viability here.

bevy_gizmos ⚠

Blocked by bevy_render.

bevy_gltf ⚠

• Remove thiserror from bevy_gltf #15772

Blocked by bevy_render. It may make sense to find a way to break this dependency, since gLTF can be used independently of wgpu (e.g., with a user-created OpenGL renderer backend), but this would need an SME for sure.

bevy_pbr ⚠

• Remove thiserror from bevy_pbr #15767

Blocked by bevy_render and wgpu. Without support for WGSL shaders there's no real point in having this crate supported in no_std.

bevy_render ⚠

• Remove thiserror from bevy_render #15765

Massive crate very deeply integrated with wgpu, which is not just std reliant, but also platform dependent too. I don't think it will ever make sense to have a no_std bevy_render. Maybe could have value in splitting out some abstractions, but I don't know.

bevy_sprite ⚠

• Remove thiserror from bevy_sprite #15763

Blocked on bevy_render.

bevy_text ⚠

• Remove thiserror from bevy_text #15762

Blocked on bevy_render.

bevy_ui ⚠

• Remove thiserror from bevy_ui #15760

Blocked on bevy_render.

bevy_winit ⚠

Blocked on winit. Likely couldn't be made no_std upstream either since it's entirely platform dependent.

General Notes

thiserror

Note: this is now outdated, as thiserror version 2 includes no_std support and is now publicly available.

thiserror is currently not available in a no_std form due to its use of the ::std::error::Error path for Error (which it continues to use for MSRV backwards compatibility). There is a PR to add no_std support to thiserror which preserves that MSRV requirement, but it's unclear if/when that will be merged and released.

One alternative is to link against the PR instead of the published version of thiserror:

thiserror = {
  git = "https://github.com/quartiq/thiserror",
  rev = "515bd36da54dbc346250026ddc349c88851e4bb1",
  default-features = false,
}

Another alternative is to switch to using derive_more. This would require adding explicit calls to derive(From, Display) as well, which adds to the noise. Additionally, it isn't already in the dependency tree, so its inclusion may be contentious.

Due to delays in thiserror's no_std support, we have decided to use derive_more.

portable-atomic

Certain platforms, such as the Raspberry Pi Pico, could run Bevy once no_std support is added, but can't due to Bevy's use of certain atomic features. To work around this issue, Bevy should employ portable-atomic and its sibling portable-atomic-util. These crates provide suitable replacements for the various AtomicX types and Arc.

This adds cfg(...) burden to the project, but would be limited in scope to bevy_ecs and bevy_tasks (the largest users of atomic types), at least initially. Additionally, there is issue with coercion since portable_atomic_util::Arc is a 3rd party smart-pointer, so you cannot, for example, create an Arc<dyn T> directly from an Arc<impl T>. There is a simple workaround, but at a small performance cost for unsized types. However, this will be resolved once #18598 stabilises.

Platform Support

Being no_std is necessary for certain platforms, but it is not always sufficient. Below is a table of platforms that I have tested:

Name	Target	Builds	Notes
UEFI	x86_64-unknown-uefi	Runs	Boots on emulated and real hardware, supported by the uefi crate.
GameBoy Advance	thumbv4t-none-eabi	Partially	The platform does not support all atomic operations (e.g., CAS), which Bevy directly and transiently relies on. Moving from tracing to log, and using portable_atomics is sufficient to make this platform compile.
Nintendo Switch	aarch64-nintendo-switch-freestanding	Compiles	I cannot test the binary produced by cargo nx on real hardware or an emulator to confirm it actually works.
PlayStation One	mipsel-sony-psx	Partially	The platform does not support all atomic operations (e.g., CAS), which Bevy directly and transiently relies on. Moving from tracing to log, and using portable_atomics is sufficient to make this platform compile.
MSP430	msp430-none-elf	No	This platform is 16-bit, which breaks too many assumptions made by dependencies like zerocopy.
Playdate	thumbv7em-none-eabihf	Runs	Runs but requires a patch to fixedbitset to disabled SIMD. Could potentially be fixed from within Bevy without the patch though.
Raspberry Pi Pico	thumbv6m-none-eabi	Runs	Runs but requires adopting portable_atomics within Bevy, since the Pico doesn't support the atomic CAS instructions required.

I have a prototype of no_std compatible Bevy available on this branch. It's not being actively maintained, as it is a proof of concept for upstream no_std support (use at your own risk, etc.). However, if anyone has a particular platform they'd like to use Bevy on, please feel free to test using this branch and let me know what kind of compatibility you have. In general:

• You must be able to compile a Rust project for this platform. (I hope this goes without saying!)
• You must have alloc and core available.
• Your platform must support Atomic CAS (hoping to relax this in the future!)
• Only the bevy_app, bevy_ecs, bevy_utils, and bevy_tasks are compatible in this branch, and must be imported directly (e.g., you can't use bevy;, instead use bevy_app;). Additionally, you must disable default features for no_std compatibility.
• Your platform must be 32-bit or higher due to safety concerns in bevy_ecs. For further information, see [Merged by Bors] - Fail to compile on 16-bit platforms #4736.

Having an std Feature

I've posted a more detailed write-up here. But as a succinct warning: no_std crates should unconditionally be #[no_std] to ensure consistent implicit prelude.

#![no_std]

#[cfg(feature = "std")]
extern crate std;

These findings are acted upon in #17086.

Building for Web using wasm32v1-none

As of Rust 1.84, wasm32v1-none has been stabilised as a tier 2 (no_std) target. This is notable compared to the existing wasm32-unknown-unknown target in that it doesn't enable new proposals as they're stabilised. This massively improves browser compatibility at the expense of some performance and functionality.

As stated, this new target is strictly no_std. This avoids the stubbed-out version of std that wasm32-unknown-unknown has, which panics when attempting to use unsupported APIs. This has the interesting side-effect of motivating previously disinterested parties into supporting no_std. A highly relevant example of this is wgpu. With wgpu potentially gaining no_std support, the possibility of bevy_render and all of its downstream crates becoming no_std compatible themselves goes from an outright impossibility to a potentially desirable mainstream feature.

Footnotes

1. bevy_core has been removed, effectively resolving its no_std compatibility. ↩

2. bevy_hierarchy has been removed since its port. ↩

[BD103]

Looks like there is some effort to make thiserror support #![no_std] in dtolnay/thiserror#304. Looks like it's on hold until the author responds, though.

[bushrat011899]

Yeah that's where I got the (temporary) fix from:

thiserror = {
  git = "https://github.com/quartiq/thiserror",
  rev = "515bd36da54dbc346250026ddc349c88851e4bb1",
  default-features = false,
}

I'm hoping the PR is merged sooner rather than later, but there's a similar issue with petgraph where there does exist a no_std compatible version, but it's waiting in the wings.

In both cases we have options for how to proceed. Either waiting for those crates to get updated, replacing them with something equivalent, or developing a replacement based on these prior efforts.