Tesla P40 under WSL2: MCDM driver model is the missing piece (+ sm_61 build, Qwen3.6 benchmarks)

[schmared]

Posting this because the failure mode wasted a lot of my time and the fix isn't documented anywhere I could find.

The problem

A Tesla P40 in TCC driver model is invisible to WSL2, but it doesn't look like a driver-model problem — it looks like a broken CUDA install:

• nvidia-smi works fine on the Windows side
• /dev/dxg exists inside WSL
• /usr/lib/wsl/lib/ is fully populated — libcuda.so.1, nvidia-smi, etc.
• but nvidia-smi in WSL returns Failed to initialize NVML: N/A

(/dev/dxg was being provided by an AMD iGPU, which is what makes this so misleading.) You can reinstall CUDA all day and never fix it.

The fix

WSL2 GPU-PV rides on the WDDM/DirectX stack, and a TCC GPU isn't exposed to it. WDDM isn't available on Tesla cards — current drivers require a GRID license, and nvidia-smi -dm 0 returns Not Supported.

MCDM works:

nvidia-smi -dm 2   # 0=WDDM, 1=TCC, 2=MCDM. Elevated. Requires reboot.

After the reboot the P40 shows up in WSL2 and CUDA compute works normally.

This was on driver 582.70, which surprised me — MCDM/WSL2 support is usually described as arriving in R595, and Pascal predates MCDM entirely. NVIDIA's CUDA on WSL guide says acceleration "will not be available on Quadro GPUs in TCC mode or Tesla GPUs yet," which reads as "Tesla is out." Apparently not, via MCDM.

If your P40 vanishes from WSL later, check the driver model first — a Windows driver update can reset it to TCC.

Building llama.cpp for sm_61

Two things worth knowing:

• CUDA 13.x cannot target Pascal at all (offline compilation for sm_61 was removed in 13.0). You need CUDA 12.x — I used 12.9.2.
• On glibc 2.41+, CUDA 12.9 won't compile: glibc added C23 sinpi/cospi/rsqrt declared noexcept(true), colliding with CUDA's headers. NVIDIA fixed this in 13.2.1 — which can't target Pascal — so there's no 12.x release with the fix. Arch and Gentoo patch the header; I did the same.
• Building the CUDA backend in Docker needs the libcuda stub linked, because the real libcuda.so.1 is injected only at runtime by the container toolkit. Otherwise you get undefined reference to 'cuMemCreate'.

Build flags that matter on Pascal:

-DCMAKE_CUDA_ARCHITECTURES=61 -DGGML_CUDA_FORCE_MMQ=ON -DGGML_CUDA_F16=OFF

MMQ routes matmuls through INT8/DP4A rather than cuBLAS FP16 — the P40 does ~47 TOPS INT8 but only ~183 GFLOPS FP16 (1:64 of its FP32 rate).

Results — Qwen3.6-35B-A3B, Q3_K_XL, single P40

Qwen3.6's hybrid Gated DeltaNet operators do work on sm_61, which I couldn't find documented either way.

Generation: 51.6 tok/s with MTP at --spec-draft-n-max 2.

Prefill: 982 tok/s on llama-bench pp512. Treat that number with care — it's a 512-token benchmark and it is not representative of long prompts. Real-world prefill degrades substantially with context length on this card: ~790 tok/s at 6K tokens, 422–609 at 25K, and ~216 at 78K. See the long-context section below.

MTP draft depth, everything else identical:

--spec-draft-n-max	tok/s
baseline (no MTP)	37.9
6	34.5
4	41.9
3 (default)	48.3
2	51.6

Default depth 3 is not optimal here and depth 6 is worse than no MTP at all. Every rejected draft token is wasted compute, and compute is exactly where Pascal is weak, so the optimum is shallower than on modern cards.

Control run: MTP weights with speculation disabled measured 38.3 tok/s, i.e. baseline — which is what confirms the gain is real speculative decoding and not model-file variance.

Note the flag is --spec-type draft-mtp, not --spec-type mtp as several tutorials state.

Context is nearly free on this architecture

Context	VRAM	Generation
4096 (KV f16)	21710 MiB	51.45 tok/s
32768 (KV q8_0)	22086 MiB	50.79 tok/s
131072 (KV q8_0)	22782 MiB	50.54 tok/s

32× the context for ~1 GB. Gated DeltaNet keeps fixed-size recurrent state instead of a growing KV cache on most layers, so normal transformer KV scaling doesn't apply.

The real cost of long context here is prefill time, not memory. At ~216 tok/s for a 78K-token prompt that's roughly 6 minutes to first token. Generation stays fast once it starts, so this suits documents you query repeatedly (prefix caching helps) far better than one-shot huge prompts.

Verified with needle-in-a-haystack rather than assuming — 9/9 exact retrievals at 6K/25K/78K tokens, needle at 10%/50%/90% depth. A server will happily allocate a 128K cache it can't actually use.

Scripts

Setup scripts, Dockerfile, the glibc patch, and both benchmark harnesses:
https://github.com/schmared/tesla-p40-wsl2-cuda-llamacpp

Caveat: all of this is one machine, one GPU, one model. P100 is sm_60 and untested. Treat it as "this worked on a P40," not a general Pascal claim.