[oneMKL][spblas] updated sparse::gemm routines spec, which adds supporting matrix storage layout #363
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goal:
for
sparse::gemm()
functionality, which is sparse matrix-dense matrix product, support dense matrix storage layout ofcolumn-major
as well asrow-major
.Details:
Currently, there is no parameter related to dense matrix storage layout in
spares::gemm()
API and assumes the dense matrices are inrow-major
matrix storage layout. In this PR, I propose to support below features:layout
of dense matrices of matrixB
andC
for bothrow-major
andcolumn-major
.B
matrix, so that we can handletransposed
case of matrixB
as well asnon-transpose
case.layout
information asoneapi::mkl::layout
, which consists ofrow_major
andcol_major
.Motivation:
As I mentioned above, current
sparse::gemm()
API-spec doesn't have parameters for dense matrix storage layout information and and matrix operation on B, which supports onlyrow-major
layout andnon-transpose
operation on matrixB
. So if a user needs to callsparse::gemm()
withcolumn-major
layout dense matrices and/ortranspose
operation on matrixB
, the user has to do extra works before and/or after usingsparse::gemm()
for their usage.By updating this proposed
sparse::gemm()
API, we can support directly for such cases without requiring additional steps. Also, as part of this proposal, I propose another enum class forlayout
information as well.