[SYCL] Support profiling info for event returned by NOP barrier #12949
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently if barrier without wailist is submitted to the in-order queue without last command (empty queue) then we return default constructed event which doesn't have profiling info because it is not associated with queue. Associate such event with the queue and record submission time which equal to start time and end time for such event because it basically correpsonds to NOP.
againull
force-pushed
the
empty_event_profiling
branch
from
a879ea3
to
2d7a5f1
Compare
cperkinsintel
approved these changes
Mar 8, 2024
sergey-semenov
added a commit
to sergey-semenov/llvm
that referenced
this pull request
Jun 10, 2024
… NOP barrier (intel#12949)" This reverts commit 200694b.
sergey-semenov
added a commit
that referenced
this pull request
Jun 13, 2024
…14123) Current implementation of profiling info for NOP barriers is inconsistent with other events from the same queue (e.g., if the previous event started after the barrier was submitted). To make them consistent while keeping the optimization, we would need to duplicate the event on our side and make the duplicate check and potentially use profiling info of its previous event. Instead, as the first step, disable the NOP optimization during profiling since profiling is known to incur a performance hit anyway. The proper duplicate event approach can be implemented as a follow up if this causes issues for users. Partially reverts #12949
ianayl
pushed a commit
to ianayl/sycl
that referenced
this pull request
Jun 13, 2024
…ntel#14123) Current implementation of profiling info for NOP barriers is inconsistent with other events from the same queue (e.g., if the previous event started after the barrier was submitted). To make them consistent while keeping the optimization, we would need to duplicate the event on our side and make the duplicate check and potentially use profiling info of its previous event. Instead, as the first step, disable the NOP optimization during profiling since profiling is known to incur a performance hit anyway. The proper duplicate event approach can be implemented as a follow up if this causes issues for users. Partially reverts intel#12949
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently if ext_oneapi_barrier without waitlist is submitted to the in-order queue that doesn't have the last command (empty queue) then we return default constructed event which doesn't have profiling info because it is not associated with any queue. Associate such event with the queue and record submission time which is equal to the start time and the end time for such event because it basically corresponds to NOP.