The native Adams controller stays on the host on CUDA and HIP #362

What is missing

On CUDA and HIP builds the native Adams march (SEP 39) keeps its controller on the host. Each trial reads its error norms back once and launches its kernels from the host, with the trial's source replayed as one device graph where its operations repeat. A controller on the device, choosing the step and order there, would remove the read-back and the host's launches. SEP 39 left this open.

Why it matters

SEP 39 measured, on an AMD MI325X, the march's own host time at 0.5 to 3.0 µs a trial, against 160 to 550 µs of device time in 25 to 70 kernels, with the rest "launch and synchronisation overhead". What the read-back itself costs has not been separated, so the gain is unknown. Read, not run.

To do

• Measure the read-back and fence on a data-centre GPU, as a share of a trial, after Device steps are bound by kernel launches and buffer copies, not by arithmetic #357.
• If it is worth it, design device forms of the landing search and the order choice.

It must take the same steps as the host controller, whose decision traces are tested. Whether a device can branch this way within vendor graphs is unchecked, and is a suspicion of the main difficulty.

Needs a decision: whether to pursue this after the measurement. It would be a SEP, by the maintainer. I recommend not starting unless the read-back is above 20 % of a trial.

Done when

The share is recorded with device, case and date, and either a SEP is accepted or this closes on that number.

Checked against commit 8a9f764. Takes over the roadmap's entry "A device-resident Adams controller".