oneDNN: the README tells practitioners to use a framework instead

The README lists ten frameworks and tells you to use one

The opening section answers a question the reader did not ask. It says deep learning practitioners should use one of the applications enabled with oneDNN, and then lists ten of them: Apache SINGA, DeepLearning4J, Flashlight, llama.cpp, ONNX Runtime, OpenNMT CTranslate2, the OpenVINO toolkit, PaddlePaddle, PyTorch and Tensorflow.

So the library does not present itself as the thing you program against. It presents itself as the set of primitives those frameworks call into, and the audience it names is framework developers interested in improving application performance on CPUs and GPUs.

The list has one loose end. Five of the ten entries carry an asterisk, on DeepLearning4J, Flashlight, PaddlePaddle, PyTorch and Tensorflow, and nothing in the visible text says what the asterisk means. There is no footnote, no legend and no sentence referring back to it, so a reader cannot tell whether those five are distinguished by support tier, by licence, by governance or by nothing more than the author's preference. It is the kind of mark that survives from an earlier version of the page.

The other framing detail is institutional. The project states it is part of the UXL Foundation and is an implementation of the oneAPI specification for the oneDNN component, which is a different kind of claim from being a company library: the specification is the contract and this repository is one implementation of it.

Five architectures are listed, three are labelled experimental

The System Requirements section opens by listing the platforms oneDNN supports, and the list has five entries: Intel 64 or AMD64, Arm 64-bit Architecture, OpenPOWER and IBM Power ISA, IBMz z/Architecture, and RISC-V 64-bit. Immediately below it there is a warning that Power ISA, IBMz and RISC-V support is experimental with limited testing validation.

So three of the five platforms in the supported list are described as experimental two paragraphs later. That is a real ambiguity for anyone building a support matrix from this file, because a reader who stops at the first list will conclude RISC-V is supported and a reader who reads the warning will conclude it is provisional.

The graphics side has a similar split. The opening paragraph says the library is optimised for Intel 64 and AMD64 processors, AArch64 processors and Intel Graphics, with experimental support for NVIDIA GPUs, AMD GPUs, OpenPOWER, IBMz and RISC-V. The detailed GPU list is entirely Intel's, from Arc A-series through Data Center GPU Flex and Max, Arc B-series and Arc Pro B-series, and integrated graphics across Core Ultra and Core series. So GPU support outside Intel is described as experimental in the summary and absent from the detail.

The build-from-source requirements then narrow the field again, naming Intel 64 or AMD64, AArch64, PPC64 and s86x, with no RISC-V at all.

The CPU list names unreleased parts by code name

The optimised CPU list is written as a rename table. Each family is named as it is sold today with the name it had before in parentheses, so Intel Xeon Scalable processors carry the parenthetical formerly Skylake, Cascade Lake, Cooper Lake, Ice Lake, Sapphire Rapids and Emerald Rapids, and Intel Core Ultra processors carry Meteor Lake, Arrow Lake, Lunar Lake and Panther Lake. Intel Xeon 6 covers Sierra Forest and Granite Rapids, and the Xeon CPU Max series is annotated as the former Sapphire Rapids HBM.

Then the list goes past anything you can buy. It includes a future Intel Core processor with AVX10.2 instruction set support, code name Nova Lake, and a future Intel Xeon processor with the same instruction set support, code name Diamond Rapids. The GPU list does the same with future discrete parts on the Xe3p-XPC architecture, code name Crescent Island, and future integrated graphics for Nova Lake.

This is useful information, because a library that names a future instruction set is telling you it has code paths for hardware that does not exist yet. It also means the support matrix has to be read as a roadmap with a rename column attached, and that the parenthetical names will need editing every time a vendor renames a line.

The dispatcher picks the newest ISA at run time, and future ones ship off

The performance story on x86 is a run-time decision rather than a compile-time one. The README says that on a CPU based on Intel 64 or AMD64 architecture, oneDNN detects the instruction set architecture at run time and uses just-in-time code generation to deploy the code optimised for the latest supported ISA.

The second sentence is the one to plan around. Future instruction sets may have initial support in the library disabled by default, and enabling them requires run-time controls, with a dedicated documentation page for the CPU dispatcher control.

So a new instruction set arrives off, and the decision to use it belongs to the application rather than to the library. That is a defensible default, since a wrong answer from a dispatcher is a crash or a silent miscompile rather than a slow path, and it means anyone chasing a new Xeon generation has a knob to find before they have a speedup.

