The Blackwell Compatibility Check: A Pivotal Moment of Due Diligence in GPU Proving Infrastructure

Introduction

In the course of building a production-grade SNARK proving daemon for Filecoin, an assistant encountered a critical juncture: would the GPU acceleration libraries underpinning the entire proof generation pipeline actually work with the available hardware? Message [msg 202] captures this moment of technical due diligence — a brief but analytically dense message in which the assistant examines the build systems of two competing GPU backends (supraseal-c2 and bellperson) to determine whether they support the NVIDIA RTX 5070 Ti's Blackwell architecture (compute capability 12.0). Though only a few lines of reasoning and a single bash command, this message represents a decision point where the assistant's understanding of build system internals, CUDA compilation toolchain behavior, and GPU architecture compatibility directly determined the feasibility of the next phase of work.

The Message in Full

The subject message reads:

The sppark build system doesn't explicitly filter architectures — it uses cc::Build with .cuda(true) which lets nvcc choose the default architecture. With CUDA 13.1 and an sm_120 GPU, nvcc should handle this. Let me also check if bellperson/ec-gpu uses rust-gpu-tools which might have device filtering:

>

``bash find ~/.cargo/registry/src -path "*/rust-gpu-tools*" -name "*.rs" 2>/dev/null | xargs grep -l "compute_cap\|min_cc\|sm_" 2>/dev/null | head -5 ``

>

Output: `` /home/theuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rust-gpu-tools-0.7.2/examples/add.rs /home/theuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rust-gpu-tools-0.7.2/src/cuda/mod.rs /home/theuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rust-gpu-tools-0.7.2/src/cuda/utils.rs /home/theuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rust-gpu-tools-0.7.2/src/device.rs /home/theuser/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rust-gpu-tools-0.... ``

This message is the culmination of a chain of investigation spanning the previous five messages ([msg 197] through [msg 201]), in which the assistant systematically inspected the build scripts of supraseal-c2, bellperson, sppark, and ec-gpu-gen to assess Blackwell compatibility.

Why This Message Was Written: The Reasoning and Motivation

The motivation for this message is deeply rooted in the practical realities of GPU-accelerated SNARK proving. The cuzk daemon, which the assistant has been building across multiple sessions, relies on either the supraseal-c2 crate (an optimized GPU prover from Supranational) or the bellperson crate (the reference GPU prover) to perform the heavy computational work of Groth16 proof generation. Both of these libraries compile CUDA kernels at build time using nvcc, and both may have implicit or explicit constraints on the target GPU architecture.

The assistant's reasoning chain began in [msg 197] with the observation that the RTX 5070 Ti is a "Blackwell-class GPU (sm_120)." This immediately raised a compatibility question. Blackwell (compute capability 12.0) is a relatively new architecture — at the time of this session, it was early 2026, and Blackwell GPUs had only recently been released. The GPU proving libraries in the Filecoin ecosystem were originally written for earlier architectures (sm_70 for Volta, sm_75 for Turing, sm_80 for Ampere). Would they compile and run correctly on sm_120?

The assistant's first move was to check whether supraseal-c2 explicitly filters GPU architectures ([msg 199]). It located the crate's build.rs and read it. The build script uses sppark::build::ccmd() to obtain an nvcc command builder, then compiles groth16_cuda.cu. Critically, the assistant noted that the build script does not pass any -arch flag to nvcc. This means nvcc will use its default architecture — which, for CUDA 13.1, is typically the newest architecture the toolkit supports.

In [msg 200], the assistant read the actual supraseal-c2 build script and confirmed this analysis. The script is remarkably simple: it obtains an nvcc command, defines FEATURE_BLS12_381, applies BLST flags, and compiles a single CUDA source file. No architecture filtering whatsoever.

Then in [msg 201], the assistant checked sppark's build script to confirm the same pattern. The sppark build system also delegates to cc::Build with .cuda(true), which lets nvcc choose the default architecture. The assistant's conclusion: "The sppark build system doesn't explicitly filter architectures."

