Register CPU kernels for the generator ops at opset 22

[Arne H Juul (arnej27959)]

Discovered when trying to use RandomNormal (opset 22) in a unit test:

RandomNormal, RandomNormalLike, RandomUniform, RandomUniformLike and Multinomial were revised in ONNX opset 22, but their CPU kernels stayed registered at their original start version with no end version, which matches that version exactly. As a result these ops had no CPU kernel at opset 22+. Cap the old registrations at 21 and add new ones at 22, the same split EyeLike and the CUDA Random kernels already use.

Type constraints are unchanged (float and double).

Description

Splits the CPU kernel registrations for RandomNormal, RandomNormalLike, RandomUniform,
RandomUniformLike and Multinomial at opset 22: the existing registrations are capped with an
end version of 21, and a new registration is added at 22 for each op. docs/OperatorKernels.md is
regenerated to match, and each op gets an opset 22 test.

Type constraints are unchanged — the opset 22 registrations declare the same float/double
constraints as the earlier ones.

Motivation and Context

All five ops were revised in ONNX opset 22, but their CPU kernels stayed registered at their
original start version (1, or 7 for Multinomial) with no end version. A kernel registered that
way matches its start version exactly: VerifyVersion in kernel_registry.cc only takes the
range branch when kernel_end_version != INT_MAX, on the reasoning that without an end version ORT
cannot know whether a later op revision added something the kernel mishandles. Since the version
that gets matched is the op's schema since_version — 1 for opsets 1-21 and 22 for opsets 22+ —
these ops had no CPU kernel at all at opset 22 and later.

Version matching happens before type matching, so this is not type-specific: an opset 22
RandomNormal with dtype=float, squarely inside the registered type constraints, still failed
with Could not find an implementation for RandomNormal(22).

EyeLike was revised in the same opset and was updated at the time; it shows the intended pattern
of capping the old registration and adding a new one. CUDA already has that split for the four
Random ops, so this was CPU-side drift. This PR applies the same treatment to all five ops.

Opset 22 also widened these schemas to the full set of float types by adding bfloat16. That is
deliberately not implemented here — supporting a new dtype is a separate feature, whereas this
change restores a working kernel lookup for the types already supported.

On the tests

OpTester's default Run() pre-assigns every node to an EP and, when no EP has a matching kernel,
logs a warning and returns without failing. The obvious version of these tests therefore passed
against the unfixed code. The new tests run with an explicitly specified CPU EP, which leaves node
assignment to the graph partitioner, so a missing registration surfaces as a session initialization
failure. All five new tests were verified failing before this change and passing after.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Copilot]

Pull request overview

Registers CPU kernels for five generator operators revised in ONNX opset 22.

Changes:

• Splits CPU kernel registrations at opset 22.
• Adds CPU-specific opset 22 tests.
• Regenerates kernel documentation.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
onnxruntime/core/providers/cpu/generator/random.cc	Defines versioned generator kernels.
onnxruntime/core/providers/cpu/cpu_execution_provider.cc	Registers the new kernel versions.
onnxruntime/test/providers/cpu/generator/random_test.cc	Adds opset 22 CPU coverage.
docs/OperatorKernels.md	Documents supported version ranges.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.