oneDPL: the data parallel C++ library in the oneAPI set

An implementation of a specification, not a standalone library

oneDPL is described as an implementation of the oneAPI specification for the oneDPL component, and it is part of the UXL Foundation. That framing matters more than it might appear. This is not a library that sits beside your project and works on its own; it is one component of a wider specification, and its behaviour is tied to a compiler and a toolchain that also carry the rest of that system.

The APIs it provides are intended to cut down the effort of writing Data Parallel C++, which the documentation calls DPC++, for high performance parallel applications across devices. In other words, the value proposition is a set of parallel algorithms and data structures that behave the same way whichever device executes them, so that the same source can target a CPU, a GPU or an accelerator without the developer rewriting the algorithm for each.

The project is written in C++, the primary language of the repository, and the default branch is main. The repository is not archived, and the last push was on 2026-10-20, so the component is being worked on continuously.

For the audience, the documentation is blunt about the audience it serves: developers working inside the oneAPI toolchain. The companion samples live in a separate repository, the oneAPI-samples project under Libraries/oneDPL, and the full documentation set is published at uxlfoundation.github.io/oneDPL.

The Base Toolkit is a hard prerequisite, not a suggestion

The prerequisites section of the project documentation is short. To use oneDPL you must install the Intel oneAPI Base Toolkit, and the documentation points to the Intel system requirements page for the specifics of what a given configuration needs.

This is the single most important practical fact about the project. oneDPL is not shipped as a package you can install from a registry and compile against with any C++ toolchain. It works with the Intel oneAPI DPC++/C++ Compiler, and the Base Toolkit is where that compiler and the surrounding runtime come from. If your build pipeline is defined by a different compiler, or if your organisation has a policy against installing a vendor toolchain, oneDPL is not on the table.

The trade-off is real in both directions. What you gain is a single programming model that covers multiple devices, and a component API that is specified rather than improvised, so the same code can move between the CPU and an accelerator. What you give up is compiler neutrality, and with it the ability to build the same codebase for several toolchains without a separate path.

The documentation also points to the release notes for version-specific detail, hosted as documentation/release_notes.rst in the repository. That is the file to read when you need to know which oneDPL version corresponds to the toolkit in your image, since the version numbers of the component and the toolkit are not the same string.

The examples directory is the clearest map of the API

When a component is specified rather than productised, the examples are often the only place where the surface area is visible in plain terms. The repository ships an `examples/` directory, and the directories inside it read like a catalogue of what the library actually does: `examples/convex_hull/`, `examples/dot_product/`, `examples/dynamic_selection/`, `examples/gamma_correction/`, `examples/histogram/`, `examples/maxloc_reductions/`, `examples/pSTL_offload/`, `examples/random/` and `examples/stable_sort_by_key/`.

Several of those names describe offload rather than algorithms, and that is the important detail. `pSTL_offload` points at the parallel standard template library path, where standard C++ algorithms can be executed on a device. `dynamic_selection` implies the choice of execution device is made at runtime rather than fixed in the source. `maxloc_reductions` and `stable_sort_by_key` are the classic reduction and sorting patterns that a data parallel library is judged on, because they combine data movement with a computation. `gamma_correction` and `histogram` are the image and signal processing shapes, and `random` is there because parallel random number generation has its own requirements.

Taken together, the list shows a library that is aiming at the general parallel algorithm workload rather than at one specialised domain. For an engineer evaluating it, these are the programs to read first, because they show the calling conventions and the data parallel idioms the component expects, and they are the same programs that ship in the oneAPI-samples repository.

A repository shaped for a specification process

The top level of the repository looks different from an ordinary library, and the differences are informative. Alongside the familiar CMakeLists.txt, include/, test/, documentation/ and examples/ directories there are `rfcs/`, `integration/`, `licensing/`, `env/`, `extras/`, `make/`, a `third-party-programs.txt` file, a `CREDITS.txt` file, a `MAINTAINERS.md` and a `SECURITY.md`.

The `rfcs/` directory is the clearest signal that this is a specification-driven project: proposals live in the repository, alongside the code, and are worked through by a community process. `integration/` suggests the component is wired into the wider oneAPI system, with tests that check it against the rest of the toolchain rather than only in isolation. `licensing/` and `third-party-programs.txt` exist because a specification component has to account for the third party code that ships inside it, and `CREDITS.txt` records attribution.

The `env/` and `extras/` directories point to environment setup and optional tooling, which is what you would expect for a component whose prerequisites are a whole SDK rather than a single library. The presence of `make/` alongside `CMakeLists.txt` says both build styles are supported, and the `.clang-format` file at the root means the code style is enforced by tooling rather than by convention.

For a user, most of this is invisible. For anyone who wants to propose a change or report a defect, it explains the shape of the contribution process: the discussion happens in the repository and in the foundation's channels, and the code follows the specification.

Version numbers, governance and how to reach the maintainers

