[cudax->libcu++] Move buffer type from cudax to libcu++ - #6627
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| @@ -119,15 +119,6 @@ foreach (cudax_target IN LISTS cudax_TARGETS) | |||
|
|
|||
| cudax_add_catch2_test(test_target containers ${cudax_target} | |||
| containers/uninitialized_buffer.cu | |||
There was a problem hiding this comment.
arent we moving uninitialized_buffer too
There was a problem hiding this comment.
We don't really use it anywhere, I think it can stay experimental until we have a usage for it
There was a problem hiding this comment.
What's the new replacement for thrust::device_vector<T>(n, thrust::no_init), which is used everywhere in benchmarks and tests?
There was a problem hiding this comment.
cuda::make_buffer<T>(stream, cuda::device_default_memory_pool(cuda::devices[i]), n, cuda::no_init). We might consider a version of it in the future that does not take a stream
There was a problem hiding this comment.
I think it would look much better if we could just do:
cuda::make_buffer<T>(stream, cuda::devices[i], n, cuda::no_init);We could add a constructor from cuda::memory_location which would mean the default memory pool
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
pre-commit.ci autofix |
|
pre-commit.ci autofix |
|
/ok to test c804cfe |
@davebayer, there was an error processing your request: See the following link for more information: https://docs.gha-runners.nvidia.com/cpr/e/2/ |
|
/ok to test a804cfe |
🥳 CI Workflow Results🟩 Finished in 9h 38m: Pass: 100%/122 | Total: 1d 21h | Max: 3h 01m | Hits: 99%/215255See results here. |
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin branch/3.2.x
git worktree add -d .worktree/backport-6627-to-branch/3.2.x origin/branch/3.2.x
cd .worktree/backport-6627-to-branch/3.2.x
git switch --create backport-6627-to-branch/3.2.x
git cherry-pick -x 5dd8bdb567b92ddec5f81cf7f49a61d31dea41e7 |
* Move buffer type from cudax to libcu++ * Fix cudax compilation * Fix merge and review feedback * Waive buffer prologue include checks * Use unwrapped_begin in get_unsynchronized * ifdef problematic cases for now * Apply suggestion from @davebayer * [pre-commit.ci] auto code formatting * Apply suggestion from @davebayer --------- Co-authored-by: David Bayer <48736217+davebayer@users.noreply.github.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Move buffer type from cudax to libcu++ * Fix cudax compilation * Fix merge and review feedback * Waive buffer prologue include checks * Use unwrapped_begin in get_unsynchronized * ifdef problematic cases for now * Apply suggestion from @davebayer * [pre-commit.ci] auto code formatting * Apply suggestion from @davebayer --------- Co-authored-by: David Bayer <48736217+davebayer@users.noreply.github.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
| // Temporary workaround to not trigger issues in CUB headers missing prologue | ||
| #define _CCCL_WAIVE_PROLOGUE_INCLUDE_CHECK |
There was a problem hiding this comment.
What was the problem? I don't like that we are disabling this
There was a problem hiding this comment.
CUB didn't properly include prologue headers and I didn't want to try to fix that as part of this PR
There was a problem hiding this comment.
I understand but then there are these workarounds coming out of nowhere. I think it would be better to fix this problem in another PR before merging this one.
It seems that we will include more cub headers, so we need a systematic solution.
There was a problem hiding this comment.
I still think it would be nice to have an opt-out like that available for similar future cases, especially since the prologue thing is not essential, but I don't mind removing it
There was a problem hiding this comment.
No, it is absolutely essential. All code in libcu++ should be guarded by the prologue/epilogue include. We do many important stuff there to prevent other macros breaking our code
There was a problem hiding this comment.
But now we also include CUB in libcu++ and CUB doesn't use it, so I would be cautious to call it essential
There was a problem hiding this comment.
And not only that, we suppress compiler warnings and other stuff. That's why the checks for the prologue/epilogue wrapping are so strict (and annoying)
There was a problem hiding this comment.
CUB doesn't do many of the things we do in libcu++, but that doesn't mean we should relax requirements on what we do in libcu++
There was a problem hiding this comment.
I am with Dave here, this is potentially breaking libcu++ which we must not do
* Move buffer type from cudax to libcu++ * Fix cudax compilation * Fix merge and review feedback * Waive buffer prologue include checks * Use unwrapped_begin in get_unsynchronized * ifdef problematic cases for now * Apply suggestion from @davebayer * [pre-commit.ci] auto code formatting * Apply suggestion from @davebayer --------- Co-authored-by: David Bayer <48736217+davebayer@users.noreply.github.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Move buffer type from cudax to libcu++ * Fix cudax compilation * Fix merge and review feedback * Waive buffer prologue include checks * Use unwrapped_begin in get_unsynchronized * ifdef problematic cases for now * Apply suggestion from @davebayer * [pre-commit.ci] auto code formatting * Apply suggestion from @davebayer --------- Co-authored-by: David Bayer <48736217+davebayer@users.noreply.github.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
PR moving last bits of the buffer type and de-duplicating the
__memory_accessibilityenum