Conversation
CPU (ndarray) stays the default — faster for the current small model and needs no GPU. Enabling the cuda feature switches the backend to cubecl-cuda on the RTX 2080. (wgpu was a dead end: burn 0.20's wgpu module is !Send, which valid() and Optimizer::step reject; CUDA is Send-clean.) - Cargo: cuda feature gates burn/cuda; ndarray always on so tests and the default build need no GPU. - session.rs: TrainBackend is cfg-selected (ndarray | cuda); InferBackend and Device derive from it, keeping the rest backend-agnostic. - shell.nix: allowUnfree + cudaPackages.cudatoolkit + CUDA_PATH, and the host driver lib (/run/opengl-driver/lib, libcuda) on LD_LIBRARY_PATH. Both configs green (fmt/clippy -D warnings/tests). Verified training on the GPU: identical learning curve, ~500 vs ~670 steps/s on CPU — slower at this tiny single-env scale (kernel-launch overhead on m=1 matmuls); the win comes with bigger models / batched envs. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Optional GPU training (CUDA)
Adds a
cudaCargo feature that moves training/inference onto the GPU(cubecl-cuda) on the RTX 2080. CPU (ndarray) stays the default — it's faster
for the current small model and needs no GPU or toolkit. Enable GPU with
cargo run --features cuda.Why not wgpu
wgpu was the portable first choice and a dead end on burn 0.20: its wgpu module
is
!Send(wgpu-core 26'sPendingWritesis!Sync), but bothAutodiffModule::valid()andOptimizer::steprequireSend, soAutodiff<Wgpu>won't compile. The CUDA backend isSend-clean and works as-is.Design
Cargo.toml:cuda = ["burn/cuda"];ndarraystays on always, socargo testand the default build need no GPU.session.rs:TrainBackendiscfg-selected (ndarray | cuda).InferBackendand
Devicederive from it via associated types, so the rest of the code isbackend-agnostic — no
cfgscattered through the logic.shell.nix:allowUnfree+cudaPackages.cudatoolkit+CUDA_PATH, and thehost driver lib (
/run/opengl-driver/lib, wherelibcudalives) appended toLD_LIBRARY_PATH.Measured (honest)
Headless training, both backends learn identically (reward 866→1010, crab stands,
every episode runs the full 500 steps):
GPU is slower at this scale — single env, a 256-wide MLP,
m=1matmuls, sokernel-launch overhead dominates and there's a one-time ~30 s kernel autotune.
The GPU win arrives with bigger models and batched/parallel envs, where the
matmuls become compute-bound. This lands the capability now so scaling up is a
flip of a feature flag, not a porting project.
Verification
cargo fmt --check,clippy --all-targets -D warnings,cargo test(5) — green.--features cuda:cargo check+clippy -D warnings— green; trainingverified live on the 2080 (cubecl initialises device 0, JIT-compiles kernels).
NVIDIA devices + driver while keeping
$HOME/secrets hidden.Not bundled here: per-episode pose metrics (height/uprightness) and a way to
render a trained crab — next up, to make iterating measurable.