Roadmap (deferred work)

Consult this page when you are wondering “did anyone already think about this, and if so why isn’t it done yet?” — it is eagle’s single list of capabilities that are deliberately not built yet, what would trigger building them, and roughly how big each one is. Every item below is a recorded decision, not an oversight: eagle’s own docs (linked from each item) already explain the design reasoning in full; this page exists so the reasoning is findable in one place instead of only where the gap happens to surface.

Plugin registry

• float32 on the C++ PluginRegistry. eagle::cuda::PluginRegistry’s entire binding surface (bind_vector, bind_uniform, consolidate) is double-typed, and from_manifest rejects any sidecar declaring scalar_type: "float32" before it ever reaches the loader — a deliberate fail-fast, present since eagle’s first commit, not a bug found later. The reasoning and the exact rejection point are written up in Plugin schema (manifest and sidecar)’s float32 on the C++ registry section, which also names the trigger: build the float-typed twin of the binding surface (a few hundred lines, on the order of the double surface it mirrors) once a genuine C++ consumer of an f32 artifact exists — foreseeably a future neural-engine deployment. Until that consumer shows up this stays a documented capability, not an open task. Note this is a different kind of gap from SoftDouble, which shares the same registry’s double binding surface and needs no widening — tests/test_PluginRegistryDtype.cu’s SoftdoubleLoadsAndLaunches proves that path already works, because SoftDouble is bit-identical float64 underneath.

GPU architecture coverage

• SM 100/120 (Blackwell). EAGLE_CUDA_ARCHS=all includes Blackwell whenever the nvcc in use compiles it (CUDA 13, late CUDA 12), and the native default builds for whatever GPU the machine has. The CI build matrix still targets Pascal through Hopper with CUDA 12.6; a CUDA 13 arm and Blackwell measurements are planned.

Host plugin parity — closed out, nothing carried forward

Host plugin parity is the row-by-row tracking page for parity between the CUDA and CPU host plugin paths. Its tally line reads 22 CLOSED / 0 OPEN, over the full 56-cell matrix — every row that page tracks is closed. It stays in the devguide as the record of how that closure was reached, and as the template this page and Test map both follow for “how do I keep a tracking page honest as work lands.”

What is not on this list, on purpose

One thing that might look like a gap is a deliberate design choice instead, already documented where it lives and not repeated here as an open item. plugin_schema’s “C++ reference-consumer scope boundary” section lists three manifest fields the C++ registry never reads (vec_widths, accumulate/sink, the convenience arrays) — not a functional gap, since arg_spec alone drives binding.