Technology · Runtime

Intel oneAPI

Intel's oneAPI stack is what ActiveKV's native engine and its kernel patches are built against, inside the vendor's own toolchain for ABI match.

ActiveKVIntel Arc Pro GPUSYCL · Level Zero · oneDNN
The stack in cross-section outlined: the three levels I worked at, down to one Arc Pro GPU
  • 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.

Cold 32K-token prefill · one Intel Arc Pro GPU
Before21.54 sWith the entry17.23 s

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.

Host · pinned pools
Arc Pro GPU · staging
fence
pages staged this step
a buffer is reused only after the fence clears

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.

One token, host and device on one clock
host API calls
device intervals
uncertainty
The two sides share no identifiers, so the tooling associates them by time and prints its clock-conversion uncertainty on every figure.

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.