Constant DEVICES 

pub const DEVICES: &[DeviceParams];

Ascending by compute capability. A test enforces both the order and the internal consistency of every row.

Why this is not shared with reconverge

reconverge’s cc.rs carries a capability table too, and #52 asked whether a shared simt-device-table crate should own both. The answer for 2.2.0 is no, for three reasons:

1. They answer different questions. reconverge needs max_per_block — the dynamic opt-in ceiling — because RC004 asks “could this allocation ever load”. This needs per-SM occupancy capacity: threads, warps, blocks and shared memory per SM. Only shared memory overlaps at all, and even there the numbers differ by the 1 KiB the driver reserves on Ampere and later.

2. It would be a third pin. A shared crate joins the lockstep set, in a project whose headline 2.2.0 issue was that the pin set went 133 commits stale. Adding a pin to reduce duplication of eleven numbers is a poor trade.

3. The drift is checkable without it. The overlapping figures were cross-checked by hand against reconverge 0.6.0’s table when these rows were written, and they agree exactly, per-SM minus the reserved KiB:

   cc	reconverge max_per_block	here smem_per_sm
   7.5	64 KiB	64 KiB (no reservation pre-Ampere)
   8.0	163 KiB	164 KiB
   8.6	99 KiB	100 KiB
   8.9	99 KiB	100 KiB
   9.0	227 KiB	228 KiB
   10.0	227 KiB	228 KiB

Revisit if a third consumer appears, or if the two tables are ever found to disagree — that would be the evidence this reasoning is wrong.