PyTorch adds system oneDNN option for CPU and XPU

PyTorch is gaining a supported build option to use a system-installed oneDNN for both its CPU path and the Intel XPU backend, rather than the copies it currently vendors.

Linux distributions such as Fedora already ship oneDNN and require packages to prefer system libraries over bundled ones. Until now the framework always built and statically linked its internal oneDNN tree for CPU work. With XPU enabled it also fetched and built a second static copy at configure time. That pattern breaks offline package builds, duplicates the library on disk, and keeps security and bug fixes in the system oneDNN from reaching PyTorch without a full rebuild.

The new path locates an installed oneDNN through its CMake package for both backends and can enforce a minimum version. oneDNN 3.x has kept a stable ABI and API across minor releases, which removes the main compatibility objection raised when the idea was first discussed in 2023. Downstream tests with Fedora’s oneDNN 3.14 against recent PyTorch releases passed XPU functional checks on Intel Arc hardware, apart from failures unrelated to the library.

One remaining edge case is that CPU code which turns on oneDNN’s experimental ukernels based only on the library version must also confirm the feature was actually compiled into the system build; otherwise the compile fails.