[CUDA] Add support for multiple active mappings #1220
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #1220 +/- ##
==========================================
- Coverage 15.46% 15.46% -0.01%
==========================================
Files 238 238
Lines 33883 33883
Branches 3747 3747
==========================================
- Hits 5240 5239 -1
Misses 28593 28593
- Partials 50 51 +1 ☔ View full report in Codecov by Sentry. |
jchlanda
approved these changes
Jan 4, 2024
|
@oneapi-src/unified-runtime-maintain would be great if someone could review these changes |
aarongreig
approved these changes
Jan 23, 2024
kbenzie
added
conformance
kbenzie
force-pushed
the
fabio/cuda_multimap
branch
from
43325e6 to
834e643
Compare
kbenzie
added a commit
to kbenzie/unified-runtime
that referenced
this pull request
Apr 11, 2024
Issue was introduced in oneapi-src#1220 where a new allocation is created in a `std::unique_ptr` to enable buffer mapping. The `.get()` member function is called before the `std::unique_ptr` is passed into the `BufferMem` constructor. However, move semantics were not being explicitly followed. The `BufferMem` constructor was taking the `std::unique_ptr` by l-value refernece, then calling `std::move()` on it. This triggered a wrapper-escape, use-after-free defect in Coverity. This fix is to explicitly `std::move()` the `std::unique_ptr` into the `BufferMem` constructor, and also update the `BufferMem` constructor to take an r-value reference instead of an l-value reference.
frasercrmck
added a commit
to frasercrmck/unified-runtime
that referenced
this pull request
May 22, 2024
This patch adds support for mapping the same buffer multiple times with urEnqueueMemBufferMap. This is mostly a straight port of oneapi-src#1220.
frasercrmck
added a commit
to frasercrmck/unified-runtime
that referenced
this pull request
May 22, 2024
This patch adds support for mapping the same buffer multiple times with urEnqueueMemBufferMap. This is mostly a straight port of oneapi-src#1220. It brings the HIP adapter's functionality in line with that of the CUDA adapter.
frasercrmck
added a commit
to frasercrmck/unified-runtime
that referenced
this pull request
May 22, 2024
This patch adds support for mapping the same buffer multiple times with urEnqueueMemBufferMap. This is mostly a straight port of oneapi-src#1220. It brings the HIP adapter's functionality in line with that of the CUDA adapter.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The CUDA adapter currently does not support multiple active mappings on the same buffer when using urEnqueueMemBufferMap. This change aims to add support for that feature.
However, the unsupported scenario of overlapping maps that were both created with the
UR_MAP_FLAG_WRITEis not currently being checked. That's better done using validation layers for which I have created an issue: #1221intel/llvm: intel/llvm#12285