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/clr commit: 90453b68d3]
We need this otherwise ROCr can give us a matching address
for another allocation and doing "insert" in ROCclr will not
update the map with the newest object. We would then end up
using stale objects (yikes)
SWDEV-234992
Change-Id: I3475adf9781a9309d64a024fae45181d7e5afb04
[ROCm/clr commit: 2cc0fb9381]
In case hipModule(Un)Load is called from different thread as hipInit we need to grab the lock
as both are going to modify modules_
Also add some logging for __hipExtractCodeObjectFromFatBinary in case binary isn't found for GPU
SWDEV-236032
Change-Id: Icbd72b412502df80d5066cea42a4fbcd5b0b8a98
[ROCm/clr commit: 374fd36f31]
We should be returning the max workgroup size calculated by the compiler.
Change-Id: If86590efbb9b291f470bdbe87e5df992e661c539
[ROCm/clr commit: b5f9d2f818]
Tao Sang
kjayapra-amd
Jatin
Joseph Greathouse
Laurent Morichetti
Payam
Evgeny
Christophe Paquot
Vlad Sytchenko