-
Notifications
You must be signed in to change notification settings - Fork 809
[SYCL] Use raw pointers in enqueue flow #18306
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2380,8 +2380,7 @@ static ur_result_t SetKernelParamsAndLaunch( | |
| const QueueImplPtr &Queue, std::vector<ArgDesc> &Args, | ||
| const std::shared_ptr<device_image_impl> &DeviceImageImpl, | ||
| ur_kernel_handle_t Kernel, NDRDescT &NDRDesc, | ||
| std::vector<ur_event_handle_t> &RawEvents, | ||
| const detail::EventImplPtr &OutEventImpl, | ||
| std::vector<ur_event_handle_t> &RawEvents, detail::event_impl *OutEventImpl, | ||
| const KernelArgMask *EliminatedArgMask, | ||
| const std::function<void *(Requirement *Req)> &getMemAllocationFunc, | ||
| bool IsCooperative, bool KernelUsesClusterLaunch, | ||
|
|
@@ -2651,9 +2650,8 @@ ur_result_t enqueueImpCommandBufferKernel( | |
| void enqueueImpKernel( | ||
| const QueueImplPtr &Queue, NDRDescT &NDRDesc, std::vector<ArgDesc> &Args, | ||
| const std::shared_ptr<detail::kernel_bundle_impl> &KernelBundleImplPtr, | ||
| const std::shared_ptr<detail::kernel_impl> &MSyclKernel, | ||
| KernelNameStrRefT KernelName, std::vector<ur_event_handle_t> &RawEvents, | ||
| const detail::EventImplPtr &OutEventImpl, | ||
| const detail::kernel_impl *MSyclKernel, KernelNameStrRefT KernelName, | ||
| std::vector<ur_event_handle_t> &RawEvents, detail::event_impl *OutEventImpl, | ||
| const std::function<void *(Requirement *Req)> &getMemAllocationFunc, | ||
| ur_kernel_cache_config_t KernelCacheConfig, const bool KernelIsCooperative, | ||
| const bool KernelUsesClusterLaunch, const size_t WorkGroupMemorySize, | ||
|
|
@@ -2761,7 +2759,7 @@ ur_result_t enqueueReadWriteHostPipe(const QueueImplPtr &Queue, | |
| const std::string &PipeName, bool blocking, | ||
| void *ptr, size_t size, | ||
| std::vector<ur_event_handle_t> &RawEvents, | ||
| const detail::EventImplPtr &OutEventImpl, | ||
| detail::event_impl *OutEventImpl, | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I can somewhat believe that in-parameters don't change ownership model, but modifying out-parameter and saying "it's unchanged, trust me" sounds very suspicious. Can you explain more? Or maybe in other words, is that out-parameter even necessary?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If The same is true for the
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've updated PR description summarizing my understanding. Can you please check if that's correct and you agree with the change?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Looks good. Thank you!
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, sorry to be a pain, but mistakes can result in leaks/use-after-free and other flaky failures, so I want to be extra careful with this stuff. Once Sergey replies about |
||
| bool read) { | ||
| assert(Queue && | ||
| "ReadWrite host pipe submissions should have an associated queue"); | ||
|
|
@@ -3122,7 +3120,7 @@ ur_result_t ExecCGCommand::enqueueImpQueue() { | |
|
|
||
| ur_event_handle_t UREvent = nullptr; | ||
| ur_event_handle_t *Event = DiscardUrEvent ? nullptr : &UREvent; | ||
| detail::EventImplPtr EventImpl = DiscardUrEvent ? nullptr : MEvent; | ||
| detail::event_impl *EventImpl = DiscardUrEvent ? nullptr : MEvent.get(); | ||
|
|
||
| auto SetEventHandleOrDiscard = [&]() { | ||
| if (Event) | ||
|
|
@@ -3237,7 +3235,7 @@ ur_result_t ExecCGCommand::enqueueImpQueue() { | |
| (!SyclKernel || SyclKernel->hasSYCLMetadata()) && | ||
| ProgramManager::getInstance().kernelUsesAssert(KernelName); | ||
| if (KernelUsesAssert) { | ||
| EventImpl = MEvent; | ||
| EventImpl = MEvent.get(); | ||
| } | ||
| } | ||
|
|
||
|
|
@@ -3248,7 +3246,7 @@ ur_result_t ExecCGCommand::enqueueImpQueue() { | |
| assert(BinImage && "Failed to obtain a binary image."); | ||
| } | ||
| enqueueImpKernel(MQueue, NDRDesc, Args, ExecKernel->getKernelBundle(), | ||
| SyclKernel, KernelName, RawEvents, EventImpl, | ||
| SyclKernel.get(), KernelName, RawEvents, EventImpl, | ||
| getMemAllocationFunc, ExecKernel->MKernelCacheConfig, | ||
| ExecKernel->MKernelIsCooperative, | ||
| ExecKernel->MKernelUsesClusterLaunch, | ||
|
|
@@ -3645,7 +3643,7 @@ ur_result_t ExecCGCommand::enqueueImpQueue() { | |
| bool read = ExecReadWriteHostPipe->isReadHostPipe(); | ||
|
|
||
| if (!EventImpl) { | ||
| EventImpl = MEvent; | ||
| EventImpl = MEvent.get(); | ||
| } | ||
| return enqueueReadWriteHostPipe(MQueue, pipeName, blocking, hostPtr, | ||
| typeSize, RawEvents, EventImpl, read); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what's our approach for
const, we probably didn't care before because shared pointers could always give us non-const ptr even if they themselves were const.@sergey-semenov , any preferences? I think the pointer we get below is non-const, so we can avoid this bit by simply changing the signature to accept non-const.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My preference is that if the object itself is not modified, then a
constpointer should be used and usemutable std::mutexsince it might be required for read-only concurrent access synchronization.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My issue is that we (most likely) don't do that consistently. I'd rather have "wrong" behavior everywhere than the "right" one somewhere only. But this isn't big deal for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's probably true in some (most?) places. I don't have a strong opinion on this, but without knowing exactly how widespread the problem is, I'd rather not contribute to it and start fixing the pieces that we hit, so I'm leaning to sticking with
mutablehere.