Outlining kernels and mapping launch coordinates

An outlined kernel needs arguments or another supported mechanism for values used from outside its body. Those values include buffers, shapes, strides, scalars, and sometimes execution dependencies. Constants can be embedded when their semantics permit, while mutable or address-space-sensitive data needs a valid representation. MLIR's GPU dialect distinguishes launch regions and outlined kernel functions, but exact syntax and passes evolve. Record the compiler revision and pipeline instead of assuming a current textual example applies unchanged to every release.

The host/device boundary imposes ABI, address-space, allocation, and availability rules. A host pointer is not automatically a device-accessible allocation, and copying only its numeric value does not establish accessibility. Dynamic shapes and strides must match the buffer actually passed. A callable kernel signature also needs target-compatible argument lowering. Test interface mismatches and layout variants rather than validating only a single statically shaped contiguous array.

Independent logical elements can map to different threads, but a recurrence or global dependence cannot be repaired by simply choosing more blocks. Ordinary workgroup barriers synchronize only their documented scope, not arbitrary blocks across an entire launch. If one phase requires all blocks to finish before another reads global results, a separate ordered kernel launch can provide a boundary, or a supported cooperative mechanism may apply under additional constraints. Removing that boundary requires an actual synchronization proof.

A launch may return before the device work finishes. Later host reads, buffer reuse, deallocation, or another queue's kernel must respect completion and dependency semantics. Submission order within one supported stream is not a blanket ordering guarantee across every independent stream or host thread. Propagate events or dependency tokens where needed. Kernel outlining should preserve the execution graph, not merely extract instructions and hope runtime ordering matches the previous region's meaning.

Small kernels can spend substantial time in launch and scheduling overhead, motivating fusion or batching. Large kernels may instead be constrained by resource use, data movement, or the number of independent blocks. Compare complete dependent workloads, including required transfers and synchronization, rather than timing an empty kernel and extrapolating blindly. A faster launch path is not acceptable if host code reads incomplete output or buffers are freed before the asynchronous work retires.

The queue lab illustrates aggregate submission pressure only. Reset and set both λ=4, μ=2, predict growing backlog from four and Step. Reset and re-set λ=2, μ=3 for a declining comparison. Its fluid jobs are not GPU blocks or commands, and it has no stream ordering, captures, events, or device memory. Use it to explain why faster submission can merely accumulate more work if execution capacity is unchanged, then identify the actual completion and dependency measurements a launch experiment needs.