-
Notifications
You must be signed in to change notification settings - Fork 793
[SYCL] Build proper barrier deps if host task is involved in pipeline #13094
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
Conversation
This reverts commit 2f56926.
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
…iEvent Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
to do:
|
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
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.
LGTM overall, just some minor comments.
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
Signed-off-by: Tikhomirova, Kseniya <[email protected]>
// Helps to manage host tasks presence in scenario with barrier usage. | ||
// Approach that tracks almost all tasks to provide barrier sync for both pi | ||
// tasks and host tasks is applicable for out of order queues only. No-op | ||
// for in order ones. | ||
void tryToResetEnqueuedBarrierDep(const EventImplPtr &EnqueuedBarrierEvent); |
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.
This seems to be a dead code.
|
||
// Called on host task completion that could block some kernels from enqueue. | ||
// Approach that tracks almost all tasks to provide barrier sync for both pi | ||
// tasks and host tasks is applicable for out of order queues only. Not neede |
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.
neede -> needed
// Called on host task completion that could block some kernels from enqueue. | ||
// Approach that tracks almost all tasks to provide barrier sync for both pi | ||
// tasks and host tasks is applicable for out of order queues only. Not neede | ||
// for in order ones. |
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.
Considering that the backend is not aware of host tasks, how in-order property is provided for host tasks?
sycl::event HTEvent = AddTask(TestCGType::HOST_TASK); | ||
EventImplPtr HostTaskEventImpl = sycl::detail::getSyclObjImpl(HTEvent); | ||
auto HostTaskWaitList = HostTaskEventImpl->getWaitList(); | ||
ASSERT_EQ(HostTaskWaitList.size(), 0u); |
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.
Shouldn't host task to wait for barrier to complete?
sycl::event KernelEvent = AddTask(TestCGType::KERNEL_TASK); | ||
EventImplPtr KernelEventImpl = sycl::detail::getSyclObjImpl(KernelEvent); | ||
auto KernelWaitList = KernelEventImpl->getWaitList(); | ||
ASSERT_EQ(KernelWaitList.size(), 0u); |
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.
Do I understand correctly that the barrier semantics is guaranteed by the backend for the kernel task, so there is not dependency on barrier?
I suggest adding in-order queue test case with code comments describing code logic.
sycl::event HTEvent = AddTask(TestCGType::HOST_TASK); | ||
EventImplPtr HostTaskEventImpl = sycl::detail::getSyclObjImpl(HTEvent); | ||
auto HostTaskWaitList = HostTaskEventImpl->getWaitList(); | ||
ASSERT_EQ(HostTaskWaitList.size(), 0u); |
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 would expect to see a dependency on barrier event here (similar to BarrierHandlingWithHostTask
test case).
EXPECT_CALL(MockCGH, depends_on(An<const sycl::detail::EventImplPtr &>())) | ||
.Times(1); | ||
Queue->finalizeHandler<LimitedHandlerSimulation>( | ||
MockCGH, detail::CG::CGTYPE::CodeplayHostTask, Event); |
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.
Do we test scenarios with multiple in-order queues, where host task enqueued in one queue and event was passed as an argument to a barrier in another queue?
No description provided.