Correctness issue when indexing "big" `oneArray`s

[cncastillo]

I was debugging some Buildkite CI errors in KomaMRI and narrowed the issue down to indexing into a matrix that's “too big.” This is a MWE:

using oneAPI
x = randn(Float32, 513, 3)
x_one = convert(oneArray, x)

julia> y = x[:, 1:2]
513×2 Matrix{Float32}:
 -0.785065    0.605889
 -0.138269   -0.886778
 -0.418909   -0.302653
 -0.0957128  -0.974546
  ⋮          
 -0.486535   -0.594906
  1.42615    -1.00182
  0.0519026  -0.0332484

julia> y_one = x_one[:, 1:2]
513×2 oneArray{Float32, 2, oneAPI.oneL0.DeviceBuffer}:
 -0.785065    0.0
 -0.138269    0.0
 -0.418909    0.0
 -0.0957128   0.0
  ⋮          
 -0.486535    0.0
  1.42615    -1.00182
  0.0519026  -0.0332484

Which is very interesting, as it does not happen when using views:

julia> y = @view x[:, 1:2]
513×2 view(::Matrix{Float32}, :, 1:2) with eltype Float32:
 -0.785065    0.605889
 -0.138269   -0.886778
 -0.418909   -0.302653
 -0.0957128  -0.974546
  ⋮          
 -0.486535   -0.594906
  1.42615    -1.00182
  0.0519026  -0.0332484

julia> y_one = @view x_one[:, 1:2]
513×2 oneArray{Float32, 2, oneAPI.oneL0.DeviceBuffer}:
 -0.785065    0.605889
 -0.138269   -0.886778
 -0.418909   -0.302653
 -0.0957128  -0.974546
  ⋮          
 -0.486535   -0.594906
  1.42615    -1.00182
  0.0519026  -0.0332484

I am using Julia 1.11.6 and oneAPI 2.0.3. Not really sure what could be the cause, but when I use x = randn(Float32, 512, 3) it starts working again, so it seems to be related to the size of the array.

[michel2323]

Tried to reproduce, but it seems to have resolved itself in latest release. Can you confirm @cncastillo?

[cncastillo]

Using Julia v1.11.7 and oneAPI v2.2.0 I can still can reproduce this on my Linux system (Ubuntu 24.04). I attach the manifest of the environment in case that is useful:

Manifest.toml.txt

EDIT: you might need to increase the size of the array (changing 513 to something larger)

[michel2323]

oneAPI v2.2.0 is really old. Can you try with v2.4.0?

[cncastillo]

Used Julia 1.12.1 and oneAPI v2.4.0 and can still reproduce the error.