[SYCL][UR][L0 v2] Fix urMemBufferCreateWithNativeHandle #17698
Merged
Conversation
This file contains hidden or 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
The implementation incorrectly assumed that hDevice is always set for memory type other than host which resulted in nullptr dereference in ur_discrete_buffer_handle_t ctor. The assumption is not true for shared allocations. Implement a separate handle type to handle shared allocations: the implementation will just use the allocation directly.
pbalcer
approved these changes
Mar 28, 2025
unified-runtime/test/adapters/level_zero/urMemBufferCreateWithNativeHandleShared.cpp
Show resolved
Hide resolved
Contributor
Author
|
@intel/llvm-gatekeepers this is ready to be merged |
Contributor
|
@igchor @npmiller @pbalcer I don't think it was this PR but any ideas what could cause this postcommit windows build fail? https://github.com/intel/llvm/actions/runs/14175023208/job/39707709728 |
Contributor
Author
|
@sarnex hm, this looks like a problem with UMF, but the UMF version was bumped a while ago, and there were no failures on merge. @lukaszstolarczuk @PatKamin have you seen this error before? |
Contributor
Author
|
@sarnex looking at the logs, I also see some failures during level-zero compilation. Also, there are some CMake warning that weren't present before: Perhaps there was some infrastructure update that caused this? |
Contributor
|
@igchor Can you send me a log from where it passed? |
Contributor
Author
|
@sarnex I was looking at this job, just after UMF bump merge: https://github.com/intel/llvm/actions/runs/13990348416/job/39172707168 |
Contributor
|
So I installed CUDA/HIP/OCL CPU on this runner but I can't imagine that's related and the logs don't seem to suggest so, I see so maybe the git repo cache is corrupted, let me try deleting it |
Contributor
Author
|
@sarnex Actually, this seems to be the last passing job: https://github.com/intel/llvm/actions/runs/14162041878/job/39668990919 |
Contributor
|
that one ran on a runner that i didn't touch, so maybe it is just this runner, let me try some stuff |
Contributor
|
ok i see the bad case is using upstream cmake and the good is using cmake from msvc, let me try removing the upstream one |
Contributor
|
ok looks like the problem was a perl version bump i did on the runner, weird. anyway seems fixed now and not related to any actual code, sorry for the trouble |
KornevNikita
pushed a commit
that referenced
this pull request
May 27, 2025
The implementation incorrectly assumed that hDevice is always set for memory type other than host which resulted in nullptr dereference in ur_discrete_buffer_handle_t ctor. The assumption is not true for shared allocations. Implement a separate handle type to handle shared allocations: the implementation will just use the allocation directly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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 implementation incorrectly assumed that hDevice is always set for memory type other than host which resulted in nullptr dereference in ur_discrete_buffer_handle_t ctor.
The assumption is not true for shared allocations.
Implement a separate handle type to handle shared allocations: the implementation will just use the allocation directly.