@graphty/webgpu-graph-algorithms 0.5.1 → 0.6.1

package/README.md

@@ -3,20 +3,24 @@
 WebGPU-accelerated graph algorithms and layouts over the `@graphty/graph-format` snapshot, for Node
 (Dawn, through the `webgpu` npm package) and browsers (Chromium). One code base, three entry points:
 
-| Entry                                      | Import        | What it gives you                                                                                                                                                                                                                                       |
-| ------------------------------------------ | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `@graphty/webgpu-graph-algorithms`         | the core      | `createForceAtlas2`, `createAccelerator`, `GpuContext`, `degree`, `seedPositions`, `WebGpuGraphError`, `isSoftwareAdapter`, the constants (`EXACT_MAX_NODES`, `FA2_DEFAULTS`, `LAYOUT_TUNING_DEFAULTS`, ...) and the option / stats / accelerator types |
-| `@graphty/webgpu-graph-algorithms/node`    | Node only     | `createNodeGpuContext`, `probeNodeWebGpu`, `createNodeGpu` (Dawn), `dawnFlags`                                                                                                                                                                          |
-| `@graphty/webgpu-graph-algorithms/browser` | browsers only | `probeBrowserWebGpu`, `requestGpuContext`                                                                                                                                                                                                               |
-
-**Status: phase P3 (ForceAtlas2, exact tier).** The GPU ForceAtlas2 is usable from Node (`run()`) and from a
-browser frame loop (`step()` once per frame) up to `exactMaxNodes` = 32768 nodes with the default
-`repulsion: "auto"`, and at any size with `repulsion: "exact"` (all pairs, O(n^2) per iteration: 18.971 ms per
-iteration at 100k nodes / 1M edges on an RTX 4070 SUPER). The grid tier for 10^5-10^6 nodes (P4),
-Fruchterman-Reingold (P5) and the algorithms (P7+) follow the phase plan of `design/webgpu/webgpu-acceleration-plan.md` (monorepo root)
-section 13 and the interface contract `design/webgpu/plans/2026-09-14-webgpu-p0-p3-interfaces.md`; the gate
-record of this phase is `docs/decisions/G3.md`. There is no CPU fallback anywhere in this package: when no
-adapter or device exists it throws `WebGpuGraphError`.
+| Entry                                      | Import        | What it gives you                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |
+| ------------------------------------------ | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `@graphty/webgpu-graph-algorithms`         | the core      | the layouts (`createForceAtlas2`, `createFruchtermanReingold`, `createSpringElectrical`, `seedPositions`), the algorithms (`pageRank`, `personalizedPageRank`, `hits`, `eigenvectorCentrality`, `katzCentrality`, `connectedComponents`, `degree`), `createAccelerator`, `calibrateLayout`, `verifyDevice`, `GpuContext`, `WebGpuGraphError`, `isSoftwareAdapter`, the constants (`EXACT_MAX_NODES`, `FA2_DEFAULTS`, `FR_DEFAULTS`, `SE_DEFAULTS`, `LAYOUT_TUNING_DEFAULTS`, ...) and the option / stats / accelerator types |
+| `@graphty/webgpu-graph-algorithms/node`    | Node only     | `createNodeGpuContext`, `probeNodeWebGpu`, `createNodeGpu` (Dawn), `dawnFlags`                                                                                                                                                                                                                                                                                                                                                                                                            |
+| `@graphty/webgpu-graph-algorithms/browser` | browsers only | `probeBrowserWebGpu`, `requestGpuContext`                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+
+**Status: three force layouts and six algorithms, on the exact and the grid repulsion tiers.**
+ForceAtlas2, Fruchterman-Reingold and ngraph's spring-electrical preset run from Node (`run()`) and from a
+browser frame loop (`step()` once per frame) at any size: the default `repulsion: "auto"` runs the exact tier
+up to `exactMaxNodes` = 32768 nodes (owner decision G4-D1 in `docs/decisions/G4.md`) and the grid tier above
+it; `repulsion: "exact"` forces all pairs at any size (O(n^2) per iteration: 18.971 ms per iteration at 100k
+nodes / 1M edges on an RTX 4070 SUPER) and `repulsion: "grid"` forces the grid tier. PageRank, personalized
+PageRank, HITS, eigenvector centrality, Katz centrality and weakly connected components run as plain async
+calls on the same context. The phases follow the phase plan of
+`design/webgpu/webgpu-acceleration-plan.md` (monorepo root) section 13 and the interface contract
+`design/webgpu/plans/2026-09-14-webgpu-p0-p3-interfaces.md`; the gate records are `docs/decisions/G<n>.md`.
+There is no CPU fallback anywhere in this package: when no adapter or device exists it throws
+`WebGpuGraphError`.
 
 ## Install
 
@@ -61,8 +65,8 @@ ctx.release(snapshot); // destroys the snapshot's buffers (nothing is freed by G
 ctx.dispose(); // destroys the device and lets the process exit
 ```
 
-Sizes above `exactMaxNodes` need `repulsion: "exact"` until the grid tier lands (P4); with the default
-`"auto"` the simulation rejects `load()` with `E_UNSUPPORTED { feature: "repulsion.grid" }`. The same run
+Above `exactMaxNodes` the default `"auto"` picks the grid tier (spec 7.8: by n alone); `repulsion: "exact"`
+keeps the all-pairs tier at any size and `repulsion: "grid"` picks the grid tier at any size. The same run
 from the command line, with a verification of the result:
 
 ```bash
@@ -85,7 +89,7 @@ if (!probe.ok) {
     throw new Error(`${probe.code}: ${probe.reason ?? ""}`); // E_NO_WEBGPU, E_NO_ADAPTER or E_SOFTWARE_ONLY
 }
 const ctx = await requestGpuContext({ adapter: probe.adapter ?? undefined });
-const acc = createAccelerator(ctx, { layout: { exactMaxNodes: 32768 } }); // the tuning every simulation inherits
+const acc = createAccelerator(ctx, { layout: { exactMaxNodes: 4096 } }); // the tuning every simulation inherits
 const sim = acc.forceAtlas2({ seed: 1, iterationsPerStep: 1, maxInFlight: 2 });
 sim.load(snapshot, positions); // positions: your stride-3 Float32Array; NaN rows are seeded
 
@@ -146,13 +150,13 @@ names and defaults as the CPU port in `@graphty/layout`) plus the GPU tuning:
 GPU tuning (`GpuLayoutTuning`; also the `layout` field of `createAccelerator`'s options, inherited by every
 simulation the accelerator creates):
 
-| Option                                              | Default                 | Meaning                                                                                                                                    |
-| --------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
-| `repulsion`                                         | `"auto"`                | `"exact"` at any n; `"auto"` = exact iff n <= `exactMaxNodes`; `"grid"` is `E_UNSUPPORTED` until P4                                        |
-| `exactMaxNodes`                                     | `32768`                 | the crossover, measured on the RTX 4070 SUPER (`docs/decisions/G3.md`); pass your own for another GPU (P4's `calibrateLayout` measures it) |
-| `deterministic`                                     | `true`                  | fixed summation order (the exact tier is always deterministic)                                                                             |
-| `compat`                                            | `"paper"`               | `"networkx"` reproduces NetworkX 3.4's `forceatlas2_layout` (gravity toward the origin, its accumulated swing / traction)                  |
-| `nearMax`, `gridMax2D`, `gridMax3D`, `extentFactor` | `64`, `512`, `128`, `6` | stored for the grid tier (P4)                                                                                                              |
+| Option                                              | Default                 | Meaning                                                                                                                                                                                                                    |
+| --------------------------------------------------- | ----------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `repulsion`                                         | `"auto"`                | `"exact"` at any n; `"auto"` = exact iff n <= `exactMaxNodes`, else grid; `"grid"` at any n                                                                                                                                |
+| `exactMaxNodes`                                     | `32768`                 | the G3 value, kept by owner decision G4-D1 while the accuracy work G4-F1 leaves is open (`docs/decisions/G4.md`; the section 7.8 rule computes 1024 on the RTX 4070 SUPER); pass your own (`calibrateLayout` measures it). |
+| `deterministic`                                     | `true`                  | fixed summation order (the exact tier is always deterministic)                                                                                                                                                             |
+| `compat`                                            | `"paper"`               | `"networkx"` reproduces NetworkX 3.4's `forceatlas2_layout` (gravity toward the origin, its accumulated swing / traction)                                                                                                  |
+| `nearMax`, `gridMax2D`, `gridMax3D`, `extentFactor` | `64`, `512`, `128`, `6` | stored for the grid tier (P4)                                                                                                                                                                                              |
 
 Every range error is `E_INVALID_ARGUMENT` (`gravity < 0`, `scalingRatio <= 0`, `jitterTolerance <= 0`,
 `maxIter < 1`, `settleWindow < 1`, `maxInFlight < 1`, `iterationsPerStep < 1`, `dim` not 2 or 3,
@@ -169,6 +173,150 @@ else the batch's wall time divided by its iteration count), the grid fields (`nu
 `trace`: one `{ swing, traction, speed, speedEfficiency, meanDisplacement, settledCount }` record per
 iteration of the last batch.
 
+## Fruchterman-Reingold and the spring-electrical preset
+
+Two more force layouts ship beside ForceAtlas2, on the same exact repulsion tier and with exactly the
+lifecycle the two ForceAtlas2 sections above describe: `load(snapshot, positions)`, then `run()` from Node or
+`step()` once per frame, with `stats`, `settled`, `setPosition`, `setFixed`, `reheat`, `flush`, `setParams`,
+`dispose` and the coalescing rule all unchanged. They differ in the force law, in their option records and in
+what their trace carries. Both are also methods of an accelerator: `acc.fruchtermanReingold(options)` and
+`acc.springElectrical(options)`, which pass the accelerator's `layout` tuning down the same way
+`acc.forceAtlas2` does.
+
+What they ask of the graph, and what they refuse, is ForceAtlas2's:
+
+- an UNDIRECTED snapshot. `load()` throws `E_SNAPSHOT { reason: "directed" }` otherwise; pass
+  `toUndirected().snapshot`
+- edge weights are ignored by both models, and both give every node the same mass rule for its whole run --
+  1 for Fruchterman-Reingold, `1 + degree / 3` for the spring preset -- so neither has a `weight` or
+  `nodeMass` option to pass
+- `positions` is the owner's stride-3 scene-unit `Float32Array` of length `3 * nodeCount`, over a plain
+  `ArrayBuffer`; any other length is `E_INVALID_ARGUMENT`. Rows holding a non-finite component are seeded in
+  place at `load()` (see `seedPositions` below), finite rows are the starting layout
+- an empty snapshot (`nodeCount: 0`) loads without touching the GPU and is `settled` on arrival; `step()`
+  resolves immediately and the positions array is left alone
+- a graph the device cannot hold is refused at `load()`, before any GPU work:
+  `E_TOO_LARGE { path: "positions" }` when `16 * nodeCount` bytes exceed the device's `maxBufferSize`,
+  `{ path: "windowed" }` when the arc arrays need more than one storage binding, and `{ path: "partials" }`
+  above 16,776,960 nodes
+- above `exactMaxNodes` with the default `repulsion: "auto"`, `load()` throws
+  `E_UNSUPPORTED { feature: "repulsion.grid" }`, as ForceAtlas2 does; `repulsion: "exact"` runs all pairs at
+  any size
+
+The GPU tuning table above applies to both, with one exception: `compat` is read by ForceAtlas2 alone and
+changes nothing here.
+
+### Fruchterman-Reingold
+
+The spring model of the original paper: every pair of nodes repels with `k^2 / d`, every edge pulls with
+`d^2 / k`, where `k` is the ideal edge length, and a falling temperature caps how far a node may move in a
+single iteration.
+
+```ts
+import { createFruchtermanReingold } from "@graphty/webgpu-graph-algorithms";
+
+// positions: the owner's stride-3 scene-unit array; NaN rows are seeded at load(), finite rows are kept
+const positions = new Float32Array(3 * snapshot.nodeCount).fill(Number.NaN);
+
+const sim = createFruchtermanReingold(ctx, { iterations: 50, cooling: "linear", seed: 42, dim: 2 });
+sim.load(snapshot, positions); // an undirected snapshot
+const stats = await sim.run({ batch: 8 }); // stops at `iterations` or when the layout settles
+console.log(sim.iterationsDone, sim.settled, stats.temperature, stats.meanDisplacement);
+
+sim.dispose(); // then ctx.release(snapshot) and ctx.dispose() when the graph goes away
+```
+
+| Option                                                                | Default                       | Meaning                                                                                                                                                                                                                                                                                                                                                 |
+| --------------------------------------------------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `k`                                                                   | `null`                        | the ideal edge length. `null` (and `0`, and `NaN`) means `1 / sqrt(nodeCount)`, resolved at `load()`; anything else must be a finite number > 0                                                                                                                                                                                                         |
+| `iterations`                                                          | `50`                          | an integer >= 0 and the budget `run()` stops at (`0` is settled on arrival). Under `cooling: "adaptive"` it is only a cap, and an option record that never set it gets `10000` instead                                                                                                                                                                  |
+| `cooling`                                                             | `"linear"`                    | `"linear"`: the temperature falls from `0.1` to `0` across `iterations`, so a run lasts the whole budget. `"adaptive"`: Yifan Hu's step control -- the temperature shrinks by `0.9` whenever the total force energy rose and grows by `1 / 0.9` after five consecutive falls -- so a run ends when the layout stops moving rather than at a fixed count |
+| `fixed`                                                               | `null`                        | which nodes are pinned, applied at `load()`: a graph-format `NodeMask`, the name of a bool node column, or `null`, which takes the column with role `fixed` when the snapshot has one and pins nothing otherwise. Not a live option: `setParams({ fixed })` is `E_INVALID_ARGUMENT`, use `setFixed(mask)`                                               |
+| `dim`, `scale`, `center`, `seed`                                      | `2`, `1`, `[0, 0, 0]`, `null` | as ForceAtlas2                                                                                                                                                                                                                                                                                                                                          |
+| `settleThreshold`, `settleWindow`, `iterationsPerStep`, `maxInFlight` | `0.001`, `10`, `1`, `2`       | as ForceAtlas2                                                                                                                                                                                                                                                                                                                                          |
+
+`FR_DEFAULTS` is the frozen record of those defaults (`center` and `seed` are the shared ones and are not in
+it). Every range error is `E_INVALID_ARGUMENT`, and `maxInFlight` cannot change after creation.
+
+`sim.stats` is `FruchtermanReingoldStats`: everything in `LayoutStatsBase` -- `iteration`,
+`meanDisplacement`, `rmsRadius`, `layoutRadius`, `centroid`, `repulsionTier` (`"exact"`), `msPerIteration`
+and the grid fields, which are `null` -- plus `temperature`, the schedule's value for the last completed
+iteration, and `trace`: one `{ temperature, meanDisplacement, settledCount }` record per iteration of the
+last batch.
+
+### The spring-electrical preset
+
+ngraph.forcelayout's model with ngraph's own constants: Hooke springs along the edges, Coulomb repulsion
+between every pair, and a velocity integrated with drag. A node's mass is `1 + degree / 3`, as ngraph
+assigns it.
+
+```ts
+import { createSpringElectrical } from "@graphty/webgpu-graph-algorithms";
+
+const sim = createSpringElectrical(ctx, { springLength: 10, timeStep: 0.5, seed: 42 });
+sim.load(snapshot, positions);
+const stats = await sim.run({ maxIter: 1000, batch: 8 }); // pass maxIter: this model has no iteration count
+console.log(sim.iterationsDone, sim.settled, stats.kineticEnergy);
+
+sim.dispose();
+```
+
+| Option                                                                | Default                       | Meaning                                                                                                                                                                                    |
+| --------------------------------------------------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `springLength`                                                        | `10`                          | the rest length of an edge; a finite number > 0                                                                                                                                            |
+| `springCoefficient`                                                   | `0.8`, size-scaled            | Hooke's constant. Left out or `null` it is ngraph's `0.8` times `min(1, 300 / nodeCount)`, applied once `nodeCount` is known at `load()`; a number you pass is used as given at every size |
+| `gravity`                                                             | `-12`, size-scaled            | ngraph's Coulomb constant, where NEGATIVE repels -- this is not ForceAtlas2's centre gravity. Left out or `null` it is ngraph's `-12` times the same factor. Any finite number is accepted |
+| `dragCoefficient`                                                     | `0.9`                         | velocity damping; a finite number >= 0                                                                                                                                                     |
+| `timeStep`                                                            | `0.5`                         | the integrator's step; a finite number > 0                                                                                                                                                 |
+| `dim`, `scale`, `center`, `seed`                                      | `2`, `1`, `[0, 0, 0]`, `null` | as ForceAtlas2                                                                                                                                                                             |
+| `settleThreshold`, `settleWindow`, `iterationsPerStep`, `maxInFlight` | `0.001`, `10`, `1`, `2`       | as ForceAtlas2                                                                                                                                                                             |
+
+The size scaling exists because ngraph's constants were tuned for graphs of a few hundred nodes: on tens of
+thousands the per-node forces are large enough that every node moves at the unit speed clamp and the layout
+never comes to rest. `SE_DEFAULTS` is the frozen record of the unscaled constants.
+
+This model has no iteration-count option, so `run()` without `maxIter` has no budget at all and returns only
+when the layout settles. Pass `run({ maxIter })` unless that is what you want.
+
+`sim.stats` is `SpringElectricalStats`: `LayoutStatsBase` plus `kineticEnergy`, and a `trace` of
+`{ kineticEnergy, meanDisplacement, settledCount }`. The energy lags the positions by one iteration -- the
+iteration that follows an integrate is the one that folds its energy -- so the first record after `load()`
+carries `0` and record i carries the energy of iteration i - 1.
+
+Both models appear in the Performance section below as row T-14 and in the `layout-fr` benchmark group.
+
+## The `seedPositions` helper
+
+Every simulation seeds the unplaced rows of your positions array at `load()`, so you never have to call this.
+It is public for the case where you want the same starting layout without a simulation -- to draw the graph
+before the first frame lands, to reproduce a run on the CPU, or to place a subgraph the same way twice.
+
+```ts
+import { fromEdgeArrays } from "@graphty/graph-format";
+import { seedPositions } from "@graphty/webgpu-graph-algorithms";
+
+const s = fromEdgeArrays({ directed: false, nodeCount: 3, src: new Uint32Array([0]), dst: new Uint32Array([1]) });
+const positions = new Float32Array(3 * s.nodeCount).fill(Number.NaN);
+
+seedPositions(s, positions, 42, 2, 1, null, "fa2");
+// every row now holds x and y in [-1, 1) and z = 0; seed 42 gives this same array every time
+```
+
+The arguments are positional and all required: the snapshot, the owner's stride-3 scene-unit array (modified
+in place, length `3 * nodeCount`), the LCG seed (`0` or `null` draws a random one, the CPU port's quirk kept
+bit for bit), `dim` (`2` or `3`), the scene `scale` (> 0), the scene `center` (an `ArrayLike<number>`, or
+`null` for the origin), and the draw range: `"fa2"` is `[-1, 1)` in layout units, `"fr"` is `[0, 1)`.
+ForceAtlas2 and the spring preset seed with `"fa2"`, Fruchterman-Reingold with `"fr"`.
+
+A row counts as unseeded when ANY of its first `dim` components is not finite, and only its non-finite
+components are written -- a finite component is never changed and a fully finite row is never touched. In 2D
+the third component of a row being seeded is set to `center[2]`. The draw box depends on what is already
+there: when no row is fully finite the draw is the plain range per axis, and otherwise it is the `[min, max]`
+box of the finite components, per axis, so new nodes land among the ones already placed instead of around the
+origin. No random number is drawn at all when nothing needs seeding. A bad `dim`, a `positions` length other
+than `3 * nodeCount`, a non-positive `scale`
+or a non-finite `center` component is `E_INVALID_ARGUMENT`; the function returns nothing.
+
 ## Acquisition
 
 ### Node
@@ -243,10 +391,218 @@ ctx.dispose(); // destroys the device and lets the process exit
 In a browser, `import { requestGpuContext } from "@graphty/webgpu-graph-algorithms/browser"` and `const ctx = await
 requestGpuContext();` replace the first import and line; the rest is identical.
 
+## Centrality and components
+
+Six algorithm functions run on the device. Every one has the same shape -- `await fn(ctx, snapshot, options?)`
+-- and every array that comes back is indexed by the snapshot's NODE INDEX (`0 .. nodeCount - 1`), never by
+node id; the snapshot's id map turns an index back into the id it was built from. Every score result carries
+`precision: "f32"`, so a reader can label what it is looking at.
+
+The context uploads what an algorithm needs the first time it sees a snapshot and keeps it until
+`ctx.release(snapshot)`: the CSR core for PageRank, HITS, eigenvector centrality and connected components,
+the reverse adjacency for PageRank, HITS and Katz, the edge list for connected components. A second call on
+the same snapshot pays no upload.
+
+Each one is also a method of the object `createAccelerator(ctx)` returns -- `acc.pageRank(s, options)` and so
+on, with `connectedComponents` answering to `weaklyConnectedComponents` as well -- which is how
+`@graphty/algorithms` reaches them when a GPU accelerator is injected into it.
+
+The PageRank example below is complete; the examples after it reuse its context `ctx` and its snapshot `s`
+rather than repeating the setup.
+
+Options every one of them accepts on top of its own (`GpuRunOptions`):
+
+| Option       | Default | Meaning                                                                                                                                                                                                                                         |
+| ------------ | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `dest`       | unset   | a preallocated result of exactly `nodeCount` elements over a plain `ArrayBuffer`: a `Float32Array` for scores, a `Uint32Array` for labels. Any other type or length is `E_INVALID_ARGUMENT { argument: "dest" }`; `hits` fills it with the hubs |
+| `signal`     | unset   | an `AbortSignal`, checked before the first submit and after every batch; `E_ABORTED { batchId }`                                                                                                                                                |
+| `onProgress` | unset   | `(done, total)` after every batch. `total` is `maxIterations`, `2 * maxIterations` for `hits` (it runs two chains) and `1` for `connectedComponents`, which reports once when it finishes                                                       |
+
+A graph too large for the device is refused before any GPU work: when the arc arrays need more than one
+storage binding they would need a windowed upload, which only `degree` executes, and each of these six throws
+`E_TOO_LARGE { needed, limit, path: "windowed" }` instead. A node count whose dispatch does not fit
+the device's 2D workgroup grid is `E_TOO_LARGE { path: "dispatch" }`, and scratch that does not fit the
+device's budget is `E_OUT_OF_MEMORY { requested, resident, label }`.
+
+### PageRank
+
+PageRank is the stationary distribution of a surfer who follows an out-arc with probability `dampingFactor`
+and teleports to a uniformly random node otherwise. `pageRank` runs NetworkX's iteration on the device: rank
+is pulled along the reverse adjacency, out-weights normalise the push, and the mass sitting on nodes with no
+out-arcs is redistributed through the teleport vector every iteration.
+
+```ts
+import { fromEdgeArrays } from "@graphty/graph-format";
+import { pageRank } from "@graphty/webgpu-graph-algorithms";
+import { createNodeGpuContext } from "@graphty/webgpu-graph-algorithms/node";
+
+const ctx = await createNodeGpuContext();
+const s = fromEdgeArrays({
+    directed: true,
+    nodeCount: 4,
+    src: new Uint32Array([0, 1, 2, 3]), // a tail into a 3-cycle: 0 -> 1 -> 2 -> 3 -> 1
+    dst: new Uint32Array([1, 2, 3, 1]),
+});
+
+const r = await pageRank(ctx, s, { dampingFactor: 0.85, tolerance: 1e-6 });
+console.log(r.scores); // Float32Array(4), index-aligned, summing to 1; node 0 scores lowest
+console.log(r.iterations, r.converged, r.danglingMass);
+
+ctx.release(s); // when the graph goes away; ctx.dispose() at the end of the program
+```
+
+| Option          | Default | Meaning                                                                                                              |
+| --------------- | ------- | -------------------------------------------------------------------------------------------------------------------- |
+| `dampingFactor` | `0.85`  | the probability of following an arc; the rest teleports                                                              |
+| `maxIterations` | `100`   | an integer >= 1; anything else is `E_INVALID_ARGUMENT`                                                               |
+| `tolerance`     | `1e-6`  | converged when the L1 change of the whole vector falls below `tolerance * nodeCount` (NetworkX's rule)               |
+| `weighted`      | `true`  | arc weights are the transition mass; `false` weighs every arc 1. A snapshot with no weights is unweighted either way |
+
+`GpuPageRankResult` comes back: `scores` (one f32 per node, summing to 1 up to f32 rounding), `iterations`
+(the FIRST iteration whose delta fell below the threshold, not the batch boundary the run stopped at, and
+`maxIterations` when it never did), `converged`, `danglingMass` (the rank mass the last iteration found on
+nodes with no positive out-weight and redistributed) and `precision`.
+
+Directed or undirected both work: an undirected snapshot carries both directions, so the pull and the
+normaliser see the same arcs, and the scores differ from the directed form's as they should. `nodeCount: 0`
+returns an empty `scores` with `iterations: 0`, `converged: true` and does no GPU work. A graph with no arcs
+at all makes every node dangling, so the teleport vector is already the fixed point: the call returns
+`1 / nodeCount` everywhere with `iterations: 0` and `danglingMass: 1`. An isolated node inside a larger graph
+is one dangling node -- it keeps its teleport share and its share of the redistributed mass -- and so is a
+node whose out-arcs all weigh zero under `weighted: true`.
+
+### Personalized PageRank
+
+The same iteration with the uniform teleport vector replaced by yours, so the walk restarts where you say:
+
+```ts
+import { personalizedPageRank } from "@graphty/webgpu-graph-algorithms";
+
+const bias = new Float32Array(s.nodeCount);
+bias[0] = 1; // restart at node 0 only
+const r = await personalizedPageRank(ctx, s, bias, { dampingFactor: 0.85 });
+console.log(r.scores); // mass concentrated on what node 0 reaches
+```
+
+`personalization` is a `Float32Array` of one finite non-negative number per node, not all zero, and it is
+normalised to sum 1 on the host before the run -- so unnormalised weights are fine. A wrong length, a
+negative or non-finite entry, or a zero total is `E_INVALID_ARGUMENT { argument: "personalization" }`.
+Options, result and edge cases are PageRank's, except that a graph with no arcs returns the normalised
+personalization vector rather than `1 / nodeCount`.
+
+### HITS
+
+HITS scores each node twice: as a hub (it points at good authorities) and as an authority (good hubs point at
+it). `hits` runs the CPU package's recurrence -- `a(i) = A^T norm(h(i-1))` and `h(i) = A norm(a(i-1))` from
+uniform seeds -- as two interleaved chains on the device, then sum-normalises both vectors once on the host.
+
+```ts
+import { hits } from "@graphty/webgpu-graph-algorithms";
+
+const cycle = fromEdgeArrays({
+    directed: true,
+    nodeCount: 2,
+    src: new Uint32Array([0, 1]),
+    dst: new Uint32Array([1, 0]),
+});
+const r = await hits(ctx, cycle);
+console.log(r.hubs, r.authorities); // [0.5, 0.5] and [0.5, 0.5]
+ctx.release(cycle);
+```
+
+The options are `maxIterations` (`100`), `tolerance` (`1e-6`) and `weighted` (`true`), with PageRank's
+meanings. `GpuHitsResult` carries `hubs` and `authorities` (both f32, index-aligned, each summing to 1),
+`iterations` (the larger of the two chains'), `converged` (both chains) and `precision`. `dest` receives the
+hubs; the authorities always come back in a fresh array.
+
+Direction is the point of the algorithm: an undirected snapshot has a symmetric adjacency, so the two vectors
+come out the same. `nodeCount: 0` returns two empty arrays with `iterations: 0` and `converged: true`; a graph
+with no arcs returns all zeros in both, since there is nothing to be a hub of.
+
+### Eigenvector centrality
+
+A node is central when central nodes point at it. The scores are the principal eigenvector of the adjacency
+matrix, found by power iteration over the forward adjacency and L2-normalised once at the end.
+
+```ts
+import { eigenvectorCentrality } from "@graphty/webgpu-graph-algorithms";
+
+const r = await eigenvectorCentrality(ctx, s, { maxIterations: 100, tolerance: 1e-6 });
+console.log(r.scores, r.converged); // f32, index-aligned, L2 norm 1
+```
+
+The options are `maxIterations` (`100`), `tolerance` (`1e-6`) and `weighted` (`true`); convergence is
+PageRank's L1 rule, a delta below `tolerance * nodeCount`. It returns `GpuScoresResult` -- `scores`,
+`iterations`, `converged`, `precision` -- which is PageRank's result without `danglingMass`.
+
+Directed or undirected both work. When a graph's components have different spectral radii the power iteration
+converges on the dominant component's eigenvector and the others fall toward zero; that is a property of the
+method, not of this implementation. `nodeCount: 0` is empty; a graph with no arcs, and an isolated node in a
+larger graph, scores 0.
+
+### Katz centrality
+
+Katz counts every walk that ends at a node, discounted by its length: `x = alpha * A^T x + beta`, so a walk of
+length L contributes `alpha^L`. Unlike eigenvector centrality it hands every node the floor `beta`, which
+keeps a node with no incoming arcs from scoring zero.
+
+```ts
+import { katzCentrality } from "@graphty/webgpu-graph-algorithms";
+
+const r = await katzCentrality(ctx, s, { alpha: 0.1, beta: 1 });
+console.log(r.scores); // f32, index-aligned, L2-normalised
+```
+
+| Option          | Default | Meaning                                                                                                                                  |
+| --------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
+| `alpha`         | `0.1`   | the attenuation per step. Convergence needs it below the reciprocal of the largest eigenvalue; the package checks only that it is finite |
+| `beta`          | `1`     | the constant every node is given each iteration                                                                                          |
+| `maxIterations` | `100`   | as above                                                                                                                                 |
+| `tolerance`     | `1e-6`  | as above                                                                                                                                 |
+| `weighted`      | `true`  | as above                                                                                                                                 |
+
+A non-finite `alpha` or `beta` is `E_INVALID_ARGUMENT`. The result is `GpuScoresResult`, L2-normalised on the
+host with no per-iteration normaliser on the device. Walks arrive along the reverse adjacency, so direction
+matters. `nodeCount: 0` is empty; with no arcs every node holds `beta` alone, which after normalisation is
+`1 / sqrt(nodeCount)` each.
+
+### Connected components
+
+`connectedComponents` labels the WEAK components: it walks the edge list, so an edge joins its two endpoints
+whether or not the snapshot is directed, and the directed and undirected forms of one edge set give identical
+labels. The kernel is GAP's Afforest -- sampled link rounds, then each edge once, then a final compress.
+
+```ts
+import { connectedComponents } from "@graphty/webgpu-graph-algorithms";
+
+const g = fromEdgeArrays({
+    directed: false,
+    nodeCount: 4,
+    src: new Uint32Array([0, 1]), // the path 0 - 1 - 2, with node 3 on its own
+    dst: new Uint32Array([1, 2]),
+});
+const r = await connectedComponents(ctx, g);
+console.log(r.labels); // Uint32Array [0, 0, 0, 1]
+console.log(r.count); // 2
+console.log(r.groups()); // [Uint32Array [0, 1, 2], Uint32Array [3]]
+ctx.release(g);
+```
+
+`labels` holds one label per node index. By default they are renumbered dense `0 .. count - 1` in first-seen
+index order, which makes them identical to the labels `@graphty/algorithms` produces for the same graph;
+`renumber: false` returns the raw root indices instead -- the same partition with arbitrary label values, and
+the same `count`. `groups()` builds the member lists on the first call and caches them, index-aligned with
+the labels in that same first-seen order.
+
+`renumber` (default `true`) is the only option besides the shared three. `nodeCount: 0` gives empty labels,
+`count: 0` and no GPU work; a graph with no arcs gives every node its own block, so `labels[v] === v` and
+`count === nodeCount`, which is what an isolated node gets inside a larger graph too. Self-loops and repeated
+edges change nothing: the link step is idempotent.
+
 ## Errors
 
 Every condition the package detects itself is a `WebGpuGraphError` with a stable `code`
-(`E_NO_WEBGPU`, `E_NO_ADAPTER`, `E_NO_DEVICE`, `E_SOFTWARE_ONLY`, `E_DEVICE_LOST`, `E_DISPOSED`,
+(`E_NO_WEBGPU`, `E_NO_ADAPTER`, `E_NO_DEVICE`, `E_SOFTWARE_ONLY`, `E_DEVICE_LOST`, `E_DEVICE_INCORRECT`, `E_DISPOSED`,
 `E_VALIDATION`, `E_SHADER_COMPILE`, `E_OUT_OF_MEMORY`, `E_TOO_LARGE`, `E_UNSUPPORTED`,
 `E_INVALID_ARGUMENT`, `E_SNAPSHOT`, `E_RELEASED`, `E_NOT_LOADED`, `E_ABORTED`) and frozen `details`.
 `isWebGpuGraphError(x)` and `hasErrorCode(x, code)` are structural brand checks, so they survive two copies
@@ -255,6 +611,38 @@ of the package. The graph-format codes `E_GPU_INELIGIBLE`, `E_UNKNOWN_NODE`, `E_
 released rejects its next `step()` with `E_RELEASED`; a lost device disposes every simulation and rejects
 every pending `step()` with `E_DEVICE_LOST` (create a new context from a fresh adapter and `load()` again).
 
+## The device self-check
+
+Some GPU drivers return wrong answers rather than failing. On Windows over the Microsoft Basic Render Driver,
+compute shaders that synchronise across a workgroup produce silently incorrect results, which would make every
+number this package computes there unreliable with no error anywhere.
+
+So the first algorithm or layout you run on a context asks the device for an answer this package already knows --
+an exclusive scan across 33 workgroups of known numbers (8,193 words on a 256-lane device), verified word by word
+on the host -- and refuses a device that gets it wrong with `E_DEVICE_INCORRECT`, naming the first wrong word,
+what belonged there and the adapter's description string. It runs once per device and is remembered: 14-20 ms
+the first time, nearly all of it compiling the two scan pipelines that any scan-using algorithm would compile
+anyway, and 0.6-1.0 ms of work under that (measured on Dawn over lavapipe and over an RTX 4070 SUPER). It cannot be switched off: a flag for it would be off in
+somebody's production build, which is the silent wrong answers walking back in.
+
+Choosing the processor instead is your decision, not the package's, so nothing falls back. To ask before you
+commit work to a device, call it yourself:
+
+```ts
+import { verifyDevice } from "@graphty/webgpu-graph-algorithms";
+
+const check = await verifyDevice(ctx); // memoised: the algorithms below reuse this result
+if (!check.ok) {
+    // check.mismatch names the first wrong word; check.description is the adapter string that identifies the driver
+    runOnTheCpuInstead();
+}
+```
+
+It checks one property -- that values crossing a workgroup barrier, and block totals crossing dispatches of one
+compute pass, survive. A device that gets that right and gets atomics or float rounding wrong still passes. It is
+a refusal mechanism, not a certificate of correctness; `docs/decisions/device-self-check.md` records what it
+covers, what it does not, and why the package refuses such a device rather than computing around it.
+
 ## Benchmarks
 
 ```bash
@@ -277,10 +665,15 @@ the profiler reports; every rung starts with an untimed clock warm-up burst, bec
 SM clock at its idle 210 MHz under sparse sub-millisecond dispatches and the kernels then measure 4-15x slower),
 `pagerank` (T-8), `wcc` (T-9), `layout-fr` (T-14: `step(1)` of `createFruchtermanReingold` and `createSpringElectrical`
 at 10k and at 100k with `repulsion: "exact"`, the same two rows per model and rung as `layout-exact`, tagged `fr` /
-`se`). The Chromium number of T-5 comes from the `bench`-tagged browser test (`GRAPHTY_BROWSER_GPU=nvidia node
-scripts/run-browser-project.js`), which appends its session through the Vitest commands bridge. `exactMaxNodes` is
-re-fixed from the ladder by the rule of plan section 7.8 (the largest rung under 4 ms per iteration, rounded down to a
-power of two; `benchmarks/layout-exact.bench.ts` `exactMaxNodesFromLadder`).
+`se`), `layout-grid` (T-6 and T-7: `step(1)` of the grid tier on the grid ladder 32k / 65k / 100k / 262k / 1M in 2D
+and in 3D, the same two rows per rung tagged `grid` with the dimension, plus the `fa2-attraction` pass of the 1M 2D
+iteration from the profiler, and the exact ladder's 1k / 4k / 8k / 16k rungs in 2D for the crossover re-check). The Chromium numbers of T-5 (10k on the exact tier, 100k on the grid tier) come from the
+`bench`-tagged browser test (`GRAPHTY_BROWSER_GPU=nvidia node scripts/run-browser-project.js`), which appends its
+session through the Vitest commands bridge. `exactMaxNodes` is re-fixed from the ladder by the rule of plan section 7.8
+(the largest rung under 4 ms per iteration and not slower than the grid tier at the same n -- the `layout-grid` 2D rows,
+which the group also records at the exact ladder's 1k / 4k / 8k / 16k rungs so the clause has a row at every rung --
+rounded down to a power of two; `benchmarks/layout-exact.bench.ts` `exactMaxNodesFromLadder`); `calibrateLayout(ctx)`
+measures the same crossover on a consumer's own device.
 
 ## Performance
 
@@ -291,18 +684,21 @@ are the T-table of plan section 10.4. A missed target is re-fixed by a recorded
 
 ### The dev box (nvidia-lovelace-driver580)
 
-Measured on nvidia-lovelace-driver580 (NVIDIA: 580.173.02 580.173.2.0), session 2026-09-20T01:06:48.656Z, medians of 5 runs; Chromium: nvidia / lovelace (nvidia-lovelace-driver0, the description is redacted by Chromium), session 2026-09-16T02:18:11.896Z.
-
-| Id   | What                                                                                                                                     | Target              | Measured               |
-| ---- | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ---------------------- |
-| T-1  | Upload of the 100k / 1M weighted hot prefix (16.4 MB); 1M / 10M (164 MB)                                                                 | <= 10 ms; <= 100 ms | 5.980 ms; 125.738 ms   |
-| T-2  | `degree` + 400 KB readback at 100k (core resident), Node                                                                                 | <= 2 ms             | 0.870 ms               |
-| T-3  | Empty submit + 4-byte `readU32` round trip, Dawn                                                                                         | <= 0.1 ms           | 0.181 ms               |
-| T-4  | ForceAtlas2 exact tier, GPU time per iteration (profiler) at 10k; at 16k                                                                 | <= 1 ms; <= 2 ms    | 0.586 ms; 1.053 ms     |
-| T-5  | ForceAtlas2 per-frame cost, `step(1)` + the 12n readback at 10k, Chromium (Node in brackets)                                             | <= 6 ms             | 2.400 ms (0.726 ms)    |
-| T-8  | PageRank, 100 iterations, wall end to end including the upload, at 100k / 1M; at 1M / 10M                                                | <= 150 ms; <= 1.5 s | 17.204 ms; 198.645 ms  |
-| T-9  | Weakly connected components (Afforest), wall end to end including the upload and the label readback, at 1M / 10M (100k / 1M in brackets) | <= 100 ms           | 145.970 ms (12.613 ms) |
-| T-14 | Fruchterman-Reingold exact tier, GPU time per iteration (profiler) at 10k; at 100k (`repulsion: "exact"`)                                | recorded            | 0.617 ms; 16.367 ms    |
+Measured on nvidia-lovelace-driver580 (NVIDIA: 580.173.02 580.173.2.0), session 2026-09-20T01:06:48.656Z, medians of 5 runs; Chromium: nvidia / lovelace (nvidia-lovelace-driver0, the description is redacted by Chromium), session 2026-09-16T02:18:11.896Z. The T-5 (100k), T-6 and T-7 rows are from the later session 2026-09-21T06:15:17.027Z (the file's last session, the current baseline, the one the crossover re-check reads; its Chromium session 2026-09-21T05:48:14.190Z), whose other rows are within 1.25x of this table's.
+
+| Id   | What                                                                                                                                     | Target                        | Measured                     |
+| ---- | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | ---------------------------- |
+| T-1  | Upload of the 100k / 1M weighted hot prefix (16.4 MB); 1M / 10M (164 MB)                                                                 | <= 10 ms; <= 100 ms           | 5.980 ms; 125.738 ms         |
+| T-2  | `degree` + 400 KB readback at 100k (core resident), Node                                                                                 | <= 2 ms                       | 0.870 ms                     |
+| T-3  | Empty submit + 4-byte `readU32` round trip, Dawn                                                                                         | <= 0.1 ms                     | 0.181 ms                     |
+| T-4  | ForceAtlas2 exact tier, GPU time per iteration (profiler) at 10k; at 16k                                                                 | <= 1 ms; <= 2 ms              | 0.586 ms; 1.053 ms           |
+| T-5  | ForceAtlas2 per-frame cost, `step(1)` + the 12n readback at 10k, Chromium (Node in brackets)                                             | <= 6 ms                       | 2.400 ms (0.726 ms)          |
+| T-5  | ForceAtlas2 per-frame cost, `step(1)` + the 12n readback at 100k on the grid tier, Chromium (Node in brackets)                           | <= 12 ms                      | 3.700 ms (2.087 ms)          |
+| T-6  | ForceAtlas2 grid tier, GPU time per iteration (profiler) at 100k 2D; at 1M 2D; at 100k 3D                                                | <= 10 ms; <= 100 ms; <= 20 ms | 0.634 ms; 5.414 ms; 1.306 ms |
+| T-7  | Attraction gather (the `fa2-attraction` pass of the grid tier), GPU time per iteration (profiler) at 1M / 10M                            | <= 15 ms                      | 1.493 ms                     |
+| T-8  | PageRank, 100 iterations, wall end to end including the upload, at 100k / 1M; at 1M / 10M                                                | <= 150 ms; <= 1.5 s           | 17.204 ms; 198.645 ms        |
+| T-9  | Weakly connected components (Afforest), wall end to end including the upload and the label readback, at 1M / 10M (100k / 1M in brackets) | <= 100 ms                     | 145.970 ms (12.613 ms)       |
+| T-14 | Fruchterman-Reingold exact tier, GPU time per iteration (profiler) at 10k; at 100k (`repulsion: "exact"`)                                | recorded                      | 0.617 ms; 16.367 ms          |
 
 Three rows miss their target in this session: the 1M / 10M upload (125.7 ms against 100 ms, the open owner decision of
 `docs/decisions/G1.md` section 7), the empty-submit round trip (0.181 ms against 0.1 ms: the row is measured after the
@@ -336,23 +732,28 @@ GPU time per iteration in the last batch).
 
 The first run of the GPU lane (`gpu.yml`, graphty-monorepo run 35316416067, 2026-09-18) on a machine.dev T4 -- one Tesla
 T4 (16 GB), 4 vCPU of a Xeon Platinum 8259CL, driver 580.126.20 -- wrote this baseline; `scripts/bench-compare.js` fails
-a later run of the lane whose median exceeds 3x these figures. The T-table targets were set on the dev box; the T4 meets
-T-4 and T-5 and misses T-1 (both uploads), T-2 and T-3, which is the class difference of a datacentre card behind a
-cloud vCPU (host-side copies and submit latency), not a regression: the exact tier's `ms / iteration` is 1.7x the
-RTX 4070 SUPER's at 10k and 3.0x at 65k.
-
-Measured on gpu-linux-t4 (NVIDIA: 580.126.20 580.126.20.0), session 2026-09-20T02:29:33.210Z (run 35483512705), medians of 5 runs; Chromium: nvidia / turing (nvidia-turing-driver0, the description is redacted by Chromium), session 2026-09-20T02:28:10.676Z.
-
-| Id   | What                                                                                                                                     | Target              | Measured                                                                                                                                       |
-| ---- | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
-| T-1  | Upload of the 100k / 1M weighted hot prefix (16.4 MB); 1M / 10M (164 MB)                                                                 | <= 10 ms; <= 100 ms | 14.338 ms; 256.418 ms                                                                                                                          |
-| T-2  | `degree` + 400 KB readback at 100k (core resident), Node                                                                                 | <= 2 ms             | 2.957 ms                                                                                                                                       |
-| T-3  | Empty submit + 4-byte `readU32` round trip, Dawn                                                                                         | <= 0.1 ms           | 1.296 ms                                                                                                                                       |
-| T-4  | ForceAtlas2 exact tier, GPU time per iteration (profiler) at 10k; at 16k                                                                 | <= 1 ms; <= 2 ms    | 0.972 ms; 1.953 ms                                                                                                                             |
-| T-5  | ForceAtlas2 per-frame cost, `step(1)` + the 12n readback at 10k, Chromium (Node in brackets)                                             | <= 6 ms             | 2.600 ms (1.359 ms)                                                                                                                            |
-| T-8  | PageRank, 100 iterations, wall end to end including the upload, at 100k / 1M; at 1M / 10M                                                | <= 150 ms; <= 1.5 s | 45.461 ms; 1092.799 ms                                                                                                                         |
-| T-9  | Weakly connected components (Afforest), wall end to end including the upload and the label readback, at 1M / 10M (100k / 1M in brackets) | <= 100 ms           | 293.079 ms (28.544 ms)                                                                                                                         |
-| T-14 | Fruchterman-Reingold exact tier, GPU time per iteration (profiler) at 10k; at 100k (`repulsion: "exact"`)                                | recorded            | 0.942 ms; 54.232 ms (the spring preset 1.051 ms; 60.706 ms)                                                                                    |
+a later run of the lane whose median AND minimum both exceed 1.35x the best figures this file has ever held, by at
+least 2.5 ms. The T-table targets were set on the dev box; the T4 meets
+T-4, T-5 and T-6 and misses T-1 (both uploads), T-2, T-3 and T-7 (the 1M attraction pass of the grid tier, 18.165 ms
+against 15 ms), which is the class difference of a datacentre card behind a cloud vCPU (host-side copies and submit
+latency), not a regression: the exact tier's `ms / iteration` is 1.7x the RTX 4070 SUPER's at 10k and 3.0x at 65k, and
+the grid tier's is 2.8x at 100k 2D and 5.7x at 1M 2D while the attraction pass alone is 12.2x.
+
+Measured on gpu-linux-t4 (NVIDIA: 580.126.20 580.126.20.0), session 2026-09-20T02:29:33.210Z (run 35483512705), medians of 5 runs; Chromium: nvidia / turing (nvidia-turing-driver0, the description is redacted by Chromium), session 2026-09-20T02:28:10.676Z. The T-5 (100k), T-6 and T-7 rows are from the later session 2026-09-22T20:21:53.814Z (GPU lane run 35775999450 on commit 1d2d4dcf, the file's last session and the current baseline of this class; its Chromium session 2026-09-22T20:19:30.117Z).
+
+| Id   | What                                                                                                                                     | Target                        | Measured                                                                                                         |
+| ---- | ---------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------- |
+| T-1  | Upload of the 100k / 1M weighted hot prefix (16.4 MB); 1M / 10M (164 MB)                                                                 | <= 10 ms; <= 100 ms           | 14.338 ms; 256.418 ms                                                                                            |
+| T-2  | `degree` + 400 KB readback at 100k (core resident), Node                                                                                 | <= 2 ms                       | 2.957 ms                                                                                                         |
+| T-3  | Empty submit + 4-byte `readU32` round trip, Dawn                                                                                         | <= 0.1 ms                     | 1.296 ms                                                                                                         |
+| T-4  | ForceAtlas2 exact tier, GPU time per iteration (profiler) at 10k; at 16k                                                                 | <= 1 ms; <= 2 ms              | 0.972 ms; 1.953 ms                                                                                               |
+| T-5  | ForceAtlas2 per-frame cost, `step(1)` + the 12n readback at 10k, Chromium (Node in brackets)                                             | <= 6 ms                       | 2.600 ms (1.359 ms)                                                                                              |
+| T-5  | ForceAtlas2 per-frame cost, `step(1)` + the 12n readback at 100k on the grid tier, Chromium (Node in brackets)                           | <= 12 ms                      | 8.100 ms (5.314 ms)                                                                                              |
+| T-6  | ForceAtlas2 grid tier, GPU time per iteration (profiler) at 100k 2D; at 1M 2D; at 100k 3D                                                | <= 10 ms; <= 100 ms; <= 20 ms | 1.790 ms; 31.057 ms; 3.954 ms                                                                                    |
+| T-7  | Attraction gather (the `fa2-attraction` pass of the grid tier), GPU time per iteration (profiler) at 1M / 10M                            | <= 15 ms                      | 18.165 ms -- MISSED: 21 % over the target on this card (1.493 ms on the dev box; G4-F16 of docs/decisions/G4.md) |
+| T-8  | PageRank, 100 iterations, wall end to end including the upload, at 100k / 1M; at 1M / 10M                                                | <= 150 ms; <= 1.5 s           | 45.461 ms; 1092.799 ms                                                                                           |
+| T-9  | Weakly connected components (Afforest), wall end to end including the upload and the label readback, at 1M / 10M (100k / 1M in brackets) | <= 100 ms                     | 293.079 ms (28.544 ms)                                                                                           |
+| T-14 | Fruchterman-Reingold exact tier, GPU time per iteration (profiler) at 10k; at 100k (`repulsion: "exact"`)                                | recorded                      | 0.942 ms; 54.232 ms (the spring preset 1.051 ms; 60.706 ms)                                                      |
 
 The exact curve (the `layout-exact` group: 2D, E = 10n, seeded G(n, m), one simulation per rung; ms / iteration from the profiler):