Skip to content

Make oneMKL sparse matrices AbstractGPUSparseArrays - #642

Merged
michel2323 merged 2 commits into
mainfrom
sparse-gpuarrays
Sep 25, 2026
Merged

michel2323 merged 2 commits into
mainfrom
sparse-gpuarrays

Conversation

@michel2323

@michel2323 michel2323 commented Sep 24, 2026 •

Copy link
Copy Markdown
Member

Fixes #627.

oneSparseMatrixCSR, oneSparseMatrixCSC and oneSparseMatrixCOO now subtype GPUArrays' AbstractGPUSparseMatrixCSR/CSC/COO, so the generic sparse functionality of GPUArrays.jl applies to them: broadcasting (zero-preserving functions keep the result sparse), sum/mapreduce along dimensions, norm/opnorm, findnz, triu/tril/kron, iszero, scalar indexing under @allowscalar, similar/copy/collect. The GPUArrays sparse testsuite is enabled for the CSR and CSC types (COO is excluded because GPUArrays' generic sparse broadcast only supports vectors, CSR and CSC).

Changes

  • Lazy oneMKL handles. GPUArrays' generic code constructs sparse matrices through the plain 4-argument constructor and resizes their storage, so the eagerly created oneMKL matrix handle (which pointed at the storage and required a queue synchronize per construction) is now created on the first oneMKL operation (oneMKL.sparse_matrix_handle) and dropped when the storage is replaced (copyto!, unsafe_free!). Empty matrices never get a handle; the wrappers short-circuit instead. Any element type can be stored; oneMKL operations still require Float32/Float64/ComplexF32/ComplexF64 with Int32/Int64 indices and throw a clear error otherwise. CSC matrices on oneMKL < 2025.3 now error at the first oneMKL operation instead of at construction.
  • On-device conversions (lib/mkl/sparse_conversions.jl): CSR↔CSC↔COO, _sptranspose/_spadjoint, sparse +/- (needed by GPUArrays' issymmetric, since oneMKL has no geam-like routine), and the COO operations GPUArrays forwards to (triu, tril, kron, reshape, droptol!), built from sortperm on integer keys and broadcasts.
  • Adapt/KernelAbstractions glue: device-side counterparts for kernels, get_backend, and adapt(oneArray, ::SparseMatrixCSC) returning a oneSparseMatrixCSC (as CUDA.jl and AMDGPU.jl do). This is a behavior change: previously the sparse matrix was densified.
  • Docs and tests updated; test/onemkl.jl gains interface, conversion, broadcast/reduction and lazy-handle tests.

Notes

michel2323 and others added 2 commits September 24, 2026 10:34
Subtype GPUArrays' AbstractGPUSparseMatrixCSR/CSC/COO so that the generic
sparse functionality of GPUArrays (broadcast, mapreduce, norms, findnz,
triu/tril/kron, indexing, similar/copy) applies to oneSparseMatrixCSR/CSC/COO,
and run the GPUArrays sparse testsuite on the CSR and CSC types.

The oneMKL matrix handle is now created lazily on the first oneMKL operation
and invalidated when the storage vectors are replaced (copyto!, unsafe_free!),
since GPUArrays' generic code constructs sparse matrices freely and resizes
their storage. As a consequence any element type can be stored; the oneMKL
operations still require Float32/Float64/ComplexF32/ComplexF64 values with
Int32/Int64 indices and error otherwise.

Conversions between the three formats, transposition/adjoint, sparse addition
and the COO structural operations (triu, tril, kron, reshape, droptol!) are
implemented on the device with generic operations (sortperm, broadcast).

adapt(oneArray, ::SparseMatrixCSC) now returns a oneSparseMatrixCSC, matching
CUDA.jl and AMDGPU.jl.

Fixes #627.
…ular ops

- Every sparse matrix now holds its own reference to its storage vectors,
  so unsafe_free! on one matrix no longer frees vectors shared with another
  (single-input broadcast outputs, type conversions).
- copyto! between sparse matrices of the same format accepts different
  element and index types, replacing the storage and dropping the handle
  instead of falling back to in-place or scalar GPUArrays methods.
- Empty triangular matrices with a unit diagonal act as the identity in
  trmv/trsv/trsm; with a non-unit diagonal the solves throw
  SingularException.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@codecov

codecov Bot commented Sep 24, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 83.96501% with 55 lines in your changes missing coverage. Please review.
✅ Project coverage is 80.76%. Comparing base (f110df6) to head (d24babb).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
lib/mkl/sparse_conversions.jl 62.96% 40 Missing ⚠️
lib/mkl/wrappers_sparse.jl 94.06% 7 Missing ⚠️
lib/mkl/array.jl 94.73% 6 Missing ⚠️
src/oneAPIKernels.jl 33.33% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #642      +/-   ##
==========================================
- Coverage   81.61%   80.76%   -0.85%     
==========================================
  Files          50       55       +5     
  Lines        3611     4087     +476     
==========================================
+ Hits         2947     3301     +354     
- Misses        664      786     +122     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@michel2323
michel2323 merged commit 82be34e into main Sep 25, 2026
5 checks passed
@michel2323
michel2323 deleted the sparse-gpuarrays branch September 25, 2026 12:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

mkl sparse arrays aren't AbstractGPUSparseArray

1 participant