[Draft/RFC] cuda-oxide (native CUDA) device build for vortx-shaders#9
Draft
haixuanTao wants to merge 3 commits into
Draft
[Draft/RFC] cuda-oxide (native CUDA) device build for vortx-shaders#9haixuanTao wants to merge 3 commits into
haixuanTao wants to merge 3 commits into
Conversation
Two fixes, both needed before vortx-shaders compiles for the native-CUDA (cuda-oxide -> nvptx64) backend; neither affects the WebGPU/spirv or host builds. 1. lib.rs: extend `no_std` to nvptx64. The crate only declared `#![cfg_attr(target_arch = "spirv", no_std)]`, so under the cuda-oxide path (target nvptx64) it implicitly linked `std`, which the target has no crate for -> the std prelude failed to load, cascading into ~27 "can't find `derive`/`step_by`/prelude/std" errors across six modules. nvptx64 was already excluded from the host `extern crate std` just below, so the GPU/host split was intended; the no_std gate just never listed nvptx64. Now: any(spirv, nvptx64). 2. Cargo.toml: pull khal-std with `default-features = false`. khal-std's default = ["rust-cuda"] enables cuda_std (and thus `half`), which is not no_std-clean on nvptx64 and breaks the device build. The cuda-oxide feature is forwarded explicitly, so the rust-cuda default is unwanted here. Mirrors how nexus-cuda already declares the same dep. Verified on an RTX 4090 laptop cuda-oxide build: these two cut the vortx-shaders device-build errors 62 -> 35, with the remainder isolated to one file (reduce.rs shared-memory glue), unrelated to no_std. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Workspace [patch.crates-io] redirects + cuda-oxide feature so vortx-shaders compiles for nvptx64 via the cuda-oxide backend into a native cubin. Pairs with cuda-oxide branch feat/nexus3d-vortx-native-cuda-5060-fixes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EvzrSDVTgXiymMWuhT4p5W
…eductions
- reduce: keep the typed decl_reductions! kernels (host consumes
ReduceAdd{F32,I32,U32} etc.) — now buildable on cuda-oxide thanks to the
generic SmemBuf; replace StepRng with Range::step_by; take the workspace as
&mut impl MaybeIndexUnchecked<T> in the tree-reduce helpers so both the
SPIR-V array param and the CUDA SmemBuf wrapper fit.
- op_assign/contiguous: StepRng -> step_by.
- shape/op_assign: gate bytemuck derives on not(spirv|nvptx64) instead of the
rust-gpu-only target_arch_is_gpu cfg.
- mod: exclude obs/reward from the nvptx device build (host-side on CUDA).
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
1 participant
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.
Draft for discussion — the vortx piece of the native-CUDA (cuda-oxide) stack (companions: dimforge/khal#9 and the dimforge/nexus draft).
What's in here
vortx-shadersbuilds cleanly for thenvptx64-nvidia-cudadevice target under the cuda-oxide codegen backend (nospirv-std-only assumptions).cuda-oxidecargo feature forwarding tokhal-std/cuda-oxide, so shader crates depending on vortx-shaders (e.g. nexus's) can enable the device backend uniformly.The resulting
.llcompiles to a sm_120 cubin via llvm-link(libdevice) → llc → ptxas and is consumed by hosts through khal-builder'sCUDA_OXIDE_SHADERS_PTX_VORTX_SHADERSprebuilt escape hatch.Blocked on upstream cuda-oxide
NVlabs/cuda-oxide #350, #358, #360 — until merged, the codegen backend
.socomes fromhaixuanTao/cuda-oxidebranchfeat/nexus3d-vortx-native-cuda.🤖 Generated with Claude Code