[christiangnrd]

JLArrays, the CPU reference back-end used to test GPUArrays and downstream packages without a GPU, still targets KernelAbstractions 0.9. The vendor back-ends (CUDA, AMDGPU, Metal, oneAPI, OpenCL) have moved to KernelAbstractions 0.10, which builds on KernelInterface, so a test environment using JLArrays can't move along with them.

This ports JLArrays to KernelAbstractions 0.10 and drops 0.9. JLBackend becomes a KernelInterface back-end in the same shape as the vendor ports: it converts arguments to POCL device arrays and forwards compilation, launches and device queries to KernelAbstractions' POCL back-end, which is what runs KA 0.10 kernels on the CPU. The KernelAbstractions and KernelInterface testsuites now run on JLArrays, skipping the same POCL-only tests the vendor back-ends skip.

JLArrays used to reduce, sort, scan and search with Base on an Array wrapping its storage, because AcceleratedKernels' kernels did not run on its KA 0.9 back-end. They do now, so JLArrays takes the same AcceleratedKernels code paths as the GPU back-ends instead of bypassing them. This is also what makes those operations work on arrays of isbits unions, which the testsuite requires since #835: an Array can't wrap their storage, while POCL's device arrays (as of KernelAbstractions 0.10.5) read the selector bytes JLArrays keeps after the data. The cost is test time, as every operation now compiles a kernel: the reduction, sorting and scan testsets take about twice as long.

Along the way:

• convert.(T, ::JLArray) failed to compile, because JLArrays wrapped Refs before POCL could recognize a Ref of a type. JLArrays now converts only what the Ref holds.
• JLArray kernels compute indices in Int like POCL's own, instead of the Int32 KernelAbstractions uses on GPUs, which keeps LLVM from vectorizing over work-items (~7% on a 2048×2048 element-wise kernel).
• Arguments are converted without allocating per launch (c .= a .+ b goes from 1344 to 480 bytes).

This is breaking, hence JLArrays 0.5: JLBackend(; static) is gone, since KA 0.10's CPU back-end has no static scheduling, and so is JLDeviceArray (JLArrays are POCL CLDeviceArrays in kernels). POCL's SPIR-V back-end cannot lower 128-bit integers, so Int128 is no longer tested with JLArrays.

The macOS runners, which run tests one at a time, were already close to the 60-minute job limit, so the limit is raised to 90 minutes.

[christiangnrd]

I bumped CI timeout to 90 minutes since the POCL backend of KA 0.10 increases testsuite runtime and the macOS runners with only 1 job were right on the edge (either side)

I cancelled the latest Buildkite run since the GHA timeout increase was the only change since the last successful run.

[christiangnrd]

Not sure this is the best approach but Claude redesigned the JLArrays storage to support bits union.

[maleadt]

Did you rebase out my changes? Looking at your force push, you went from https://github.com/JuliaGPU/GPUArrays.jl/commits/784d123d40e549406b292c57a61bfb1fe6c1d5ed/ to https://github.com/JuliaGPU/GPUArrays.jl/commits/764ad56eba1db4cf6a617083edf2ccaaea145ede/, which lacks the result of my rework last week (as reflected by the edited top post).

[christiangnrd]

I think I might have I missed the rework. The commit is probably still on my laptop I’ll revert my changes in a few hours.

[maleadt]

No worries. Maybe just have your Claude session incorporate those changes? It cleaned-up the implementation a bit, too.

[christiangnrd]

Ok I had Claude recover your changes, rebase, and then reincorporate the storage backing I'm unsure about.

Tests should pass once KA cpu backend has bitsunion support

[maleadt]

I reworked this together with #827, now that KernelAbstractions 0.10.5 is out (with JuliaGPU/KernelAbstractions.jl#944).

I dropped the Vector{T} storage commit. Main's byte layout already keeps the selector bytes after the data, which is where POCL's device arrays (as of 0.10.5) look for them, so kernels only need maxsize pointing there. The part that really needed Vector{T} storage was JLArrays' host fallbacks for reductions, sorting, scans and findall, which wrap the storage in an Array. Those only existed because AcceleratedKernels' kernels didn't run on JLBackend under KA 0.9. They do now, so I removed the fallbacks and JLArrays takes the same AK paths as the GPU back-ends. That fixes the union tests, and in an earlier measurement it also cut using JLArrays from about 4.4 s to 0.6 s. The cost is test time: the reduction and scan testsets take about twice as long, which the 90-minute timeout should absorb.

On #827: I kept the KernelInterface port and the padding removal (2048² Float32 matmul on an RTX 5080: 5.1 ms → 3.5 ms; the PTX only uses vector shared loads without the padding). I dropped the -zero accumulator and the 1:min(TILE, K - k0) loop. The loop made the kernel about 7% slower, and Base's matmul returns +0.0 for [-0.0;;] * [1.0;;] on Julia 1.10–1.13 (only 1.15-DEV gives -0.0), so the -0.0 change can be a follow-up once LinearAlgebra settles.

[christiangnrd]

Nice! I didn't like that workaround at all.

Regarding #827, once that's merged and we have a version of KI.barrier that doesn't require the device memory flag it'll be identical to the Metal.jl scalar kernel so we'll be able to deprecate that one