Fixes the elapsed time for the scenarios where HIP API takes one of the start/stop events
and another one is recorded using hipEventRecord.
Change-Id: I51831b2651fc8e7207ff0e3fcc6dc7c1b4239fa8
Submit explicit profile marker for hipEventRecord to record
timestamps. Enable explicit signal profiling if the API specifies
start and stop events.
Toggle this with env var HIP_FORCE_QUEUE_PROFILING=0
Change-Id: Iae449a63ec3ebf6c2880e65d7b1dd1031a29018f
Hip applications assume that hipEventRecord called from multiple
threads will contain exactly the last queued command to the stream.
Change-Id: I1da3259f143d7670d0870d9a47c08e32336b2222
SWDEV-237377 - This fixes time calculation where the event may
be recorded on Null stream and work submitted on other streams
Change-Id: Ie36310dea5cee2fed4a514ed01f04db4b47e571c
If the start and stop events have same command internally
then measure command end to command start
Change-Id: Ie70cfa37c06c06573f0ed58dab2bbe4434c1724b
This issue happens because we getLastQueuedCommand when recording
the event and do end_ - start_ so it takes the ticks for the
completion of the last command before event record. This may not
happen if one records a marker command for hipEventRecord
Change-Id: I1d6b06a5befb3b93f16b67692c59dca25c982e0f
Satyanvesh Dittakavi
kjayapra-amd
Saleel Kudchadker
German Andryeyev
Payam