This brings us to the subject message ([msg 202]). The assistant synthesizes the findings so far: because sppark uses cc::Build without specifying an architecture, nvcc will compile for its default target. With CUDA 13.1 and an sm_120 GPU, the default architecture should be at least sm_80 or higher — and given that CUDA 13.1 is a very recent toolkit, it likely defaults to sm_90 or sm_100. The assistant reasons that "nvcc should handle this" — a reasonable inference, but one that carries risk. The message then pivots to a secondary concern: what about the bellperson backend, which uses rust-gpu-tools for device management? Does that library have runtime device filtering that might reject a Blackwell GPU?

The Decision Process and Assumptions

The assistant's decision-making in this message is subtle but important. Rather than simply attempting a build and hoping for the best, the assistant performs a structured compatibility assessment with three layers:

  1. Build-time filtering: Does the build script explicitly restrict which GPU architectures the CUDA kernels are compiled for? (Answer: No — sppark and supraseal-c2 let nvcc choose the default.)
  2. Runtime filtering: Does the library check the GPU's compute capability at runtime and refuse to run on unsupported architectures? (Answer: Unknown — this is what the assistant is checking next by examining rust-gpu-tools.)
  3. Fallback path: If supraseal-c2 doesn't work on Blackwell, can the assistant fall back to the bellperson CUDA backend? (This is the implicit question driving the investigation of both backends.) The key assumption in this message is that nvcc's default architecture will produce code compatible with sm_120. This is a reasonable assumption but not guaranteed. CUDA has a concept of "forward compatibility" — code compiled for sm_80 (Ampere) can run on sm_90 (Hopper) and sm_100 (Blackwell) because newer architectures are supersets of older ones. However, the reverse is not true: if nvcc defaults to sm_90 and the Blackwell GPU requires sm_100-specific features, there could be issues. The assistant's confidence likely stems from the fact that the CUDA kernels in question are relatively standard elliptic curve and NTT operations that don't rely on architecture-specific features like Tensor Cores or DPX instructions. Another assumption is that rust-gpu-tools is the primary mechanism by which bellperson might filter devices. The assistant searches for patterns like compute_cap, min_cc, and sm_ in the rust-gpu-tools source tree. The presence of matches in cuda/mod.rs, cuda/utils.rs, and device.rs suggests that there is indeed some form of compute capability checking, but the assistant doesn't yet know whether it's restrictive or permissive.

Input Knowledge Required

To understand and produce this message, the assistant drew on several domains of knowledge:

Output Knowledge Created

This message produces several important pieces of knowledge:

  1. Confirmed: The sppark build system (used by supraseal-c2) does not filter GPU architectures at build time. This means the CUDA kernels will be compiled for nvcc's default architecture, which with CUDA 13.1 should be compatible with Blackwell.
  2. Confirmed: The rust-gpu-tools library (used by bellperson) does contain files that reference compute capability, minimum CC, and SM architecture patterns. This means there may be runtime device filtering that could reject a Blackwell GPU.
  3. Decision point: The assistant has enough information to proceed with building using supraseal-c2 (which appears safe), but needs to investigate rust-gpu-tools further before committing to the bellperson backend.
  4. Risk assessment: The Blackwell compatibility risk is lower for supraseal-c2 than for bellperson, because supraseal-c2 doesn't filter architectures at any level, while bellperson may have runtime checks.

Mistakes and Incorrect Assumptions

The assistant's analysis in this message is sound, but there are potential pitfalls worth examining:

The "nvcc default architecture" assumption: The assistant assumes that nvcc's default architecture will produce code compatible with sm_120. However, CUDA's default architecture is not always the newest one — it depends on the CUDA toolkit version and how it was configured. For CUDA 13.1, the default is likely sm_90 (Hopper) or possibly sm_100. While sm_100 code should run on sm_120 (Blackwell), there's a subtlety: Blackwell is actually sm_120, not sm_100. NVIDIA's compute capability numbering isn't always sequential with architecture generations. The assistant's reasoning that "nvcc should handle this" is a best-effort inference, not a guarantee.

