oneMath is an open-source implementation of the oneMath specification. It can work with multiple devices using multiple libraries (backends) underneath. The oneMath project was previously referred to as oneMKL Interfaces.
oneMath is part of the UXL Foundation.
There are two oneMath selector layer implementations:
Run-time dispatching: The application is linked with the oneMath library and the required backend is loaded at run-time based on device vendor (all libraries should be dynamic).
Example of app.cpp with run-time dispatching:
#include "oneapi/math.hpp" ... cpu_dev = sycl::device(sycl::cpu_selector()); gpu_dev = sycl::device(sycl::gpu_selector()); sycl::queue cpu_queue(cpu_dev); sycl::queue gpu_queue(gpu_dev); oneapi::math::blas::column_major::gemm(cpu_queue, transA, transB, m, ...); oneapi::math::blas::column_major::gemm(gpu_queue, transA, transB, m, ...);
How to build an application with run-time dispatching:
if OS is Linux, use icpx compiler. If OS is Windows, use icx compiler. Linux example:
$> icpx -fsycl –I$ONEMATH/include app.cpp $> icpx -fsycl app.o –L$ONEMATH/lib –lonemath
Compile-time dispatching: The application uses a templated backend selector API where the template parameters specify the required backends and third-party libraries and the application is linked with the required oneMath backend wrapper libraries (libraries can be static or dynamic).
Example of app.cpp with compile-time dispatching:
#include "oneapi/math.hpp"
...
cpu_dev = sycl::device(sycl::cpu_selector());
gpu_dev = sycl::device(sycl::gpu_selector());
sycl::queue cpu_queue(cpu_dev);
sycl::queue gpu_queue(gpu_dev);
oneapi::math::backend_selector<oneapi::math::backend::mklcpu> cpu_selector(cpu_queue);
oneapi::math::blas::column_major::gemm(cpu_selector, transA, transB, m, ...);
oneapi::math::blas::column_major::gemm(oneapi::math::backend_selector<oneapi::math::backend::cublas> {gpu_queue}, transA, transB, m, ...);
How to build an application with compile-time dispatching:
$> clang++ -fsycl –I$ONEMATH/include app.cpp $> clang++ -fsycl app.o –L$ONEMATH/lib –lonemath_blas_mklcpu –lonemath_blas_cublas
Refer to Selecting a Compiler for the choice between icpx/icx and clang++ compilers.
Header-based and backend-independent Device API can be called within sycl kernel or work from Host code (device-rng-usage-model-example). Currently, the following domains support the Device API:
oneapi/math/rng/device.hpp header file.Supported domains include: BLAS, LAPACK, RNG, DFT, SPARSE_BLAS
Supported compilers include:
What should I download?
Functional Testing Build Only Documentation CMake (version 3.13 or newer) Linux* : GNU* GCC 5.1 or higherThe oneMath project is governed by the UXL Foundation and you can get involved in this project in multiple ways. It is possible to join the Math Special Interest Group (SIG) meetings where the group discusses and demonstrates work using this project. Members can also join the Open Source and Specification Working Group meetings.
You can also join the mailing lists for the UXL Foundation to be informed of when meetings are happening and receive the latest information and discussions.
You can contribute to this project and also contribute to the specification for this project. Please read the CONTRIBUTING page for more information. You can also contact oneMath developers and maintainers via UXL Foundation Slack using #onemath channel.
You can find the oneMath release schedule and works already in progress towards future milestones in GitHub's Milestones section. If you are looking for a specific task to start, consider selecting from issues that are marked with the help wanted label.
Distributed under the Apache license 2.0. See LICENSE for more information.
Q: What is the difference between the following items?
A:
The oneAPI Specification for oneMath defines the SYCL interfaces for performance math library functions. The oneMath specification can evolve faster and more frequently than implementations of the specification.
The oneAPI Math Library (oneMath) project is an open source implementation of the specification. The project goal is to demonstrate how the SYCL interfaces documented in the oneMath specification can be implemented for any math library and work for any target hardware. While the implementation provided here may not yet be the full implementation of the specification, the goal is to build it out over time. We encourage the community to contribute to this project and help to extend support to multiple hardware targets and other math libraries.
The Intel(R) oneAPI Math Kernel Library (oneMKL) project is an Intel product provided as part of the Intel(R) oneAPI Base Toolkit. It is used for the Intel backends of oneMath. Its C++ API is very similar to the oneMath specification. It is highly optimized for Intel CPU and Intel GPU hardware.
Q: I'm trying to use oneMath in my project using FetchContent, but I keep running into ONEMATH::SYCL::SYCL target was not found problem when I try to build the project. What should I do?
A: Make sure you set the compiler when you configure your project. E.g. cmake -Bbuild . -DCMAKE_CXX_COMPILER=icpx.
Q: I'm trying to use oneMath in my project using find_package(oneMath). I set oneMath/oneTBB and Compiler environment first, then I built and installed oneMath, and finally I tried to build my project using installed oneMath (e.g. like this cmake -Bbuild -GNinja -DCMAKE_CXX_COMPILER=icpx -DoneMath_ROOT=<path_to_installed_oneMath> .) and I noticed that cmake includes installed oneMath headers as a system include which ends up as a lower priority than the installed Intel(R) oneAPI Math Kernel Library package includes which I set before for building oneMath. As a result, I get conflicts between Intel(R) oneAPI Math Kernel Library and installed oneMath headers. What should I do?
A: Having installed oneMath headers as -I instead on system includes (as -isystem) helps to resolve this problem. We use INTERFACE_INCLUDE_DIRECTORIES to add paths to installed oneMath headers (check oneMathTargets.cmake in lib/cmake to find it). It's a known limitation that INTERFACE_INCLUDE_DIRECTORIES puts headers paths as system headers. To avoid that:
EXPORT_NO_SYSTEM property set to true and you won't see the issue.PROPERTIES NO_SYSTEM_FROM_IMPORTED true for your target. E.g: set_target_properties(test PROPERTIES NO_SYSTEM_FROM_IMPORTED true).RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4