muSOLVER API Reference
This reference covers the muSOLVER APIs supported in MUSA SDK 5.2. It begins with the muSOLVER library families and problem models, then documents the dense solver APIs for QR factorization, LU factorization and solve, orthogonal and unitary matrix generation, and generalized eigenvalue problems.
1. Introduction
1.1 What Is muSOLVER
muSOLVER provides GPU-accelerated solver routines for linear algebra on MUSA devices. The library follows an umbrella model: different API prefixes identify dense solvers, sparse solvers, sparse refactorization routines, and multi-GPU routines.
This umbrella model helps when reading the headers because the prefix identifies the solver family before the function name identifies the operation. This reference introduces the family model first, then narrows the MUSA SDK 5.2 scope to the supported dense solver APIs.
1.2 muSOLVER Components and Problem Models
The API prefix identifies the solver family and the problem class.
| Prefix | Meaning | Typical problem class | MUSA SDK 5.2 API reference coverage |
|---|---|---|---|
musolverDn | Dense solver APIs | Dense factorizations, dense linear solves, and dense eigenvalue problems | Included in this reference |
musolverSp | Sparse solver APIs | Sparse linear systems and sparse least-squares problems | Concept only; no API entries |
musolverRf | Sparse refactorization APIs | Repeated sparse solves with a shared sparsity pattern | Concept only; no API entries |
musolverMg | Multi-GPU solver APIs | Distributed dense matrix operations | Concept only; no API entries |
1.2.1 Dense Solver APIs (musolverDn)
Dn means dense. The musolverDn APIs operate on dense matrices stored in device memory. Dense solver routines commonly target linear systems in which all matrix entries are represented explicitly:
The dense APIs in this reference include QR factorization, LU factorization and solve, generated orthogonal or unitary matrices, and generalized symmetric or Hermitian eigenvalue problems. The corresponding problem models include:
Here, A and B are dense matrices, X is the solution or eigenvector matrix, Q is an orthogonal or unitary matrix, P is a permutation matrix, and L and U are triangular factors.
1.2.2 Sparse Solver APIs (musolverSp)
Sp means sparse. Sparse solver APIs target matrices in which only nonzero entries are stored. These APIs are commonly used for sparse linear systems:
and sparse least-squares problems:
Sparse solver declarations may appear in the public headers, but they are not included as supported API entries in this MUSA SDK 5.2 reference.
1.2.3 Sparse Refactorization APIs (musolverRf)
Rf means refactorization. Refactorization APIs target a sequence of sparse linear systems in which the coefficient values change but the sparsity pattern remains the same:
This model avoids repeating the full symbolic analysis when the ordering, pivoting, and sparsity pattern of the triangular factors are unchanged across solves. Refactorization declarations may appear in the public headers, but they are not included as supported API entries in this MUSA SDK 5.2 reference.
1.2.4 Multi-GPU APIs (musolverMg)
Mg means multi-GPU. Multi-GPU APIs describe solver operations over matrices distributed across multiple MUSA devices, typically using a device grid and distributed matrix descriptors. Multi-GPU declarations may appear in the public headers, but they are not included as supported API entries in this MUSA SDK 5.2 reference.
1.3 Document Scope in MUSA SDK 5.2
Use this reference to check the functions, types, parameters, and status values supported for muSOLVER in MUSA SDK 5.2. The API reference body covers only dense solver entries with the musolverDn prefix.
Note: Some muSOLVER declarations may appear in the public headers but are absent from this reference. These declarations are experimental in MUSA SDK 5.2 and are provided for reference only.
1.4 Supported Dense Solver Capabilities
| Capability | Representative APIs |
|---|---|
| Dense solver context management | musolverDnCreate, musolverDnDestroy |
| QR factorization | musolverDnSgeqrf, musolverDnDgeqrf, musolverDnCgeqrf, musolverDnZgeqrf |
| LU factorization and solve | musolverDnSgetrf, musolverDnSgetrs |
| Orthogonal or unitary matrix generation | musolverDnSorgqr, musolverDnCungqr |
| Generalized symmetric or Hermitian eigenvalue solve | musolverDnSsygvd, musolverDnChegvd |
1.5 How to Use This Document
Start with Chapter 1 to understand the muSOLVER family prefixes and the 5.2 reference scope. Use Chapter 2 for the dense solver usage model, matrix layout rules, and workflow overview. Use Chapter 3 to check return values, handle lifecycle, shared helper and context rules, data types, function signatures, parameter lists, and supported API entries.
2. Using the muSOLVER API
2.1 Dense Solver Model
The APIs in Chapter 3 use the musolverDn prefix and operate on dense matrices stored in device memory. Sparse, refactorization, and multi-GPU workflows are outside the scope of this MUSA SDK 5.2 API reference.
The matrix data arguments point to MUSA device memory, and each routine receives a musolverDnHandle_t handle that identifies the dense solver execution context.
The supported routines follow LAPACK-style conventions. Matrix dimensions are passed as integers. Leading dimensions describe the storage stride for column-major dense matrices. Factorization routines overwrite the input matrix with factorized data, and solve or generation routines consume those factors in later calls.
2.2 Handles and Execution Context
Each API entry takes a musolverDnHandle_t argument named handle. The handle must identify a valid dense solver context before the routine is called. The handle type is defined as a muBLAS handle type, so dense solver execution is tied to the library context supplied by the application.
Create the dense solver handle with musolverDnCreate before calling the routines in this reference, and destroy it with musolverDnDestroy when the dense solver context is no longer needed.
Chapter 3.3 documents the handle-lifecycle helper functions. Shared workspace-query and diagnostic conventions are described in Sections 2.4 and 2.8. This release does not include separate reference entries for stream selection or logger control.
2.3 Formats Reference
The MUSA SDK 5.2 musolverDn APIs covered here use dense vectors and dense
column-major matrices in device memory. The conventions in this section apply
to the QR, LU, solve, orthogonal or unitary generation, and generalized
eigenvalue routines in Chapter 3.
2.3.1 Index Base Format
The dense APIs covered here use dimensions, leading dimensions, and memory layouts
that follow standard C host-side indexing conventions when describing storage
offsets. For example, when a dense matrix is stored in column-major order, the
element in row i and column j is addressed with an offset such as
A[i + j * lda].
The LU factorization family is a special case for pivot information. The
getrf and getrs routines use pivot arrays whose elements are 1-based, as
described in the parameter tables for those routines.
2.3.2 Vector (Dense) Format
Dense vectors are stored linearly in device memory. This convention applies to
vector arguments in this reference, such as Householder scalar arrays (TAU or tau),
eigenvalue output arrays (D), and diagnostic arrays (devInfo or info).
For a length-n vector
the device storage is a linear array containing the elements in order: