-
Notifications
You must be signed in to change notification settings - Fork 796
[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
Conversation
Pull to update my local fork
list prior to executing that command list.
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.
Are we deliberately changing naming convention to LEVEL_ZERO for new vars?
Just checking.
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 for docs
} | ||
|
||
pi_result _pi_queue::executeOpenCommandList() { | ||
if (this->RefCount > 0) { |
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.
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?
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.
Possibly, I am not sure. But if it is always true it is harmless, and we could remove it in a separate change-set.
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.
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.
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, will remove this.
: ZeCommandQueue{Queue}, Context{Context}, Device{Device} {} | ||
pi_device Device, pi_uint32 QueueBatchSize) | ||
: ZeCommandQueue{Queue}, Context{Context}, Device{Device}, | ||
QueueBatchSize{QueueBatchSize} {} |
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.
why do we need batch size to be a member of a queue instead of just using ZeCommandListBatchSize
?
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.
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.
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, but please clarify this intention of QueueBatchSize
in 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.
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(); |
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.
here and in all other places you call executeOpenCommandList
please check return code and return if it is not PI_SUCCESS
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 do that.
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.
see comments
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.
comments
…nt in executeOpenCommandList as requested in code review.
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.
Thanks! LGTM.
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
[DeviceASAN] Bugfix for GetDeviceType
[DeviceASAN] Bugfix for GetDeviceType
No description provided.