Shared support for onnx-light in ORT#
onnx_light_ort/common_light_to_ort/ builds the static target
onnx_light_ort::common_light_to_ort. It adapts native onnx-light execution
to an ORT host’s current tensors and kernel context. Both
Custom-op bridge: onnx-light called by ORT and EP bridge: onnx-light called by ORT depend on it.
It contains no ops/EP registration, descriptor or factory ownership.
The current LeakyReluKernel retains one native kernel and its alpha
attribute. Each Compute call validates CPU memory, supported floating-point
type, matching output type, rank,
dimensions, checked element/byte counts, non-null nonempty buffers, alignment
and non-overlap before borrowing payloads. It owns neither the input/output
storage nor the ORT context and retains none of them between calls.
GetUnaryTensorBuffers shares these checks with LogKernel. Both kernels
preserve float16, bfloat16, float32 and float64 storage. Log dispatches directly
to onnx-light-cpu’s matching typed function, using its default tuning; LeakyRelu
passes the original typed tensor views to onnx-light’s native kernel.
The numerical dependency remains private to this common library;
neither the incoming common library nor ONNX Runtime is linked.
Native exceptions propagate to the bridge’s C ABI boundary; api_status.h
provides the shared exception-to-status conversion used at those boundaries
and by the entry-point library.
Actual allocation capacity remains part of the real host’s valid tensor
contract; see Architecture.
Unit tests#
ctest --test-dir build -L common_light_to_ort --output-on-failure
ctest --test-dir build -R common_light_to_ort_unit --output-on-failure
The component’s tests/test_leaky_relu_kernel.cc exercises the real adapter
and numerical kernel using a minimal explicit C API test host. It covers
repeated vector/matrix/scalar/empty/rank-16 execution, input preservation,
missing inputs/outputs, device/type/rank rejection, negative dimensions,
element and byte-count overflow, null or overlapping buffers, unchanged
status propagation, metadata cleanup and recovery after errors.
These native tests need no ORT installation or mocking framework. The fixture can supply invalid metadata that real ORT usually rejects before dispatch. The separately enabled real-ORT suite also checks caller-provided aligned/unaligned buffers and direct IO-bound outputs.