Skip to content

GPUCommonMath: double functions, 64-bit bit counts, atomic load/store… - #15986

Merged
davidrohr merged 1 commit into
AliceO2Group:devfrom
f3sch:gpu/math
Oct 20, 2026
Merged

davidrohr merged 1 commit into
AliceO2Group:devfrom
f3sch:gpu/math

Conversation

@f3sch

@f3sch f3sch commented Oct 19, 2026

Copy link
Copy Markdown
Collaborator

…, host-device calls

Named double functions for GPUCommonMath::Sqrt,Sin,Cos,Tan,ASin,ACos,ATan,ATan2,Log,Copysign.
Clz64, Ctz64, Popcount64: 64-bit counterparts of Clz, Ctz and Popcount on the same builtins and CUDA/HIP intrinsics.
And AtomicLoad/Store.

@davidrohr davidrohr left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you change all the GPUd() to GPUhd(). GPUhd() means it is executed by the host code compiled with CUDA, so that should be only the code that drives the devices?
Does that code really need the GPUCommonMath functions? IMHO in that case one can use std:: directly.

Named double functions for GPUCommonMath::Sqrt,Sin,Cos,Tan,ASin,ACos,ATan,ATan2,Log,Copysign.

Clz64, Ctz64, Popcount64: 64-bit counterparts of Clz, Ctz and Popcount on
the same builtins and CUDA/HIP intrinsics. Named rather than uint64_t
overloads, which would change existing calls with 64-bit arguments and
make calls with int arguments ambiguous.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Felix Schlepper <felix.schlepper@cern.ch>
@f3sch

f3sch commented Oct 20, 2026

Copy link
Copy Markdown
Collaborator Author

Hi @davidrohr, you right of course. I had declared functors with GPUhd() in code linked to O2 using CAMath. My compilation then failed without declaring the functions also GPUhd(), so I had 'bug' in my code... sorry. I think I never understood the difference between GPUhd() and GPUd().

Also I had the question about the deterministic mode, currently it forces some computations to be made in double precision and then downcasts to float, but this trick does not work if the computation is supposed to be in double see for example GPUCommonMath::ASin(float...), i.e. how would GPUCommonMath::ASin(double...) look like for deterministic mode?

@davidrohr

Copy link
Copy Markdown
Collaborator

Hm, deterministic mode in double is a good question. IEEE double precision does not specify log, trigonimetric functions etc., i.e. they do not need to be 100% precise.
And different compilers / hardware vendors can use different taylor series to com0ute them, so results might vary...
I'll think about what we can do. Worst case one could implement everything ourselves as a power series... But I don't really like it. At the moment, the determijistic mode does not work in double...

@davidrohr
davidrohr merged commit 8f4271a into AliceO2Group:dev Oct 20, 2026
10 of 11 checks passed
@f3sch
f3sch deleted the gpu/math branch October 20, 2026 16:30
matthias-kleiner added a commit to matthias-kleiner/AliceO2 that referenced this pull request Oct 20, 2026
Follow-up to AliceO2Group#15986. TrackParametrization, TrackParametrizationWithError and
TrackUtils call the float-only gpu::CAMath functions (Sqrt, ASin, ATan2, ...),
so TrackParD / PropagatorD is effectively float. Compared with a std:: double
reference, propagateParamTo(x, b[3]) from x = 85 to 250 cm is off by up to
74 µm after 100 steps (pt 0.3 GeV, small transverse field), and
finite-difference derivatives through it are noisy. This affects the barrel
alignment (Detectors/Align) and the ITS3 alignment; no reconstruction workflow
uses the double types.

Call math_utils::detail::{sqrt, asin, ...}<value_t> instead, as Propagator.cxx
already does: for double these dispatch to the double functions, for float to
the same functions as before. Add GPUCommonMath::Expd and
math_utils::detail::exp for the remaining Exp calls.

Float results are bit-identical; TrackParD now agrees exactly with the double
reference.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
matthias-kleiner added a commit to matthias-kleiner/AliceO2 that referenced this pull request Oct 20, 2026
Follow-up to AliceO2Group#15986. TrackParametrization, TrackParametrizationWithError and
TrackUtils call the float-only gpu::CAMath functions (Sqrt, ASin, ATan2, ...),
so TrackParD / PropagatorD is effectively float. Compared with a std:: double
reference, propagateParamTo(x, b[3]) from x = 85 to 250 cm in 100 steps is off
by 0.4 to 74 µm, depending on pt and the field (toy fields with a transverse
component, no material), and finite-difference derivatives through it are
noisy. This affects the barrel alignment (Detectors/Align) and the ITS3
alignment; no reconstruction workflow uses the double types.

Call math_utils::detail::{sqrt, asin, ...}<value_t> instead, as Propagator.cxx
already does: for double these dispatch to the double functions, for float to
the same functions as before. Add GPUCommonMath::Expd and
math_utils::detail::exp for the remaining Exp calls.

Float results are bit-identical; TrackParD now agrees exactly with the double
reference.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
matthias-kleiner added a commit to matthias-kleiner/AliceO2 that referenced this pull request Oct 20, 2026
Follow-up to AliceO2Group#15986. TrackParametrization, TrackParametrizationWithError and
TrackUtils call the float-only gpu::CAMath functions (Sqrt, ASin, ATan2, ...),
so TrackParD / PropagatorD is effectively float. Compared with a std:: double
reference, propagateParamTo(x, b[3]) from x = 85 to 250 cm in 100 steps is off
by 0.4 to 74 µm, depending on pt and the field (toy fields with a transverse
component, no material), and finite-difference derivatives through it are
noisy. This affects the barrel alignment (Detectors/Align) and the ITS3
alignment; no reconstruction workflow uses the double types.

Call math_utils::detail::{sqrt, asin, ...}<value_t> instead, as Propagator.cxx
already does: for double these dispatch to the double functions, for float to
the same functions as before. Add GPUCommonMath::Expd and
math_utils::detail::exp for the remaining Exp calls. This restores the
math_utils::detail calls of cd9835a (switched back to CAMath in bf65d3c)
and extends them to TrackParametrizationWithError and TrackUtils.

Float results are bit-identical; TrackParD now agrees exactly with the double
reference.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
shahor02 pushed a commit that referenced this pull request Oct 21, 2026
Follow-up to #15986. TrackParametrization, TrackParametrizationWithError and
TrackUtils call the float-only gpu::CAMath functions (Sqrt, ASin, ATan2, ...),
so TrackParD / PropagatorD is effectively float. Compared with a std:: double
reference, propagateParamTo(x, b[3]) from x = 85 to 250 cm in 100 steps is off
by 0.4 to 74 µm, depending on pt and the field (toy fields with a transverse
component, no material), and finite-difference derivatives through it are
noisy. This affects the barrel alignment (Detectors/Align) and the ITS3
alignment; no reconstruction workflow uses the double types.

Call math_utils::detail::{sqrt, asin, ...}<value_t> instead, as Propagator.cxx
already does: for double these dispatch to the double functions, for float to
the same functions as before. Add GPUCommonMath::Expd and
math_utils::detail::exp for the remaining Exp calls. This restores the
math_utils::detail calls of cd9835a (switched back to CAMath in bf65d3c)
and extends them to TrackParametrizationWithError and TrackUtils.

Float results are bit-identical; TrackParD now agrees exactly with the double
reference.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants