Skip to content

DistributedClosestPoint GPU-related optimizations - #1974

Open
publixsubfan wants to merge 12 commits into
developfrom
feature/yang39/dcp-gpu-opt
Open

DistributedClosestPoint GPU-related optimizations#1974
publixsubfan wants to merge 12 commits into
developfrom
feature/yang39/dcp-gpu-opt

Conversation

@publixsubfan

@publixsubfan publixsubfan commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Summary

This is a grab-bag of various optimizations to improve DistributedClosestPoint query performance:

  • DistributedClosestPoint: sort query points by Morton order to reduce divergence
  • BVH:
    • Add a BVH2Node struct for representing internal nodes. Since HIP architectures appear to do temporal coalescing, this may be more efficient than having separate arrays for the bounding boxes and child node indices by reducing the number of memory waits (s_waitcnt vmcnt(*))
    • Adds a new method to the BVH traverser interface traverseTreeShared() which uses GPU shared memory to cache the most-recently used entries in the BVH stack
  • Primal: use fmax/fmin for clamp operation inside squared_distance(Point, BoundingBox)
    This seems to improve GPU codegen compared to the generic axom::utilities::clampVal() function.

Performance results

I rebased this branch onto Kenny's branch in #1952, and ran a test with the following setup:

  • One node of rzadams, CPX mode, 24 ranks
  • Object mesh: 24 domains, 24M points total (1M points per rank)
  • Query mesh: 24 domains, 48M cells total (2M cells per rank)
  query runtime
Pre-optimizations 23.200s
Morton sort query points 17.798s
BVH optimizations 17.234s

HIP architectures appear to do temporal coalescing; that is, memory
accesses for array-of-struct types that would be individually strided
can be coalesced so long as the loads are all issued before the next
wait ("s_waitcnt vmcnt(*)"). In some cases, that makes loading the whole
struct faster than through a struct-of-arrays layout.

We should revisit this when we get a chance on Nvidia platforms.
Use fmin/fmax to perform clamping operation. This avoids extra
instructions that are generated to perform a generic ternary-based clamp
operation.
@publixsubfan publixsubfan added Quest Issues related to Axom's 'quest' component Primal Issues related to Axom's 'primal component Spin Issues related to Axom's 'spin' component GPU Issues related to GPU development labels Sep 1, 2026
@Arlie-Capps

Copy link
Copy Markdown
Contributor

@publixsubfan , the first line of your performance table is labeled "Clean." Does this mean "before optimizations?"

@publixsubfan

Copy link
Copy Markdown
Contributor Author

@publixsubfan , the first line of your performance table is labeled "Clean." Does this mean "before optimizations?"

@Arlie-Capps, yes -- I think that would be a better wording.

@rhornung67

Copy link
Copy Markdown
Member

@publixsubfan does this PR address any of the memory issues (i.e., "leaked" memory) observed by user applications?

@publixsubfan

Copy link
Copy Markdown
Contributor Author

Unfortunately no, this PR won't improve that situation. There's some other potential optimizations I'm looking at that may help with the memory usage.

@rhornung67

Copy link
Copy Markdown
Member

Unfortunately no, this PR won't improve that situation. There's some other potential optimizations I'm looking at that may help with the memory usage.

Thanks. Just checking.

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

Labels

GPU Issues related to GPU development Primal Issues related to Axom's 'primal component Quest Issues related to Axom's 'quest' component Spin Issues related to Axom's 'spin' component

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants