The Kernel Placement Problem
OpenCL-style kernels are a useful boundary because they make some work explicit: inputs, outputs, buffers, launch shape, memory movement, and the device that runs the kernel.
That is not enough by itself. If kernels are meant to spread across accelerator cards, FPGA regions, chiplets, or a larger fabric, the system needs placement and ownership rules that survive more than one device.
What Has To Be Managed
- Placement: which device, region, chiplet, or fabric area owns the kernel instance.
- Memory: where buffers live, when data moves, and which copies are authoritative.
- Configuration: which bitstream, kernel variant, clock, memory layout, or protocol endpoint is active.
- Security: which tenant, process, or capability can invoke the work and access the data.
- Failure: what happens when a device stalls, a link drops, a kernel faults, or a configuration update fails.
What Final Hardware Changes
A kernel running on a GPU is still usually managed by a host runtime. A kernel lowered into FPGA fabric or chiplet-scale hardware has fewer layers between the operation and the physical execution path.
That can reduce overhead, but it also removes convenient runtime assumptions. Allocation, scheduling, isolation, observability, and updates have to be designed into the system instead of assumed from the host software stack.
Useful Scope
This note does not claim configuration-free or infinitely scalable kernel management. The useful target is smaller and harder: make kernel placement explicit enough that source code, data movement, device ownership, and security boundaries can still be understood when work is distributed across hardware.
The fabrication side of this question connects to The Missing Maker Fab: the missing layer is not just more boards, but active behavior that can be built, tested, and controlled closer to the builder.