Skip to content

Fix storage-level matrix-vector mul! with step-range vectors - #823

Open
maleadt wants to merge 1 commit into
mainfrom
tb/matvec-step-view
Open

maleadt wants to merge 1 commit into
mainfrom
tb/matvec-step-view

Conversation

@maleadt

@maleadt maleadt commented Oct 19, 2026 •

Copy link
Copy Markdown
Member

The storage-level mul!(y, tA, A, x, α, β) reshapes y and x to n×1 matrices and forwards to the matrix-matrix mul!, so back-ends that only overload gemm still get matrix-vector products. For a non-contiguous view, reshape returns a Base.ReshapedArray rather than a strided GPU array. The call then fell through to LinearAlgebra's CPU fallback, which fails with a scalar-indexing error on Julia 1.13 and with a MethodError on earlier versions. #775 introduced this; before it, the reshaped vectors went to GPUArrays' own kernel.

This keeps the forwarding when the reshape yields a strided GPU matrix (plain vectors and contiguous views), and otherwise runs generic_matmatmul! on the vectors directly. The test calls the storage-level mul! with step-range x and y for tA in 'N', 'T' and 'C'.

Fixes #816

The storage-level `mul!(y, tA, A, x, α, β)` reshapes both vectors to n×1
matrices and forwards to the matrix-matrix `mul!`, so back-ends with a
vendor gemm also handle matrix-vector products. For a non-contiguous view
that reshape returns a `Base.ReshapedArray`, which isn't a strided GPU
array, and the product fell through to LinearAlgebra's CPU fallback
(scalar indexing on Julia 1.13, a MethodError before).

Only forward when the reshape yields a strided GPU matrix, and otherwise
run the generic kernel on the vectors directly, as this method did before
#775.

Fixes #816

This branch has not been deployed

No deployments
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.

Storage-level matrix-vector mul! scalar-indexes step views

1 participant