[UR] [L0 v2] Enable wait lists and signal events for command buffer in L0 adapter v2 #18442
Conversation
| ur_device_handle_t hDevice = nullptr; | ||
|
|
||
| // tells if event has been enqueued in some way (e.g. by appending to a queue) | ||
| bool isEventInUse = true; |
There was a problem hiding this comment.
Hm, this might be a bit error-prone, especially if you're not setting it for regular operations. Could we use resetQueueAndCommand instead and query if we have ommandType set?
There was a problem hiding this comment.
It is true that this may be error prone, however I don't think that your suggestion does what is required - we need to mark events that are signaled by command buffers, and not use them until the command buffer is enqueued. In that case the commandType is still set, and I don't think this is the way to distinguish events created by queue, from these created by command buffer
| return UR_RESULT_SUCCESS; | ||
| } | ||
| void ur_exp_command_buffer_handle_t_::registerEvent(ur_event_handle_t event) { | ||
| addedEvents.push_back(event); |
There was a problem hiding this comment.
what are the addedEvents used for?
There was a problem hiding this comment.
It is used to enable all events of command buffer when it is enqueued.
| const std::vector<ur_device_handle_t> hDevices; | ||
| v2::command_list_cache_t commandListCache; | ||
| v2::event_pool_cache eventPoolCache; | ||
| v2::event_pool_cache eventPoolCacheImmediate, eventPoolCacheRegular; |
There was a problem hiding this comment.
nit: for consistency, please define the variables in separate lines
| const ur_event_handle_t *phEventWaitList) try { | ||
| for (uint32_t i = 0; i < numEvents; ++i) { | ||
| if (!phEventWaitList[i]->getIsEventInUse()) { | ||
| // TODO: This is a workaround for the underlying inconsistency |
There was a problem hiding this comment.
So what's the state of regular and counter-based events by default right now? Is it that regular events are not signaled? If so, could we just signal them manually?
There was a problem hiding this comment.
As far as I understand, when regular event is signaled by command buffer that has not been enqueued, it is signaled. However, as soon as command buffer gets enqueued the event becomes not signaled, and waits for command buffer execution. However, that is not the case for counter-based events, what causes issues - if we use counter-based event, the event that is signaled by not enqueued command buffer is not signaled by default.
Maybe @pbalcer can explain it clearer.
|
Closing this PR, since it has some functionality that does not seem to work properly with L0 driver. |
2 participants
No description provided.