feat(cuda): report device identity and compiled architecture

[NicolasRouquette]

Why

A benchmark or a sizing decision that cannot name the device it ran on produces a number that cannot be filed beside another one. Buffer.allocatorStats already answers how much device memory there is; nothing answered which device, and nothing answered which architectures the binary actually holds native code for.

The second gap is the one that bites quietly. Device code is compiled for an architecture, and with no -arch the toolkit applies its own default. A binary built that way still runs on a newer GPU — through forward PTX JIT — so nothing fails and nothing warns. The timings are then of JIT-generated code for an architecture the compiler was never told about, which is a different measurement from the one a reader will assume.

What

• Buffer.deviceInfo : IO (Option DeviceInfo) over cudaGetDeviceProperties: name, index, compute capability, SM count, core and memory clocks, memory bus width, total memory, driver and runtime versions.
• DeviceInfo.peakBandwidthGBs, so a row reporting achieved GB/s can be read as a fraction of the roofline without the reader looking the card up.
• Buffer.compiledArchList — the binary's own __CUDA_ARCH_LIST__ ("860", "750,860") — and DeviceInfo.runsNatively. DeviceInfo.format prints the mismatch as a warning:

NVIDIA RTX A4500 (device 0, sm_86, 56 SMs, 19.5 GiB, ~640 GB/s peak, driver 13.0, runtime 12.6) [WARNING: compiled for 520, NOT sm_86 — running via PTX JIT]

That line is not hypothetical — it is the first thing the check reported on the machine it was written on.

Shape of the change

Properties are queried once under pthread_once and cached; cudaGetDeviceProperties is comparatively expensive and its answer cannot change for a device index.

In the CPU stub, and in a CUDA build on a host where no device answers, the name is empty and every scalar is 0, so deviceInfo returns none. A caller therefore prints one line under either build flavour and reads the absence off the fields rather than off its own build flavour.

Additions only — 4 files, no existing declaration or symbol changed. The stub carries the matching definitions so the parity build keeps linking.

Testing

Built and run both flavours on an RTX A4500 (sm_86, CUDA 12.6, driver 13.0):

• CPU stub: deviceInfo returns none, the caller's line reads as absence.
• CUDA, no -arch: reports the device correctly and flags compiled for 520, NOT sm_86.
• CUDA, TORCHLEAN_CUDA_ARCH=sm_86: warning gone, reads [compiled for 860].

Measured cost of the JIT for the workload in hand: none (24.47 ms against 23.29 ms, within run-to-run scatter). The point is that it was not knowable before.

🤖 Generated with Claude Code