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
[ROCm/hip commit: 08cf695e1f]
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
[ROCm/hip commit: 2ef062480b]
The hipOccupancyMaxPotentialBlockSize API is meant to return the
number of threads for the highest-occupancy workgroup, and the number
of those workgroups. It was previously calculating the number of
maximum-sized workgroups that would fit on a single CU. This is
a mixture of the API we wanted (to calculate max potential block size)
and the MaxBlocksPerMultiprocessor function.
This patch fixes it up so that the internal occupancy calculation
function works for two uses: the traditional function that calculates
the maximum blocks per multiprocessor when a user passes in a fixed
block size (used for hipMaxBlocksPerMultiprocessor style functions)
and a function that calculates the size of a block that would lead
to maximum occupancy, and how many blocks of that size would be
needed to fill the whole GPU (for hipOccupancyMaxPotentialBlockSize
style functions).
This also updates the occupancy calculation function to prepare for
gfx10, which does not have SGPR-based occupancy limits.
Change-Id: Ie007b3f9d5ebc4e166b50a3a051498af35650f35
[ROCm/hip commit: ebe5054e04]
SWDEV-237377 - This fixes time calculation where the event may
be recorded on Null stream and work submitted on other streams
Change-Id: Ie36310dea5cee2fed4a514ed01f04db4b47e571c
[ROCm/hip commit: fb2d7bcd2b]
We should be returning the max workgroup size calculated by the compiler.
Change-Id: If86590efbb9b291f470bdbe87e5df992e661c539
[ROCm/hip commit: 1b1c032e9f]