Repository navigation
Commit e4270ed
GPU: wait for the O2 track count before sorting the O2 output tracks
With GPUCA_SPECIALIZE_THRUST_SORTS (CUDA and HIP), the host-side launch
of GPUTPCGMO2Output::sort takes the number of elements from the host
copy of the merger's memory, processors()->tpcMerger.NOutputTracksTPCO2().
That count is computed by GPUTPCGMO2Output::prepare on the device, and
TransferMemoryResourceLinkToHost brings it to the host asynchronously,
on the same stream, right before the sort is launched. The event of the
transfer was only waited for after the sort, so the sort very likely
got the value from before prepare ran: 0, since RunTPCTrackingMerger
clears the merger's memory on the host at its start, and the transfer
is queued behind prepare. Then the O2 output tracks keep the order in
which prepare wrote them. This goes back to b0155c2, which moved
the wait after the sort. With debugLevel >= 1 or serializeGPU the
transfer is synchronous, which would hide it.
The other sorts that read host counts, SortTracks and SortTracksQPt,
wait for their transfer with CondWaitEvent first; do the same here, by
waiting before the sort. The wait was already needed before the
allocation of the O2 output that follows, so it costs no extra
synchronisation.
Found by reading the code, while porting these sorts to the Metal
backend, which reads the count after draining the stream. Not tested on
CUDA or HIP, there is no NVIDIA or AMD GPU here; the CPU build compiles.
To check on a GPU: with debugLevel 0, outputTracksTPCO2 should come out
ordered by the sort's comparator with this change, and not without it.1 parent 92368c4 commit e4270ed
1 file changed
Lines changed: 1 addition & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
305 | 305 | | |
306 | 306 | | |
307 | 307 | | |
| 308 | + | |
308 | 309 | | |
309 | 310 | | |
310 | | - | |
311 | 311 | | |
312 | 312 | | |
313 | 313 | | |
| |||
0 commit comments