Extensions to support copy! for CuStridedView (and friends!)

[kshyatt]

This PR creates some logic to allow StridedViews backed by CuArrays (and, soon, any generic GPU array) to hook into the existing GPUArrays.jl infrastructure for broadcasted copies without having to replicate all the indexing logic or create arrays of indices.

I've created two extensions:

• one generic GPUArrays.jl one so that we can reuse logic for CUDA and AMD
• one CUDA.jl specific-one which is needed because the KernelAdaptor type for adapting CuArrays to be usable inside kernels is not a subtype of anything in GPUArrays.jl. A similar extension would be needed for AMDGPU.jl.

For now this only supports copy! but I think other uses are already covered (for CUDA.jl at least) by TensorOperations.jl.

[kshyatt]

I'll also add a BuildKite pipeline for this

[codecov]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

ℹ️ You can also turn on project coverage checks and project coverage reporting on Pull Request comment

Thanks for integrating Codecov - We've got you covered ☂️

[github-actions]

Your PR no longer requires formatting changes. Thank you for your contribution!

[kshyatt]

I thought so too but then it seems to work for transpose and adjoint (because the axes are then the same), which surprised me. I agree about restricting the element types. I think I need more extensive tests here tbh.

…

On Wed, Feb 25, 2026 at 10:23 PM Jutho ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In ext/StridedCUDAExt.jl <#40 (comment)> : > @@ -0,0 +1,17 @@ +module StridedCUDAExt + +using Strided, CUDA +using Strided: StridedViews +using CUDA: Adapt, KernelAdaptor +using CUDA: GPUArrays + +const ALL_FS = Union{typeof(adjoint), typeof(conj), typeof(identity), typeof(transpose)} + +function Base.copy!(dst::StridedView{TD, ND, TAD, FD}, src::StridedView{TS, NS, TAS, FS}) where {TD, ND, TAD <: CuArray{TD}, FD <: ALL_FS, TS, NS, TAS <: CuArray{TS}, FS <: ALL_FS} + bc_style = Base.Broadcast.BroadcastStyle(TAS) + bc = Base.Broadcast.Broadcasted(bc_style, identity, (src,), axes(dst)) + GPUArrays._copyto!(dst, bc) This is probably not generally correct, for example if FS and FD are different, say one is identity and the other is conj. For GPUArrays, probably we should only have TD and TN being <:Numbers and FS and FD being only typeof(identity) or typeof(conj) ? — Reply to this email directly, view it on GitHub <#40 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGKJY5COO3ZYNB42UHVN734NYHDRAVCNFSM6AAAAACV7IGOX6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTQNJXGA3TGMBZGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kshyatt]

I've added more tests including for size-0 arrays and square ones, things still seem to be working! Maybe I've written the test wrong? Otherwise I think the getindex call is applying the conj as appropriate?

[kshyatt]

This probably needs QuantumKitHub/StridedViews.jl#26 and a tag first

[Jutho]

I was assuming that you would unpack the parent array from the StridedView, but you are just passing the StridedView objects to GPUArrays._copyto!. In that case, if this ends up calling the StridedViews getindex implementation, it will indeed automatically apply the necessary function like conj. But can this just work within a GPU kernel? I don't know anything about this, nor even thow GPUArrays._copyto! works.

[kshyatt]

I was assuming that you would unpack the parent array from the StridedView, but you are just passing the StridedView objects to GPUArrays._copyto!. In that case, if this ends up calling the StridedViews getindex implementation, it will indeed automatically apply the necessary function like conj. But can this just work within a GPU kernel? I don't know anything about this, nor even thow GPUArrays._copyto! works.

So what happens behind the scenes is the backing CuArray (or WLOG ROCArray) gets converted into the "kernel compatible" bits type device array -- but very crucially, this new kernel-friendly array has the same pointer and offset. Then all the indexing logic for a StridedView is used in the copying kernel -- all GPUArrays needs is that you have implemented such logic correctly (as it seems you have).

[Jutho]

That's great. Looking at the GPUArrays._copyto! implementation, there might actually be quite a few (if not all) of the Strided.jl functionality that could be made working on a GPU, even if it is not the most efficient implementation possible.

[kshyatt]

That's great. Looking at the GPUArrays._copyto! implementation, there might actually be quite a few (if not all) of the Strided.jl functionality that could be made working on a GPU, even if it is not the most efficient implementation possible.

Absolutely. Contra to my usual tendency I didn't add this here to keep this PR more or less "skinny" and reviewable, but would be happy to add more things as we need them.

[Jutho]

I don't think transpose and adjoint really make sense for scalar element types.

[Jutho]

Ah wait, it is applied to the matrix. Never mind, then it does make sense.

[kshyatt]

Is there another element type we want to test with? Maybe a StridedView of a BlockArray or something?