Problem
Axiom's Kerr step graph cannot run on the released XDNA TOSA tier. It requires nonlinear FP32 ADD, SUB, MUL, MINIMUM, MAXIMUM, NEGATE, RECIPROCAL, RSQRT, comparisons, logical operations, and SELECT. XDNA 0.3.4 correctly rejects those operations and must continue to do so.
Axiom issue MicroPerceptron/axiom#64 and PR MicroPerceptron/axiom#66 prove the existing provider lifecycle on real Kerr data, but only with BF16 IDENTITY; the 989-node FP32 integrator remains entirely on CPU. There is no honest XDNA-only Kerr simulation with the current compiler authoring surface.
Requested backend-local tier
Add a provider-local, explicitly named experimental fused BF16 Kerr tile program that produces an XDNP artifact without expanding the portable TOSA capability.
The intended unit is one coarse ray tile and many/all integration steps per submission:
- BF16 position/momentum storage with a separately documented internal accumulation/approximation contract;
- exact integer/Boolean lane state where practical;
- capture, disk-crossing, escape, and unresolved outputs plus required boundary records;
- static ray-count/step-count envelope;
- direct-bound input/output slots;
- no host round-trip for per-step intermediates;
- offline/catalog compilation supported so serving does not require Python;
- explicit capability/tier identity distinct from general TOSA BF16 or FP32.
If native reciprocal, reciprocal-square-root, comparisons, or selection cannot be implemented correctly in the pinned AIE2P toolchain, the ticket should close with that negative evidence rather than inserting CPU fallback or advertising portable operators.
Acceptance evidence
- compiler/helper contract is bounded and does not accept arbitrary source from a guest;
- generated
XDNP loads through the existing XDNA runtime;
- on-metal dispatch through
/dev/accel/accel0 with direct-binding/staging diagnostics;
- a small deterministic ray-tile oracle against Axiom's CPU FP32 reference;
- event-class and boundary tolerances defined before tuning;
- compile, upload, device execution, readback, and decode timings separated;
- general FP32 TOSA remains unsupported and its fail-loud tests remain intact.
This is a provider-local coarse kernel, not a request to smuggle Kerr operations into the public portable TOSA surface.
Problem
Axiom's Kerr step graph cannot run on the released XDNA TOSA tier. It requires nonlinear FP32
ADD,SUB,MUL,MINIMUM,MAXIMUM,NEGATE,RECIPROCAL,RSQRT, comparisons, logical operations, andSELECT. XDNA 0.3.4 correctly rejects those operations and must continue to do so.Axiom issue MicroPerceptron/axiom#64 and PR MicroPerceptron/axiom#66 prove the existing provider lifecycle on real Kerr data, but only with BF16
IDENTITY; the 989-node FP32 integrator remains entirely on CPU. There is no honest XDNA-only Kerr simulation with the current compiler authoring surface.Requested backend-local tier
Add a provider-local, explicitly named experimental fused BF16 Kerr tile program that produces an
XDNPartifact without expanding the portable TOSA capability.The intended unit is one coarse ray tile and many/all integration steps per submission:
If native reciprocal, reciprocal-square-root, comparisons, or selection cannot be implemented correctly in the pinned AIE2P toolchain, the ticket should close with that negative evidence rather than inserting CPU fallback or advertising portable operators.
Acceptance evidence
XDNPloads through the existing XDNA runtime;/dev/accel/accel0with direct-binding/staging diagnostics;This is a provider-local coarse kernel, not a request to smuggle Kerr operations into the public portable TOSA surface.