RadixSort fails on NVIDIA's OpenCL driver: its default block size of 512 exceeds the reported kernel limit of 256

Aperta
  • Qualcosa non va?
#201 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
julia
Ambito
backend, performance

Direzione di ricerca

Start with SortTuning and OpenCLExt to trace how OpenCL GPU devices choose radix_block_size; then inspect the RadixSort cases in test/generic/workspace.jl and the “reduce: block sizes” testset in reduce_dims.jl. Check how MAX_BLOCK_SIZE is set in test/runtests.jl, since it uses the device limit while launches are checked against a kernel limit. Done when the default radix sort fits the kernel limit and the affected OpenCL tests pass.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

With NVIDIA's OpenCL driver, every RadixSort call with the default settings throws before launching anything:

using OpenCL                      # with NVIDIA's ICD, e.g. OCL_ICD_FILENAMES=libnvidia-opencl.so.1
import AcceleratedKernels as AK
AK.sort!(CLArray(rand(Float32, 1000)); alg=AK.RadixSort())

ERROR: ArgumentError: Work-group size (512, 1, 1) has more than 256 work-items, the maximum for this kernel

SortTuning's default radix_block_size is 512. KernelInterface checks each launch against CL_KERNEL_WORK_GROUP_SIZE, and NVIDIA's driver reports 256 for that. Every length and layout fails the same way (100 and 10^4 elements, dims=1 on 100×3, dims=2 on 3×3000, 32- and 64-bit keys), while RadixSort(block_size=256) sorts correctly. Auto() never picks RadixSort on OpenCL GPUs, so only an explicit alg=AK.RadixSort() runs into this. The test suite hits it in test/generic/workspace.jl (the RadixSort cases) and in the "reduce: block sizes" testset of reduce_dims.jl, which tries block sizes up to MAX_BLOCK_SIZE. For OpenCL that is the device's max_work_group_size (1024), not the kernel's limit.

Nothing launches with an invalid configuration: KernelInterface's check_work_group_size rejects the launch, so the user gets an ArgumentError, not a crash.

Environment: AK main (fdd0a6f, 0.5.11), OpenCL.jl 1.0.0, KernelAbstractions 0.10.4, KernelInterface 0.4.3, spirv2clc_jll 0.2.7, Julia 1.12.7. NVIDIA driver 615.78.08 (OpenCL platform "CUDA 13.4.96"), on an RTX 5080 (Linux 7.2) and an RTX 6000 Ada. The driver lacks cl_khr_il_program, so OpenCL.jl translates the SPIR-V to OpenCL C with spirv2clc.

Triage: the limit is the driver's, and it doesn't depend on the kernel:

  • Every kernel reports CL_KERNEL_WORK_GROUP_SIZE == 256, while CL_DEVICE_MAX_WORK_GROUP_SIZE is 1024. That includes AK's radix, merge, scan and reduce kernels, a one-line KA copy kernel, and hand-written OpenCL C built directly with cl.Program(source=...), with or without -cl-std. So it isn't spirv2clc output or register pressure.
  • Even a kernel declared __attribute__((reqd_work_group_size(1024, 1, 1))) reports 256, while CL_KERNEL_COMPILE_WORK_GROUP_SIZE says (1024, 1, 1). The two answers contradict each other.
  • Launches past the reported limit work. Hand-written kernels at local sizes of 512 and 1024 (one with a barrier and local memory) give correct results, and with KernelInterface's check overridden, RadixSort(block_size=512) and block_size=1024 sort 100 and 10^6 Float32/Int64 keys correctly.

So the driver under-reports. Still, the per-kernel value is the only limit OpenCL defines, and nothing tells which larger launches are safe, so AK should stay within it rather than have KernelInterface skip the check.

Other back-ends:

  • CUDA: KA compiles a kernel with a static work-group size with that size as its thread limit, so max_threads_per_block equals the block size. On the RTX 5080 the radix kernels report 512 at block_size=512 and 1024 at 1024.
  • Metal and oneAPI: KernelInterface checks the pipeline's maxTotalThreadsPerThreadgroup or the kernel's maximum group size the same way. Register-heavy kernels can get a lower limit there, but RadixSort at 512 passes the M1 CI. I haven't measured it further.

On every back-end, a too-large block is an ArgumentError before launch. AK never queries a kernel's limit itself: check_block_size only bounds block sizes at 1024.

Suggested fix:

  1. In OpenCLExt, give GPU devices SortTuning(radix_block_size=256). OpenCL GPUs have no measured tuning (the comment says so), and 256 is what every other AK kernel algorithm uses by default. A clamp at launch time wouldn't work, because the block size is a compile-time constant of the kernels and sets the size of the workspace's histograms.
  2. In test/runtests.jl, derive OpenCL's MAX_BLOCK_SIZE from a compiled kernel's limit (for example, KI.max_work_group_size of a trivial kernel), not from the device's max_work_group_size.
  3. Optionally, report the constant 256 to NVIDIA, with the reqd_work_group_size kernel as the reproducer.
Lingua principale
Julia
Stelle
204
Fork
20
Merge medio
2g 19h
PR unite (30g)
41

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di JuliaGPU/AcceleratedKernels.jl

Tutte le issue di JuliaGPU/AcceleratedKernels.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.