[kshyatt]

Idea is to allow us to take advantage of JuliaGPU/CUDA.jl#2616 and the AMDGPU equivalent by avoiding round-trip copies when using VI with GPU arrays.

[kshyatt]

I think a DenseArray can be N-dimensional which isn't really a Vector, so I've updated that and created a BLASMatrix and BLASArray pair to encapsulate things that should be allowed.

[codecov]

Codecov Report

❌ Patch coverage is 98.14815% with 1 line in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/scalar.jl	96.77%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/VectorInterface.jl	100.00% <100.00%> (ø)
src/abstractarray.jl	98.78% <100.00%> (+0.36%)	⬆️
src/interface.jl	100.00% <ø> (ø)
src/scalar.jl	96.77% <96.77%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[kshyatt]

So currently this doesn't make use of the device-side storage in cuBLAS and rocBLAS. If we like the overall approach, I will then add some specializations via extensions here and elsewhere that will use them.

[Jutho]

I think these types of convert(T, ...) calls will have to be updated to support Scalar inputs, and to then call the corresponding BLAS library call. This can be done via package extensions, but it would be good to contemplate if we can do without, or at least as much as possible.

[kshyatt]

I think for a Scalar backed by a Vector these calls should just convert to the "number within" since CPU BLAS doesn't have this pointer mode at all. For all other (e.g. GPU based) array types it can stay as-is, I think?

[kshyatt]

Fail looks like an Enzyme bug, EnzymeAD/Enzyme.jl#4051

[wsmoses]

or rather actually a julia problem, where 1.13.4 broke otherwise functional code in 1.13.3. I'd rec to pinning 1.13.3 for now