Windows MSVC support fork and signed release artifacts

Hi! I have been working on a Windows-support fork of cuda-oxide here:

https://github.com/ansidium/cuda-oxide-windows

The fork keeps the Linux path upstream-compatible while adding an experimental native Windows MSVC path. The first signed Windows release is published here:

https://github.com/ansidium/cuda-oxide-windows/releases/tag/windows-v0.2.0

Current Windows scope:

Target: x86_64-pc-windows-msvc.
Windows GNU is intentionally out of scope.
Windows CI canary on windows-latest without a live GPU.
Side-by-side cargo-oxide.exe + rustc_codegen_cuda.dll release layout.
CUDA Toolkit / NVVM / nvJitLink discovery improvements for Windows paths.
Windows smoke script and documentation.

I do not want to open one large PR that mixes fork branding, release packaging, CI, docs, and portability fixes. If you are open to upstreaming any of this, I can split the work into smaller PRs, for example:

Cross-platform path and dynamic-library naming helpers.
CUDA Toolkit / NVVM / nvJitLink discovery improvements.
Windows-safe cargo oxide command/path handling.
Windows CI no-GPU compile canary.
Windows setup docs.

Would any of these be useful upstream? If so, which order and scope would you prefer?

Thanks really needed, subscribed to your repo

Thanks for the detailed write-up, and for keeping the fork close to upstream.

Just so that I don't set the wrong expectations: we have not decided whether we can support Windows, and we may not be able to. The questions below are only to understand what supporting it would actually cost, before we commit either way.

Ongoing upkeep: The main codebase changes fast. It's already ~110 commits past your fork's last sync point, and every one of those changes is something a Windows build has to keep working against. How often do you currently have to fix the Windows build after pulling our changes in, and who would own that upkeep if it lived upstream?
Catching Windows breakage: GitHub's Windows runners have no GPU, and today even your fork's automatic CI doesn't rebuild the codegen backend (the part with the linker/export-limit problem) on every change. If a Windows-only break slipped into our main, what would catch it before a release?
Running on a real GPU: Actually running kernels on Windows needs a physical Windows machine with an NVIDIA GPU. We don't have one in CI. Is there a machine the project could rely on for that, or is Windows execution simply something we could never test automatically?
Scope: Of your proposed changes, which ones also help (or at least don't affect) Linux, and which are purely Windows-only? That helps us see how much of this is low-risk no matter where the Windows decision lands.

Thanks, that makes sense.

Quick update: I rebased the Windows fork onto current upstream/main (56b843f) and used that sync as a real canary. It exposed a few rebase conflicts plus one DeviceBuffer compile fallout from the recent async-free changes; those are fixed now.

Upkeep: I can own the Windows upkeep for the fork/PR path and keep it rebased regularly. This latest sync was useful because it showed the actual kind of maintenance needed.
Catching breakage: I strengthened the regular hosted Windows CI. It now installs CUDA + libffi, builds cargo-oxide, tests oxide-artifacts, runs cargo oxide setup, and compile-checks vecadd with cargo oxide build vecadd --arch sm_75. Latest run is green: https://github.com/ansidium/cuda-oxide-windows/actions/runs/27791763718
Real GPU: We do have Windows NVIDIA GPU hardware available for manual/runtime validation. It is not set up as an always-on CI runner today, so fully automatic GPU execution would still require a reliable self-hosted Windows NVIDIA runner.
Scope: The sync/DeviceBuffer repair and general platform-path cleanup are Linux-neutral; the MSVC backend packaging, ffi.lib discovery, and Windows CI setup are Windows-only. I can split any upstreamable work that way if helpful.

No new Windows release is needed right now, since upstream's latest release is still v0.2.1; the current fork release remains windows-v0.2.1.

I opened #1173 as a narrow follow-up to this issue.

Since #330 already addressed the cargo-oxide backend target-directory and host dylib-path handling, #1173 is limited to making runtime discovery in libnvvm-sys and nvjitlink-sys platform-aware.

It preserves the existing Linux discovery behavior and adds Windows/MSVC CUDA Toolkit DLL candidates with deterministic tests for the discovery logic.

It intentionally does not include COFF support, cargo-oxide Windows command handling, codegen backend changes, Windows CI, packaging, or claim full Windows support.

I kept it separate so the library-discovery change can be reviewed independently from the broader Windows-support decision.

@uurl

Thanks @uurl. I reviewed #1173 and the closure feedback.

To make ownership explicit: I can maintain the Windows/MSVC runtime-discovery code and its hosted Windows CI if this scope is accepted upstream. This includes keeping the lane green as main changes and submitting fixes for Windows regressions.

The implementation now uses one shared discovery component for libnvvm-sys and nvjitlink-sys. It preserves the Linux discovery order, enumerates installed Windows Toolkit roots without a release table, compares Toolkit and DLL versions numerically, matches Windows DLL names case-insensitively, and verifies the exact loaded file.

The mandatory windows-latest lane installs CUDA, runs the shared discovery tests, loads libNVVM and nvJitLink from fingerprintable files, builds the backend, and materializes a vecadd cubin without a GPU:
ansidium@c930cd3f
https://github.com/ansidium/cuda-oxide-windows/actions/runs/32730586257

Would this be sufficient for a fresh minimal PR from current main?

fix: use zero padding for read-only tile-like loads (NVIDIA#139)

The fork is now ansidium/cuda-rust-windows. It is synced through upstream a0cc6cc, including the monorepo layout and shared host crates.

Windows CI for x86_64-pc-windows-msvc runs automatically on pushes to main and pull requests targeting main. It tests CUDA library discovery and loading, builds the codegen backend, and materializes a vecadd cubin. The latest Windows run passed, and all nine workflows passed on f3738d887.

Scripted GPU tests run on demand on a local RTX 4080, outside hosted CI. Checks passed with Rust 1.99.0 and CUDA 13.4.2, including reference-validity kernels with and without debug assertions.

I can maintain the shared discovery code and hosted Windows CI lane.

feat(cuda-oxide): add Windows x86_64 MSVC support (NVIDIA#1770)

Navigation Menu

Repository navigation

Windows MSVC support fork and signed release artifacts #139

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows MSVC support fork and signed release artifacts #139

Description

Activity

egorsmkv commented on Jun 9, 2026

nihalpasham commented on Jun 18, 2026

ansidium commented on Jun 18, 2026

uurl commented on Aug 23, 2026

ansidium commented on Aug 24, 2026

ansidium commented on Oct 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions