Add syncthreads to scans prevent overwriting shared memory of previous chunk #97
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.
Description
This PR fixes an issue that we had for a long time. Programs with scans would sometimes give incorrect values. As I found out, this is caused by missing synchronization in thread groups in the scan kernels.
Motivation and context
A thread group in a scan kernel may handle multiple chunks of the input.
A __syncthreads was missing between the end of one chunk and the start of the next, which caused that
shared memory could be overwritten in in the next iteration, before all threads are finished reading data from the previous iteration.
scanBlockShfl does perform synchronisation between its writes and reads, but there was no synchronisation between the reads of some iteration of the outer loop, and the writes in the next iteration.
How has this been tested?
Our quickhull implementation now works correctly on the GPU, whereas it previously would produce garbage values or crash (as it continues to compute with those garbage values). This was tested on an A100 and 4090.
Types of changes
Checklist: