[pocl] Enable float add and min/max atomics via cl_ext_float_atomics - #737
Draft
vchuravy wants to merge 2 commits into
Draft
[pocl] Enable float add and min/max atomics via cl_ext_float_atomics#737vchuravy wants to merge 2 commits into
vchuravy wants to merge 2 commits into
Conversation
Contributor
Benchmark ResultsShow table
Benchmark PlotsA plot of the benchmark results have been uploaded as an artifact to the workflow run for this PR. |
Member
|
Have you seen JuliaGPU/OpenCL.jl#453? Might want to copy some of the logic from there. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #737 +/- ##
==========================================
+ Coverage 64.77% 64.89% +0.12%
==========================================
Files 24 24
Lines 2024 2031 +7
==========================================
+ Hits 1311 1318 +7
Misses 713 713 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The SPIR-V backend refuses to translate a module containing an atomic fadd
unless the extension guarding it has been listed:
LLVM ERROR: The atomic float instruction requires the following SPIR-V
extension: SPV_EXT_shader_atomic_float_add
Enzyme's reverse mode runs into this because it accumulates gradients with
atomic fadd, so reverse-mode AD over a POCL kernel fails to compile outright.
Derive the extension list from the device the way `supports_fp16`/`supports_fp64`
already are, keyed off the corresponding OpenCL extension (`cl_ext_float_atomics`,
which PoCL advertises). Listing an extension only permits it -- nothing is
emitted unless a module needs those instructions -- so kernels that do not use
float atomics are unaffected. An explicit `extensions=` keyword still wins, and
`default_spirv_extensions` gives later extensions an obvious home.
Verified end-to-end: with this change, reverse-mode Enzyme over a POCL kernel
compiles, runs and produces correct gradients.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…pabilities Atomix lowers `@atomic A[i] += x` and `@atomic max(A[i], x)` on floats to LLVM `atomicrmw fadd`/`fmin`/`fmax`, which the SPIR-V backend only translates when SPV_EXT_shader_atomic_float_add resp. SPV_EXT_shader_atomic_float_min_max is permitted. Derive both from the per-precision cl_ext_float_atomics capability bitfields instead of the bare extension string, requiring the global and local memory bits like OpenCL.jl does, and expose the bitfields as device properties. Adds an `Atomics` testsuite entry exercising add/min/max for Int32, UInt32, Float32 and (where supported) Float64 on all backends, and a POCL-specific check that both extensions are permitted on pocl's CPU device while an explicit `extensions=` still wins. Assisted-by: Claude Code (Fable 5.1)
vchuravy
force-pushed
the
vc/pocl-float-atomics
branch
from
September 7, 2026 19:22
4cc0e6e to
0d0a4ad
Compare
Member
|
CUDA failure on 1.10/1.11 seem real? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #600 (the last open item: float atomics) — fixes #671.
Problem
Atomix lowers
@atomic A[i] += xand@atomic max(A[i], x)on floats to LLVMatomicrmw fadd/fmin/fmax. The SPIR-V backend refuses to translate a module containing them unless the guarding extension has been permitted, so on the CPU backend every float atomic fails to compile:Enzyme's reverse mode hits the first one too, because it accumulates gradients with atomic fadd.
Change
nanoOpenCL: add thecl_ext_float_atomicsconstants and expose the per-precision capability bitfields asdev.single_fp_atomic_capabilities,dev.double_fp_atomic_capabilities,dev.half_fp_atomic_capabilities(zero when the extension is absent).default_spirv_extensions(dev)permitsSPV_EXT_shader_atomic_float_addandSPV_EXT_shader_atomic_float_min_maxwhen the device natively supports the operation for Float32 or Float64, in both global and local memory (same rule as OpenCL.jl'shas_fp_atomics). Listing an extension only permits it, so kernels without float atomics are unaffected. An explicitextensions=keyword still wins.Atomicsentry running@atomicadd/max/min forInt32,UInt32,Float32and, wheresupports_float64,Float64on every backend (skipped whensupports_atomicsis false).runtests.jladditionally checks that pocl's CPU device gets both extensions and that the override works.pocl's CPU device reports native add and min/max atomics for single and double precision (global and local), and none for half.
Not in this PR
atomic_*_fallback!for that). Not needed for pocl's CPU device.test/atomics.jl.SPIRV_LLVM_Backend_jllnewer than 22.1.x ([SPIR-V] Rewrite extractvalue over aggregate spv_extractv result llvm/llvm-project#200065 plus one pending fix).🤖 Generated with Claude Code
https://claude.ai/code/session_01DnYMbgSmZQr7KtRUwei63a