[SYCL] Native event for default-ctored sycl::event has to be in COMPLETE state #7148
Conversation
…ETE state Per SYCL 2020 for event(): > Constructs an event that is immediately ready. The event has no > dependencies and no associated commands. Waiting on this event will > return immediately and querying its status will return > info::event_command_status::complete. piEventCreate on the other hand creates an event that isn't completed. As such an extra call to piEventSetStatus is needed making that API not-deprecated. There is a more general problem that isn't addressed here: auto e = q.submit(... h.host_task(...) ..) This event would be a host one and we assert that no get_native could be called on it (see existing sycl::detail::getImplBackend). If we will ever want to support such scenario we'd need to implement some tracking of host/backed events in the SYCL RT and keep updating the latter whenever the host one changes the state.
sycl/source/detail/event_impl.cpp
Outdated
| assert(!isDiscarded() && "Can't ask getNative of a discarded event!"); | ||
| // Wouldn't be true if MHostEvent could be true. | ||
| assert(MState == HES_Complete && "Expected to have a completed event!"); | ||
| Plugin.call<PiApiKind::piEventSetStatus>(MEvent, PI_EVENT_COMPLETE); |
There was a problem hiding this comment.
Can we instead change the "piEventCreate" to create a completed event?
BTW, in what circumstances is it called? How is such event used afterwards?
There was a problem hiding this comment.
BTW, in what circumstances is it called? How is such event used afterwards?
Not sure, I've only got a reduced example from the customer. I'd expect (without any grounds for those expectations) something like this is possible
auto event = [&]() {
if (needs_some_preprocessing) {
return q.submit();
} else {
return event();
}
} ();
q.parallel_for<MAIN>(..., event);
Can we instead change the "piEventCreate" to create a completed event?
From what I see in the codebase currently, that's possible although I don't see any substantial benefits.
There was a problem hiding this comment.
I mean why do we even need to create a native event (call to piEventCreate) when we need to create a completed event, for which I assume there is no SYCL API to reset such event? We'd just mark the SYCL event as completed without going to native plugins.
Can we instead change the "piEventCreate" to create a completed event?
From what I see in the codebase currently, that's possible although I don't see any substantial benefits.
To continue deprecating and removing the piEventSetStatus
There was a problem hiding this comment.
I mean why do we even need to create a native event (call to piEventCreate) when we need to create a completed event, for which I assume there is no SYCL API to reset such event? We'd just mark the SYCL event as completed without going to native plugins.
Because SYCL spec says that such event
is constructed as though it was created from a default-constructed queue. Therefore, its backend is the same as the backend from the default device.
which means it is subject to interop API and its state can be modified using native backend APIs (which seems to be what the customer is doing).
There was a problem hiding this comment.
OK, makes sense. So what about changing piEventCreate instead?
There was a problem hiding this comment.
So what about changing piEventCreate instead?
I'm already working on that.
| (void)ExecutionStatus; | ||
| die("piEventSetStatus: deprecated, to be removed"); | ||
| if (ExecutionStatus == PI_EVENT_COMPLETE) | ||
| zeEventHostSignal(Event->ZeEvent); |
There was a problem hiding this comment.
This has to properly process error codes.
|
@intel/llvm-reviewers-runtime , 2nd iteration of the PR evolved into plugin-side fix. Can I get an approval/merge? |
|
@intel/llvm-gatekeepers , PR is ready. |
…ETE state (intel#7148) Per SYCL 2020 for event(): > Constructs an event that is immediately ready. The event has no > dependencies and no associated commands. Waiting on this event will > return immediately and querying its status will return > info::event_command_status::complete. Modify piEventCreate to create an event in such a state. There is a more general problem that isn't addressed here: auto e = q.submit(... h.host_task(...) ..) This event would be a host one and we assert that no get_native could be called on it (see existing sycl::detail::getImplBackend). If we will ever want to support such scenario we'd need to implement some tracking of host/backed events in the SYCL RT and keep updating the latter whenever the host one changes the state. Alternatively, SYCL spec could be updated to prohibit such scenario or specify that such event has no native counterpart.
Per SYCL 2020 for event():
Modify piEventCreate to create an event in such a state.
There is a more general problem that isn't addressed here:
auto e = q.submit(... h.host_task(...) ..)
This event would be a host one and we assert that no get_native could be called on it (see existing sycl::detail::getImplBackend). If we will ever want to support such scenario we'd need to implement some tracking of host/backed events in the SYCL RT and keep updating the latter whenever the host one changes the state.
Alternatively, SYCL spec could be updated to prohibit such scenario or specify that such event has no native counterpart.