AMD is merging its ZenDNN work into oneDNN, the library Intel built and an open foundation now governs, and both companies have named it the default x86 CPU backend for PyTorch. For anyone running inference on a CPU, the vendor-specific fork era is ending.
Two companies that have spent four decades trying to sell you a different processor have agreed to share the same math library. AMD and Intel announced today that oneDNN will be the default open-source library for x86 acceleration inside PyTorch, and AMD is folding its own ZenDNN optimizations into it rather than keeping them in a separate project.
The news was first spotted by Phoronix and is laid out in the joint statement summarized by SD Times. AMD has also joined the UXL Foundation, which governs oneDNN, as a Steering Member. Until now it was a general contributor.
Why there were two libraries in the first place #
oneDNN started life at Intel as a set of hand-tuned deep learning primitives, the convolutions, matrix multiplies and activation functions that do the heavy lifting when a model runs. PyTorch, TensorFlow, ONNX Runtime and OpenVINO all lean on it for CPU work. The catch was that Intel tuned it for Intel silicon.
AMD’s answer was ZenDNN, a downstream fork that kept the oneDNN API but swapped in kernels written for Zen cores. It worked, and it got very fast on EPYC, but it meant anyone deploying on a mixed fleet had to think about which build of which library sat underneath their framework. Maintaining two near-identical code paths is the kind of tax nobody budgets for until it bites.
Under the new arrangement, AMD’s Zen-specific work goes upstream into oneDNN itself, and developers pick up the best path for whichever x86 chip they land on from a single library.
The x86 group finally ships something you can use #
The decision came out of the x86 Ecosystem Advisory Group, the body AMD and Intel set up in late 2024 to stop the instruction set from drifting apart. Its early work was mostly about ISA alignment, which matters but is invisible to most people. A shared AI library is the first outcome that lands directly in a framework developers actually import.
It also ties into the other joint project. The companies say they are collaborating on AI Compute Extensions, the new x86 matrix-multiply ISA, with PyTorch support planned through future oneDNN updates. We covered the toolchain side of that when ACE support landed in GCC 17. Having one library to carry those kernels means the instructions can show up in PyTorch once, instead of twice on two schedules.
What it does not change #
This is a CPU story. AMD’s GPU stack is still ROCm, and the company continues to run its own PyTorch partnerships on that side. oneDNN does carry experimental support for AMD GPUs through SYCL, but nobody is suggesting it replaces ROCm on Instinct hardware.
The UXL Foundation itself has been around since September 2023 and sits under the Linux Foundation’s Joint Development Foundation, so oneDNN is no longer Intel’s library in the governance sense, even if Intel engineers wrote most of it. AMD taking a steering seat makes that neutrality a lot easier to believe.
For anyone running inference on a Ryzen workstation or an EPYC box, the practical upshot should arrive quietly: a stock PyTorch install that does the right thing on Zen without a separate plugin. That is the whole point. No timeline for the first merged ZenDNN code paths has been given yet.