The release tags carry a year and a build number, with oneDPL-release-2022.13.0 published on 2026-07-13, oneDPL-release-2022.12.0 on 2026-05-04 and oneDPL-2022.11.0-release on 2025-12-27. The pattern is worth parsing before you use it in a release plan. The 2022 component version line is what is shipping in 2026, so the number in the tag is a component version that continues independently of the calendar year of the release. The tag names have also drifted slightly, with the most recent using a different prefix format from the one before it, which is a small sign of a versioning scheme that is still settling.

Governance sits with the UXL Foundation, and the documentation explains how to take part: members can join the Open Source and Specification Working Group meetings, which discuss the evolution of oneDPL and the other oneAPI components under the foundation. The oneAPI specification itself lives at oneapi-spec.uxlfoundation.org, which is where the contract for this component is defined.

There are several routes for support. Issues and suggestions go through GitHub issues on the repository, developers are reachable through the UXL Foundation Slack in the #onedpl channel, and the foundation also runs mailing lists for the working groups. Security issues are handled separately: the documentation directs potential vulnerability reports to the Intel Security Center, and a Security Policy is published in SECURITY.md. That last point is worth noting for adopters, because a component hosted under a foundation but built by a vendor still has a vendor-run vulnerability reporting path.

The contribution process itself is described in CONTRIBUTING.md, and a code of conduct is included in the repository.

Apache 2.0 with the LLVM exception, and what the exception buys you

The licence is Apache License Version 2.0 with LLVM exceptions, and the full text and copyright notice are in the LICENSE.txt file. The repository is also listed with the Apache 2.0 badge in the README, so the two statements agree on the base licence.

The LLVM exception is the part to read rather than skim. The base Apache 2.0 grant is permissive: you can use the library in commercial software, in closed source products, without a source disclosure obligation, and the usual attribution and notice conditions apply to distributed copies. The exception then narrows one specific aspect of patent licensing that the base licence does not address on its own, and it is the reason the licence is expressed as a modified Apache grant rather than plain Apache 2.0. What it means for your organisation in practice depends on your own patent situation, and that is a question for your counsel rather than a summary you should rely on.

The separate `licensing/` directory and the `third-party-programs.txt` file matter for the same reason at a different level. When a component ships with or links against third party code, the terms of that code travel with it, and the file listing those components is where you check what else applies to your build. Combined with the `CREDITS.txt` attribution file, the repository gives you what you need to assemble a distribution notice, though assembling it correctly for your distribution is still your work.

A note on trademark rather than copyright: the documentation states that Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries, and that other names and brands may be claimed as the property of others. So the licence lets you redistribute the code, and the trademark statement is there to keep you from implying that the UXL Foundation or Intel endorses your product.

Where oneDPL is the wrong choice

The clearest case against is compiler neutrality. If your project has to build with several compilers, or on platforms where the Intel oneAPI toolchain is not available, then depending on a component that requires the DPC++ compiler and the Base Toolkit closes off options that other parallel C++ approaches leave open. The base toolkit is also a large, licensed vendor installation, and putting it in a continuous integration image is a decision with procurement attached to it.

The second case is when the standard library already covers your need. The `pSTL_offload` example tells you that parallel standard template library support is part of the picture, and if your workload is a handful of familiar algorithms over vectors, the standard library plus your own threading is often the smaller commitment. oneDPL earns its place when the parallelism is the substance of the problem, not an optimisation applied to a trivial loop.

The third case is team familiarity. The programming model here is DPC++ specific, with device selection, USM allocators and queue based execution. A team that has never written data parallel C++ will spend its first weeks on the model rather than on the problem, and the documentation set, while complete, is written for people who already know the vocabulary. That is an adoption cost rather than a defect, but it is the one that decides projects.

The alternative worth naming is the alternative approach rather than a rival product: writing the same algorithms against a different parallel programming model, or using an open source parallel STL implementation that compiles with your existing toolchain. The difference in approach is exactly the one described above. oneDPL gives you a specified component with a device uniform API and a vendor supported toolchain behind it. An open source parallel STL gives you compiler neutrality and no toolchain dependency, and you carry the risk of supporting it yourself. Teams that need one specific accelerator, or that have already standardised on oneAPI, get more from the specified component. Teams that need to keep their build portable get more from the portable option.

Editorial conclusion

oneDPL is the right choice for a team building data parallel C++ that already licenses and installs the Intel oneAPI Base Toolkit, because it supplies the oneAPI component APIs in a form the DPC++ compiler can offload across devices. It is the wrong choice for a portable C++ project that must build with several compilers, and it is not a substitute for the standard library algorithms you already have. Before adopting it, confirm the Base Toolkit installation in your build images, read the release notes in documentation/release_notes.rst for the version your toolkit ships, and check licensing/ and third-party-programs.txt for the third party code the build pulls in.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. uxlfoundation/oneDPL on GitHub