The scope of the search: The assistant searches for compute_cap, min_cc, and sm_ in rust-gpu-tools source files. These patterns might miss other forms of device filtering, such as environment variables, feature flags, or runtime library version checks. The search is a reasonable heuristic but not exhaustive.

The binary choice between backends: The assistant implicitly treats supraseal-c2 and bellperson as the only two options. In reality, there might be a third path: using the CPU-only prover (which would be slow but functional) or patching one of the GPU backends to support Blackwell. The assistant doesn't consider these fallbacks explicitly in this message.

The Thinking Process Visible in the Reasoning

What makes this message particularly interesting is the visible structure of the assistant's reasoning. It follows a clear pattern:

  1. Synthesize previous findings: "The sppark build system doesn't explicitly filter architectures — it uses cc::Build with .cuda(true) which lets nvcc choose the default architecture."
  2. Draw a conclusion: "With CUDA 13.1 and an sm_120 GPU, nvcc should handle this."
  3. Identify remaining uncertainty: "Let me also check if bellperson/ec-gpu uses rust-gpu-tools which might have device filtering."
  4. Execute a targeted investigation: The bash command to search for device filtering patterns in rust-gpu-tools. This pattern — synthesize, conclude, identify gaps, investigate — is characteristic of thorough technical reasoning. The assistant doesn't stop after confirming that supraseal-c2 is safe; it immediately identifies the parallel concern about bellperson and begins investigating that as well. This reflects an understanding that the two backends are independent and both need to be assessed. The bash command itself reveals the assistant's investigative strategy. Rather than reading every file in rust-gpu-tools, it uses targeted grep patterns (compute_cap, min_cc, sm_) to quickly identify files that might contain architecture filtering logic. The output shows five matching files, which the assistant can then inspect more closely in subsequent messages.

Broader Context and Significance

This message sits at a critical transition point in the cuzk project. The assistant has just verified that the workspace compiles cleanly without CUDA features ([msg 195]), confirmed that the test data and parameters are in place, and identified the RTX 5070 Ti as the target GPU. The next step is to build with CUDA features and run a real proof. But before committing to a build that could take 30-60 minutes (compiling CUDA kernels for a 45 GiB parameter set), the assistant is doing due diligence to ensure the build won't fail due to architecture incompatibility.

This is the kind of pragmatic engineering decision-making that distinguishes robust development workflows from fragile ones. The assistant could have simply run cargo build --features cuda-supraseal and waited for the result, but instead it invested a few minutes in upfront analysis to assess the likelihood of success. This investment paid off: the subsequent build succeeded ([msg 203] onward), and the assistant was able to run the first end-to-end GPU proof, achieving a 20.5% speedup from SRS residency.

The message also illustrates the importance of understanding the build systems of dependencies. Many developers treat build scripts as black boxes, but the assistant's willingness to read build.rs files for supraseal-c2, sppark, bellperson, and ec-gpu-gen reveals a deeper understanding of how the software stack is assembled. This knowledge proved essential for assessing compatibility with a cutting-edge GPU architecture that the library authors may not have tested against.

Conclusion

Message [msg 202] is a compact but revealing artifact of the engineering process behind the cuzk proving daemon. In just a few lines of reasoning and a single bash command, the assistant synthesizes findings from multiple prior investigations, draws a reasoned conclusion about Blackwell compatibility for one GPU backend, identifies a remaining uncertainty about the other backend, and initiates a targeted investigation to resolve it. The message exemplifies the kind of structured, risk-aware thinking that separates robust infrastructure development from fragile prototyping. It is a small but pivotal moment in a much larger effort — the moment when the assistant decided that yes, this should work, and proceeded to build the GPU proving pipeline that would ultimately validate the entire cuzk architecture.