[pocl] Enable SPV_EXT_shader_atomic_float_add where supported - #737
Draft
vchuravy wants to merge 1 commit into
Draft
[pocl] Enable SPV_EXT_shader_atomic_float_add where supported#737vchuravy wants to merge 1 commit into
vchuravy wants to merge 1 commit into
Conversation
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>
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:
|
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.
The SPIR-V backend refuses to translate a module containing an atomic fadd unless the extension guarding it has been listed:
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.
Change
Derive the extension list from the device, the same way
supports_fp16/supports_fp64already are, keyed off the corresponding OpenCL extensioncl_ext_float_atomics(which PoCL advertises on this machine).Listing an extension only permits it — nothing is emitted unless a module actually needs those instructions — so kernels that don't use float atomics are unaffected. An explicit
extensions=keyword still wins, and the newdefault_spirv_extensionshelper gives later extensions an obvious home.Verification
End-to-end, reverse-mode Enzyme over a POCL kernel now runs and produces correct gradients:
That run needed a
SPIRV_LLVM_Backend_jllnewer than the currently pinned 22.1.8, because reverse mode also trips two LLVM SPIR-V backend bugs:SPIRVInstructionSelector::selectExtractVal, already fixed upstream by [SPIR-V] Rewrite extractvalue over aggregate spv_extractv result llvm/llvm-project#200065 (fd1f9225458a, 2026-06-07) — not in 22.1.8. Bumping the JLL past that commit is all that is needed.OpCompositeExtractpointee-type mismatch on pointers extracted from aggregates, still present on trunk; fix pending upstream.I verified this by overriding the JLL to point at a patched trunk
llc; with the shipped 22.1.8 the same test fails withFailed to translate LLVM code to SPIR-V. This PR is independent of those and is needed regardless — without it the module does not compile even with a fixed backend.x-ref #583, EnzymeAD/Enzyme.jl#3405, EnzymeAD/Enzyme.jl#3309.
🤖 Generated with Claude Code