-
Notifications
You must be signed in to change notification settings - Fork 769
[SYCL] Implementation of discard_events #5026
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
[SYCL] Implementation of discard_events #5026
Conversation
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
/summary:run |
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
/summary:run |
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
/summary:run |
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.
The tests need to be added (both in sycl/test and intel/llvm-test-suite) for the new functionality.
sycl/source/detail/event_impl.cpp
Outdated
@@ -303,6 +312,9 @@ template <> cl_uint event_impl::get_info<info::event::reference_count>() const { | |||
template <> | |||
info::event_command_status | |||
event_impl::get_info<info::event::command_execution_status>() const { | |||
if (MState == HES_Invalid) |
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.
Maybe it's better to say discarded
rather than invalid
? Invalid sounds like something wrong with the implementation.
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.
Ok, I will change HES_Invalid
to HES_Discarded
sycl/source/detail/queue_impl.hpp
Outdated
// The presence of support for DiscardEvents from the queue | ||
const bool MHasDiscardEventsSupport; |
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.
Could you please clarify what this support means?
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.
MHasDiscardEventsSupport
serves to answer the question: can we discard the low-level event using this queue? The variable answers this question in terms of queue support, because the final decision about discarding is decided before the operation itself, since it is necessary to check whether this operation uses accessors, and also in the case of a kernel, it is necessary to check the use of assert() statement.
For example, you can create a queue with discard_events
property, but without in_order
property then the queue doesn't support discarding.
Another example, you can create a queue with discard_events
and in_order
properties, but run it on level_zero backend(which doesn't support discarding events yet) then the queue doesn't support discarding.
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.
Ok, so this flags says if we can discard events based on a queue "setup" which will be common for all kernels submitted to the queue. And as you said this is a must condition for discarding, but even if it's true, in some cases, we won't be able to discard events.
It would be nice if this information is added as a comment.
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.
Ok, done.
sycl/include/CL/sycl/handler.hpp
Outdated
if (info::event_command_status::ext_oneapi_unknown == | ||
Event.get_info<info::event::command_execution_status>()) { |
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 looks very expensive. Since what we really would like to know here is whether the event is discarded, can we just check this field?
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 code covers the case "when invalid event is passed into handler API" described in https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/DiscardQueueEvents/SYCL_EXT_ONEAPI_DISCARD_QUEUE_EVENTS.asciidoc
Here we just want to check if the MState
field of event_impl
has HES_Invalid
value or not.
I think it is possible if we move the definition of the depends_on()
method to the handler.cpp
and check the field by the new public method of event_impl
(it needs to be added). I will try that, thanks!
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
…discarded" event Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
sycl/source/detail/event_impl.cpp
Outdated
if (MState == HES_Discarded) | ||
throw sycl::exception( | ||
make_error_code(errc::invalid), | ||
"waitInternal method cannot be used for an discarded 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.
"waitInternal method cannot be used for an discarded event."); | |
"waitInternal method cannot be used for a discarded 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.
Done, thanks!
ext_oneapi_unknown = | ||
submitted + running + complete + | ||
1 // TODO: a more elegant way to ensure that the unique value is here |
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.
ext_oneapi_unknown = | |
submitted + running + complete + | |
1 // TODO: a more elegant way to ensure that the unique value is here | |
ext_oneapi_unknown = 1000; |
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.
It would leave enough space for 1:1 mapping if BE supports more statuses.
Maybe @gmlueck have an opinion as well.
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.
You are worried that the value of ext_oneapi_unknown
might collide with some future OpenCL extension that adds a new "command execution status" value? It's hard to predict what new values might be added in the future. However, since all values are positive now, it's probably safe to use a negative value. Therefore, you could use -1
. If we add other ext_oneapi
values in the future, they could be -2
, etc.
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.
Ok, I changed it to -1
, thanks for the suggestion!
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
Signed-off-by: Alexander Flegontov <alexander.flegontov@intel.com>
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, but it would be nice if @vladimirlaz or @sergey-semenov take a look as well.
* upstream/sycl: (5961 commits) [SYCL] Implement discard_events extension (intel#5026) [SYCL][NFC] Fix unused parameter warning in piQueueFlush (intel#5139) [SYCL][XPTI] Fix static analysis tool warnings (intel#5040) [CI] Switch post-commit jobs to self-hosted runners (intel#5147) [SYCL] Fix support for classes implicitly converted from items in parallel_for (intel#5118) [SYCL][HIP] Fix platform query in USM alloc info (intel#5140) [Docker] Add workarounds for two SYCL issues (intel#5143) [CI] Install cm-compiler in drivers image (intel#5128) [ESIMD] Add support for an arbitrary number of elements to simd::copy_from/to (intel#5135) [SYCL] Add number HW threads per EU query (intel#4901) [CI] Refactor workflow files (intel#5134) [CI] Enable HIP and CUDA plugins in GitHub Actions builds (intel#5087) [SYCL] Implement queue flushing (intel#5052) Disable issue labeler in LLVM forks Modify translation for disable_loop_pipelining metadata Add SPIR-V friendly translation for OpLoad and OpStore Fix return type postfix for SPIR-V Friendly IR Restrict special handling of sampler OpVariable only to UniformConstant Add lowering for llvm.bswap intrinsic Fix translation of OpVariable with OpSamplerType ...
Review documentation in #4922