Skip to content
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] Implement queue::ext_oneapi_empty() API to get queue status #7583

Merged
merged 24 commits into from
Dec 5, 2022

Conversation

againull
Copy link
Contributor

@againull againull commented Nov 29, 2022

@againull againull requested review from a team as code owners November 29, 2022 23:09
@smaslov-intel
Copy link
Contributor

where is this extension documented?

@againull
Copy link
Contributor Author

againull commented Nov 30, 2022

where is this extension documented?

Extension is documented here:
https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/proposed/sycl_ext_oneapi_queue_status_query.asciidoc

As we discussed with @gmlueck, we definitely need ext_oneapi_empy. ext_oneapi_size/ext_oneapi_get_wait_list necessity is going to be discussed and most likely will be dropped. That's why this PR is implementin ext_oneapi_empty only.

sycl/plugins/cuda/pi_cuda.cpp Outdated Show resolved Hide resolved
sycl/plugins/level_zero/pi_level_zero.cpp Outdated Show resolved Hide resolved
sycl/include/sycl/detail/pi.h Outdated Show resolved Hide resolved
* Catch exception in the cuda plugin
* Use hasOpenCommandList in the L0 plugin
* Rename PI_QUEUE_INFO_STATUS -> PI_EXT_ONEAPI_QUEUE_INFO_STATUS
and update int value
Immediate command lists are not associated with any L0 command queue.
So we need to check status of the events on eacn immediate command
lists to get the status of the queue.
@againull
Copy link
Contributor Author

againull commented Dec 1, 2022

I guess l will need to mention this limitation in the extension documentation, correct?

Yes, we usually do this by adding a NOTE callout in the "Status" section. Something like:

This extension is currently support fully by DPC++ in both the Level Zero and CUDA backends, but there are limitations when running on the OpenCL backend. Attempting to call queue::empty() for the OpenCL backend will trigger an assertion unless the queue has the in_order property.

What is the current behavior if the application attempts to call this AP on OpenCL? Does it raise an assertion failure? I'm not sure what we normally do for unsupported features.

Exception will be thrown if somebody attempts to call this API on OpenCL.

* Rename PI_EXT_ONEAPI_QUEUE_INFO_STATUS->PI_EXT_ONEAPI_QUEUE_INFO_EMPTY
* Document return type in pi.h
* Define feature macro
smaslov-intel
smaslov-intel previously approved these changes Dec 2, 2022
@smaslov-intel smaslov-intel dismissed their stale review December 2, 2022 00:25

one more thing

@@ -58,6 +58,8 @@
// piDeviceGetInfo.
// 11.17 Added new PI_EXT_ONEAPI_QUEUE_PRIORITY_LOW and
// PI_EXT_ONEAPI_QUEUE_PRIORITY_HIGH queue properties.
// 11.18 Add new parameter name PI_EXT_ONEAPI_QUEUE_INFO_EMPTY to
// _pi_queue_info.

#define _PI_H_VERSION_MAJOR 11
#define _PI_H_VERSION_MINOR 16
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please update the version

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, thanks, fixed.

@@ -499,6 +499,30 @@ struct _pi_queue {
return is_last_command && !has_been_synchronized(stream_token);
}

template <typename T> bool all_of(T &&f) {
{
std::lock_guard<std::mutex> compute_guard(compute_stream_mutex_);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
std::lock_guard<std::mutex> compute_guard(compute_stream_mutex_);
std::lock_guard compute_guard(compute_stream_mutex_);

}
}
{
std::lock_guard<std::mutex> transfer_guard(transfer_stream_mutex_);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
std::lock_guard<std::mutex> transfer_guard(transfer_stream_mutex_);
std::lock_guard transfer_guard(transfer_stream_mutex_);

unsigned int end =
std::min(static_cast<unsigned int>(compute_streams_.size()),
num_compute_streams_);
for (unsigned int i = 0; i < end; i++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be an algorithm.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for suggestions, fixed.

num_transfer_streams_);
for (unsigned int i = 0; i < end; i++) {
if (!f(transfer_streams_[i]))
return false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This déjà vu suggests more abstraction.

if (!f(transfer_streams_[i]))
return false;
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We really need some heavy refactoring across the various back-ends some day... :-(

@againull againull requested a review from keryell December 2, 2022 15:48
@gmlueck
Copy link
Contributor

gmlueck commented Dec 2, 2022

If my PR #7612 is merged before yours, then you should also move the extension document from "proposed" to "supported" as described in the extension process README. Be sure to change the "Status" section of the spec as indicated.

Note that #7612 was merged. Please merge the main thread into this PR, and then move / update the spec.

@againull againull requested a review from a team as a code owner December 2, 2022 17:40
Copy link
Contributor

@gmlueck gmlueck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes to extension spec LGTM.

@againull
Copy link
Contributor Author

againull commented Dec 2, 2022

@romanovvlad Friendly ping

Copy link
Contributor

@keryell keryell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

// If we have in-order queue where events are not discarded then just check
// the status of the last event.
if (isInOrder() && !MDiscardEvents) {
std::lock_guard<std::mutex> Lock(MLastEventMtx);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use C++17 CTAD everywhere. There are still a lot in the new code.

@againull
Copy link
Contributor Author

againull commented Dec 5, 2022

Reported unrelated HIP backend failures here: #7634

@againull againull merged commit c493295 into intel:sycl Dec 5, 2022
@againull againull deleted the ext_oneapi_empty branch December 13, 2022 20:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants