Backends¶
KOKKOS_ENABLE_<BACKEND> macros are defined when the corresponding backend
was enabled at configuration time, with -DKokkos_ENABLE_<BACKEND>=ON.
This page lists them, along with the backend-specific memory spaces and options.
Note
Application code should rarely need these macros. Instead of naming a
concrete execution space such as Kokkos::Cuda or Kokkos::OpenMP, use
Kokkos::DefaultExecutionSpace and Kokkos::DefaultHostExecutionSpace.
Likewise, prefer Kokkos::DefaultExecutionSpace::memory_space and
Kokkos::HostSpace over backend-specific memory spaces. This keeps your
code portable across backends.
The legitimate use of these macros is interoperability with the underlying programming model, as shown below.
Execution and memory spaces¶
Test these macros for existence, e.g. #ifdef KOKKOS_ENABLE_SERIAL. See
Backend selection in the Configuration Guide for the restrictions on
combining backends. Device backends also provide memory spaces of their own,
which only exist when the backend is enabled.
Macro |
Execution space |
Backend-specific memory spaces |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
See Execution Spaces and Memory Spaces for details.
Interoperability with the backend programming model¶
Guarding code with the backend macro lets you hand Kokkos resources to native libraries or kernels, for example a CUDA stream:
#include <Kokkos_Core.hpp>
void do_work() {
#ifdef KOKKOS_ENABLE_CUDA
Kokkos::Cuda space;
cudaStream_t stream = space.cuda_stream();
// hand the stream to a CUDA library or a hand-written CUDA kernel
#endif
}
Backend-specific options¶
These follow the same naming rule and are documented alongside their CMake option under Backend-specific options in the Configuration Guide.
Macro |
Description |
|---|---|
|
Relaxed constexpr functions are enabled for the CUDA backend. |
|
Relocatable device code (RDC) is enabled for the CUDA backend. |
|
Relocatable device code (RDC) is enabled for the HIP backend. |
|
Relocatable device code (RDC) is enabled for the SYCL backend. |