# RTX 4060 Ti 16GB (10de:2805) Ada canary

On October 24, 2026, the AD102-family four-PLM payload ran on one
RTX 4060 Ti 16GB (`10de:2805`, AD106, 34 SMs) before the unmodified NVIDIA
`595.99.02` driver. Every gate the module enforces passed and the NVIDIA RM
getter changed FMLA32, IMLA2 and IMLA4 from half to full rate. This is one
physical card and one cold boot. No same-card stock throughput run has been made,
so this report does not yet show a matched speedup. It does not establish
support for other AD106 boards or the 8 GB variant.
The [evidence directory](evidence/ada2805/README.md) contains the selected boot
messages, rate readbacks and unedited benchmark stdout with the GPU UUID
replaced.

The host ran Ubuntu 26.04.1 with kernel `7.0.0-38-generic`. Its initramfs is
generated by dracut, which ignores the initramfs-tools drop-in; the Debian
package now also ships the dracut drop-in, without which `gpu_unlock` was
absent from the initramfs. The module was built by DKMS from commit
`3d7814e` (kernel logic) plus that packaging change, signed with the host's
local MOK key, so its `.ko` hash is host-specific and not recorded here.
The boot used the **single exact PCI target** and `ad106_experimental=1`.
The card owner performed a full power-off before this first attempt and
confirmed it was a cold boot; the module's entry readback reported WPR2 high
`0x0`.

## Firmware and driver checks

The module loaded the pinned NVIDIA `610.43.03` stock AD102 Booter/GSP assets
and the generated 64,000-byte payload. The kernel log recorded:

- entry: `SS0=0x1403041`, `SS1=0x3`, WPR2 high `0x0`, chip `0x196000a1`;
- payload marker `0x67b00001` (expected `0x67b00001`), SEC2 halted;
- the three required permission writes: `WPR_CFG=0xfffff0ff`,
  `WPR=0xffffffff`, `FEAT=0xffffffff`. The observational FBPA field stayed
  `0xffffff0f`, as on the 2705;
- selector writes read back `SS0=0x88888888` and `SS1=0x8`, and the
  effective readout changed from fields `0 0 2 0 0 2 0 2 0` to all zero;
- after PCIe FLR the selectors were still `SS0=88888888 SS1=00000008`;
- `gpu_unlock: unlocked`.

The stock driver then loaded and CUDA kernels completed. The current-boot
kernel log contained no NVRM Xid or GPU-fallen-off message.

The read-only RM getter reported:

| Field | Before | After |
| --- | ---: | ---: |
| FMLA32 | 1 (half) | 0 (full) |
| IMLA2 | 1 (half) | 0 (full) |
| IMLA4 | 1 (half) | 0 (full) |
| IMLA0, FMLA16, DP, FFMA, IMLA1, IMLA3 | 0 | 0 |

The "before" values were read on the same card and driver in an earlier boot,
before this build was installed; the stock 1.1.1 module present then does not
accept `10de:2805`.

## Unlocked instruction rates

`diagnostics/bench/tensor_modes_issue.cu` was built with CUDA 13.4 for `sm_89`
(cubin SHA-256
`33aa6db385aa9eb8a1f73bb2f74891aea84794326b7c40992bc642f93a3c614d`) and run
at the card's default 165 W cap with 20,000 iterations and three repetitions:

| Mode | Best rate | Mismatches |
| --- | ---: | ---: |
| FP16 → FP32 accumulate | 91.0 TF/s | 0 / 270,336 |
| TF32 → FP32 accumulate | 46.9 TF/s | 0 / 270,336 |
| Unsigned INT4 → INT32 | 374.9 TOP/s | 0 / 270,336 |

An earlier run on the same boot measured 93.9 TF/s for FP16/FP32; FP16
repetitions rise as clocks ramp. 91.0 TF/s corresponds to the full 1,024
FP16 FLOP per clock per SM at about 2.6 GHz.

INT4 did not change between stock and unlocked on the 2705, so it serves as a
clock-normalised reference. The FP16/FP32-to-INT4 ratio was 0.126 stock and
0.252 unlocked on the 2705; here it is 0.243. This is an inference from a
different chip, not a measured stock comparison on this card.

## Not yet done

- a stock boot on the same card with the same cubin and power cap;
- a cold-boot repeat and warm-reboot behaviour;
- GEMM numerical validation (`validate_gemm.cu`) and application workloads;
- other 2805 boards and the 8 GB variant.