The GPU list has no equivalent statement, and one platform carries a warning of its own: on macOS, applications that use oneDNN may need to request special entitlements if they use the hardened runtime, with the linking guide covering it. That is a packaging constraint rather than a performance one, and it is the only place the README talks about what it takes to ship an application that links the library.

RISC-V is a supported platform and not a build requirement

The build-from-source list has three items: an operating system with Intel 64 or AMD64, AArch64, PPC64 or s86x architecture support, a C++ compiler with C++11 support, and CMake 3.13 or later. RISC-V is not in it, although it is in the supported platform list further up and in the experimental list in the opening paragraph. Three lists, three different answers.

The C++11 floor is also worth noting for a 2026 library, since it is a decade-old standard and it means the code is not relying on anything newer.

Building the documentation is a longer list with a wide spread of minimum versions: Doxygen 1.8.5 or later, Doxyrest 2.1.2 or later, Sphinx 7.4.7 or later, sphinx-book-theme 1.2.0 or later, sphinx-copybutton 0.5.2 or later, and graphviz 2.40.1. Doxygen 1.8.5 is from the middle of the last decade while Sphinx 7.4.7 is current, so a documentation build needs two toolchains of very different vintages side by side. The section closes by warning that configurations of CPU and GPU engines may introduce additional build time dependencies, which is the sentence that tells you the three-item list is a floor rather than a complete answer.

Four Python tools, a Python 3.7 target, one generated directory excluded

A C++ library with four Python linters configured in one file, and the reason is visible in what they are pointed at. The mypy section lists its files as scripts, .github and doc, so the Python being checked is build scripts, continuous integration and documentation tooling rather than a Python library. pyright, black and isort cover the same ground, and all four exclude `doc/doxyrest`, the directory Doxyrest generates from the C++ headers.

The settings are specific enough to be revealing:

[tool.isort]
profile = "black"
line_length = 80
src_paths = [".github", "scripts", "doc"]
supported_extensions = ["py", "pyi", "in"]

That extension list is the tell. A third extension, `in`, appears alongside Python and stub files because the documentation pipeline has templated files that are processed into Python, and the tools are taught about them rather than ignoring them. Black runs in preview mode with the unstable string processing feature enabled, at a line length of 80, and mypy is configured to skip following imports, to install missing types, and to disable three error codes including import errors.

Then there is the version target, which is the most dated thing in the repository's configuration: pyright is set to a Python 3.7 language version while the C++ side requires CMake 3.13 and the documentation side wants Sphinx 7. So the tooling that maintains the build and the docs is pinned to a 2017 Python, while the things it maintains are not.

The examples are matmul, quantization and four precisions

The examples directory is the best available statement of what the library actually spends its effort on, and it is a list of matrix multiplication variants. There are CPU matmul examples for the coordinate and sparse row formats, for grouped matmul, for weights compression, for a host-provided scalar scale, plus a matmul benchmark, an f8 quantization example, and a batch normalisation on unsigned eight-bit data with binary post-operations.

Around that sit convolutional and recurrent networks in several precisions: CNN inference and training in f32, bf16 and int8, RNN inference in f32 and int8, and CPU-only variants of each. Two examples exist in both C and C++, which is how the C interface is demonstrated without a separate example set, and there is a cross-engine reorder pair doing the same thing. Then a getting-started example, a GPU OpenCL interoperability example, and a `graph/` subdirectory for the graph API.

So four precisions and two sparse formats account for most of the surface a reader sees, which is a reasonable proxy for where a deep learning library's users spend their time. The release line is moving in the same pattern: v3.13.2 on 2026-08-26, v3.13.3 on 2026-09-25, and then v3.14-rc on 2026-10-02, a release candidate rather than a final, with the last push to the default branch dated 2026-10-04.

Editorial conclusion

Read it as the layer inside a framework rather than as something to call directly, because that is how the README positions it, with a list of ten applications to use instead. If you are evaluating support for a machine, the two documents that matter disagree with each other in a specific way: the platform list includes Power ISA, IBMz and RISC-V while a warning marks exactly those three as experimental with limited testing validation, and the build-from-source list leaves RISC-V out entirely. If you are chasing performance on x86, the dispatcher behaviour is the part to understand: the instruction set is detected at run time, and support for instruction sets that do not exist yet ships disabled until you turn it on.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes