Skip to content

[SYCL] Exit early while trying to enqueue blocked tasks #2347

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

Merged

Conversation

DenisBakhvalov
Copy link
Contributor

No description provided.

@DenisBakhvalov DenisBakhvalov requested a review from a team as a code owner August 20, 2020 01:02
Copy link
Contributor

@romanovvlad romanovvlad left a comment

Choose a reason for hiding this comment

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

LGTM

@DenisBakhvalov
Copy link
Contributor Author

I need to fix the test failures revealed in the CI.

@DenisBakhvalov DenisBakhvalov force-pushed the private/dbakhval/enqueue-blocked-tasks branch from 32c51b7 to 10963c4 Compare September 2, 2020 00:27
@DenisBakhvalov
Copy link
Contributor Author

I fixed CI failures. See 2ec35d1.

Copy link
Contributor

@s-kanaev s-kanaev left a comment

Choose a reason for hiding this comment

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

The changes look good. Only a single comment and a question.

Comment on lines +74 to +80
// We have such a graph:
//
// A
// / | \
// B C D
//
// If C is blocked, we should not try to enqueue D.
Copy link
Contributor

Choose a reason for hiding this comment

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

Do I understand it correctly that A depends on B, C and D? Why can't we enqueue D then?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We discussed it with @romanovvlad and AFAIU, in the current design there are no benefits of including D, as it is likely to be blocked as well.

Copy link
Contributor

@romanovvlad romanovvlad left a comment

Choose a reason for hiding this comment

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

LGTM

@DenisBakhvalov
Copy link
Contributor Author

@bader, please merge if no objections.

@againull againull self-requested a review September 2, 2020 22:24
@againull againull merged commit bc8f0a4 into intel:sycl Sep 2, 2020
bader pushed a commit that referenced this pull request Sep 28, 2020
This patch introduces two use-cases for host-task implementation.

The issue of the first use-case (`test3`) was about performance and a long-run/wait of host-taske depening on another host-task. This issue rooted in lots of enqueue calls for blocked command and was fixed in bc8f0a4 (#2347).

The second use-case shows a deadlock situation when host-task `A` depends on the blocked one `B` via call `handler::depends_on()`. The `A` host-task won't be enqueued as it's `EmptyCommand` is in blocked state.
The test for this use-case is disable now and will be enabled when the deadlock is fixed.

The deadlock will be fixed in follow-up patch.
jsji pushed a commit that referenced this pull request Feb 15, 2024
It should have tested DebugInfoNone base type

Signed-off-by: Sidorov, Dmitry <dmitry.sidorov@intel.com>

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@e0aef72fee42e0a
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