repository·develop·Indexed 18 days ago
https://github.com/kokkos/kokkos-kernelsHigh-performance, performance-portable computational kernels for linear algebra (BLAS, Sparse BLAS) and graph operations using the Kokkos programming model. Features include the GMRES solver for sparse linear systems, Distance 2 Graph Coloring (D2GC) routines, and a framework for BLAS performance testing. Designed as a local, coarse-grained building block for shared-memory parallel programming.
The graph package provides high-performance implementations of graph coloring algorithms. These algorithms are used as a foundation for a symmetric multithreaded Gauss-Seidel implementation.
Key capabilities include:
Kokkos Kernels provides local computational kernels for linear algebra and graph operations using the Kokkos shared-memory parallel programming model.
Key characteristics:
Available Kernels include:
Important Usage Note:
Do NOT use or rely on the KokkosBlas::Impl namespace or anything in the src/impl/ directory. Use only the public interfaces located in src/.
The Kokkos Kernels Sparse API provides data structures and high-performance kernels for sparse linear algebra. Sparse containers store only non-zero indices and values, assuming all other entries are zero to save memory. The API is organized into several functional categories:
The KokkosSparse_Preconditioner class in the KokkosSparse::Experimental namespace provides an abstract base class for using Kokkos-based preconditioners with iterative linear solvers (such as the GMRES implementation in examples/gmres). It is designed to be compatible with other solver packages and is loosely based on the Trilinos IfPack2::Preconditioner class.
CRS: The type of the compressed row sparse matrix. All key types should be derivable from this type.KokkosGraph load-balance routines map irregular task sizes onto a dense work-item space. These routines are useful for redistributing work from tasks of varying sizes into a uniform space of work items.
LoadBalanceResult<View>
This structure stores the mapping for each work item:
tasks: A view containing the source task index for each work item.ranks: A view containing the rank (index) of that work item within its source task.load_balance: Use this when you are starting from raw task sizes (a view of work amounts per task).load_balance_exclusive: Use this when you already have an exclusive prefix sum (scan) of the task sizes available.load_balance_team: Use this for team-local cooperative load balancing within a Kokkos team.inclusive_prefix_sum_team: Performs an inclusive prefix sum locally within a team.#include <Kokkos_Core.hpp>
#include <KokkosGraph_LoadBalance.hpp>
using view_type = Kokkos::View<int*>;
void example(const view_type& taskSizes) {
auto result = KokkosGraph::load_balance(taskSizes);
(void)result;
}KokkosGraph provides routines to traverse the merge path induced by two ordered rank-1 inputs. Instead of generating a materialized merged output, these routines invoke a user-provided stepper for every step along the path. This is useful for performing custom work during a merge operation without the overhead of allocating a new merged view.
merge_path_thread: Used when the caller wants to perform custom per-step work within a single thread. It allows forwarding optional contexts (ctxs) to the stepper.merge_path_team: Partitions the merge path across a Kokkos team. It forwards a thread-level context to each stepper invocation.StepperContext: A struct recording the current positions in the inputs and the path:ai: Position in the first input (a).bi: Position in the second input (b).pi: Overall position in the path.StepDirection: An enum indicating which input is being consumed in the current step:StepDirection::a: The step consumes an element from input a.StepDirection::b: The step consumes an element from input b.// Example of a basic thread-level merge path traversal
#include <Kokkos_Core.hpp>
#include <KokkosGraph_MergePath.hpp>
template <class AView, class BView>
void example(const AView& a, const BView& b) {
auto stepper = [](KokkosGraph::StepDirection dir,
KokkosGraph::StepperContext step) {
(void)dir;
(void)step;
};
KokkosGraph::merge_path_thread(a, b, a.size() + b.size(), stepper);
}When using symmetric_gauss_seidel_apply, ensure your types satisfy the following constraints:
The input parameter types must match the types defined by the KernelHandle:
row_map value type must match KernelHandle::const_size_type.entries value type must match KernelHandle::const_nnz_lno_t.values value type must match KernelHandle::const_nnz_scalar_t.y_rhs_input_vec value type must match KernelHandle::const_nnz_scalar_t.x_lhs_output_vec value type must match KernelHandle::nnz_scalar_t.The views describing the matrix (row_map, entries, and values) must not use Kokkos::LayoutStride. They should use a non-strided layout (e.g., Kokkos::LayoutLeft or Kokkos::LayoutRight).
When developing or configuring Kokkos Kernels, be aware of the distinction between user-visible cache variables and internal regular variables:
KokkosKernels_ (e.g., KokkosKernels_ENABLE_THING). These are intended to be set by the user via the command line or ccmake.KOKKOSKERNELS_ENABLE_THING). These are used within the CMake logic to implement the actual configuration and are not intended for direct user manipulation in the cache.The KokkosKernels::Experimental::KokkosKernelsHandle provides a generic set of get, create, and destroy member functions to manage specialized sub-handles associated with specific algorithms. These sub-handles allow for fine-grained control over the state and configuration required by individual kernels (like SpGEMM, SpADD, or GMRES) without cluttering the main handle.
// General pattern for sub-handle management
KernelHandeType* get_kernel_handle();
void create_kernel_handle(Args...);
void destroy_kernel_handle();KokkosKernels uses two independent mechanisms for components:
ENABLE_COMPONENT_* and ENABLE_ALL_COMPONENTS): These BOOL flags determine which library source files are actually compiled into the library.ENABLED_COMPONENTS): This STRING flag determines which component tests are registered with the test runner.Key Interaction Rules:
ENABLED_COMPONENTS has no effect on which source files are compiled.ENABLE_COMPONENT_* flags do not affect which tests are registered.To use the KokkosGraph merge routines, the following conditions must be met:
AView, BView, and CView must be rank-1 Kokkos views.merge_into overloads, c.size() must exactly equal a.size() + b.size().Kokkos Kernels provides generic graph coloring capabilities used for applications like Gauss-Seidel and multigrid aggregation. The algorithms are categorized into two main types based on the coloring constraint:
Additionally, the library provides a Graph coloring handle which extends the standard KokkosKernels handle to include options specific to these coloring algorithms.