Skip to content

oneMKL potrf on GPU reports the failing column relative to its 32-column panel #755

Open

Description

@michel2323

On the GPU, oneMKL's potrf returns the wrong info when the matrix stops being positive definite after column 32. This is oneMKL 2026.1, through oneAPI_Support_jll 0.11.0, on an Intel Data Center GPU Max 1100.

  • Real types get the column's position inside its 32-column panel, i.e. (j - 1) % 32 + 1.
  • Complex types get panel * 1024 + position.

Columns 1 to 32 are reported correctly. The shim onemkl<T>potrf returns computation_error::info() unchanged, so the wrong value comes from oneMKL itself, not from oneAPI.jl.

Reproducer

using oneAPI, LinearAlgebra
using oneAPI: Support, sycl_queue, global_queue

n, j = 100, 50
G = randn(n, n); S = Matrix(Hermitian(G * G' / n + n * I)); S[j, j] = -1
A = oneMatrix(S)
q = sycl_queue(global_queue(oneAPI.context(A), oneAPI.device(A)))
lw = Support.onemklDpotrf_scratchpad_size(q, 'L', n, n)
Support.onemklDpotrf(q, 'L', n, A, n, oneVector{Float64}(undef, lw), lw)   # returns 18, expected 50

Observed values for an HPD matrix with A[j, j] = -1. Results are the same for 'L' and 'U'.

type n j info
Float32 / Float64 50 17 17
Float32 / Float64 50 33 1
Float32 / Float64 100 50 18
Float32 / Float64 100 100 4
Float32 / Float64 257 257 1
ComplexF32 / ComplexF64 100 50 1042
ComplexF32 / ComplexF64 100 97 3073
ComplexF32 / ComplexF64 257 254 7198

In every case the factor itself still follows LAPACK potf2. The first diagonal entry that is not a finite positive number is exactly column j, so a caller can recover the right column from the diagonal. getrf's info is correct. The environment variables OverrideDefaultFP64Settings and IGC_EnableDPEmulation make no difference.

Impact. cholesky, issuccess and isposdef only check whether info is nonzero, so they are unaffected. Only the exact column number is wrong, for example in a PosDefException. #754 makes LinearAlgebra.LAPACK.potrf! return info and marks these cases @test_broken.

Possible handling

  1. Report the bug to Intel, which is the real fix.
  2. Optionally work around it in Julia: when info > 0, take the first non-positive diagonal entry as the column. This costs one small diagonal copy on the failure path only, since the shim already synchronizes. If you prefer to carry a workaround, a separate test on the raw shim would keep tracking the oneMKL bug.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions