- 192Unified-Runtime entry points covered by the generated preload shim
- ~18engine files calling Level Zero directly
- 3.12the oneDNN version the patch series targets
ActiveKV's native engine and every kernel patch sit on Intel's oneAPI stack: SYCL and DPC++, Level Zero, the Unified Runtime, oneDNN, and the PTI and unitrace tracing tools. I saw a choice between treating that stack as a black box and working at whatever level a problem lived at. I chose the second, and the work ran at three levels.
Kernel library patches
The first level is the kernel libraries. Patches are built against the vendor's own sources inside the vendor's image, with Intel's toolchain, so the ABI matches what the serving engine loads and a whole class of mismatch disappears. The oneDNN work is a series of patches. One is a kernel-catalogue entry for Xe2 large-N GEMM shapes.
The rest serve the 4-bit-weight model path: weight reuse, local convert-and-scale, scale broadcast and a DPAS tail path. SYCL is the language of the recurrent-layer prefill fixes and of the paged-attention log-sum-exp output that lets attention merge exactly across memory tiers. Every oneDNN and SYCL change had to produce bit-identical results against the unpatched path on a quiet host before I kept it. That work is told in Bringing a serving stack up on new silicon.
I kept a rewrite that produced exact arithmetic with no whole-workload gain, because exactness is a property I want in the product.
Runtime calls on Level Zero
The second level is runtime calls. The memory tier uses Level Zero and unified shared memory directly for its pinned host pools, staging and fences.
Tracing without the vendor's overhead
The third level is tracing. The step-profiling suite associates Unified-Runtime calls with device kernel and copy intervals and with host waits, so I can follow a single token from the scheduler to the device and back to the client. The vendor tracing path kept memory on every driver call, which limited me to one instrumented capture at a time. I replaced it with a preload shim generated over the Unified-Runtime entry points, described on the LD_PRELOAD symbol interposition page.
Timing events turned out to serialise the copy engine. Every claim about overlap now gets an uninstrumented control before anyone acts on it, as told in The observer that changed the answer. I work below the framework when the problem is there. oneAPI, oneDNN, Level Zero and the Unified Runtime are Intel's software; my part is the patches and tooling built on them, for a single Arc Pro GPU.