Skip to content

[SYCL][PI][L0] Add batching of multiple command into a command list before executing that command list. #2605

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
merged 7 commits into from
Oct 7, 2020

Conversation

kbsmith-intel
Copy link
Contributor

No description provided.

kbsmith-intel and others added 2 commits October 6, 2020 14:39
Pull to update my local fork
Copy link
Contributor

@pvchupin pvchupin left a comment

Choose a reason for hiding this comment

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

Are we deliberately changing naming convention to LEVEL_ZERO for new vars?
Just checking.

pvchupin
pvchupin previously approved these changes Oct 7, 2020
Copy link
Contributor

@pvchupin pvchupin left a comment

Choose a reason for hiding this comment

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

ok for docs

}

pi_result _pi_queue::executeOpenCommandList() {
if (this->RefCount > 0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

With the queue being locked for the duration of each PI API using this queue, is it really possible for this condition to ever be false?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Possibly, I am not sure. But if it is always true it is harmless, and we could remove it in a separate change-set.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd rather not add dead code from the beginning. It also gives bad example to others who may be adding more such checks, which certainly don't add clarity to the code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, will remove this.

: ZeCommandQueue{Queue}, Context{Context}, Device{Device} {}
pi_device Device, pi_uint32 QueueBatchSize)
: ZeCommandQueue{Queue}, Context{Context}, Device{Device},
QueueBatchSize{QueueBatchSize} {}
Copy link
Contributor

Choose a reason for hiding this comment

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

why do we need batch size to be a member of a queue instead of just using ZeCommandListBatchSize?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was setting this code up for the future. By making this a field of the queue that gets set at queue creation time based on the global ZeCommandListBatchSize global variable/env var, I can allow a heuristic to change this on a queue specific basis without introducing any race/thread unsafe global var uses since fields of the queue are now all guarded in a thread safe manner. So, while not specifically necessary, I think it is an excellent way to make it easier to add heuristics for batching in the future.

Copy link
Contributor

Choose a reason for hiding this comment

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

OK, but please clarify this intention of QueueBatchSize in a comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do.

// go ahead and execute what is already in the batched list,
// and then go on to process this. On exit from executeOpenCommandList
// ZeOpenCommandList will be nullptr.
Queue->executeOpenCommandList();
Copy link
Contributor

Choose a reason for hiding this comment

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

here and in all other places you call executeOpenCommandList please check return code and return if it is not PI_SUCCESS

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, I will do that.

Copy link
Contributor

@smaslov-intel smaslov-intel left a comment

Choose a reason for hiding this comment

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

see comments

Copy link
Contributor

@smaslov-intel smaslov-intel left a comment

Choose a reason for hiding this comment

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

comments

…nt in

executeOpenCommandList as requested in code review.
Copy link
Contributor

@smaslov-intel smaslov-intel left a comment

Choose a reason for hiding this comment

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

Thanks! LGTM.

@pvchupin pvchupin merged commit b9d72a9 into intel:sycl Oct 7, 2020
jsji pushed a commit that referenced this pull request Jun 27, 2024
The affected source files were relying on transitive includes that
were no longer included after recent llvm-project changes (such as
36c6632 ("[IR] Don't include PassInstrumentation.h in
PassManager.h (NFC) (#96219)", 2024-06-21)).

Original commit:
KhronosGroup/SPIRV-LLVM-Translator@97069a601d2e733
kbenzie added a commit to kbenzie/intel-llvm that referenced this pull request Feb 17, 2025
Chenyang-L pushed a commit that referenced this pull request Feb 18, 2025
[DeviceASAN] Bugfix for GetDeviceType
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.

3 participants