Zero size pools have no numa bindings. Selecting a pool with numa
bindings should prevent thrashing due to numa balancing daemon.
Change-Id: Ib0082cb9af66e24e07a2adbb83c1045145d51403
Zero size pools have no numa bindings. Selecting a pool with numa
bindings should prevent thrashing due to numa balancing daemon.
Change-Id: Ib0082cb9af66e24e07a2adbb83c1045145d51403
[ROCm/ROCR-Runtime commit: 32bb10086d]
This has nothing to do with registering agents.
Moved to Runtime::Load.
Change-Id: I0f84c9d8f5a68d458717111113f02af56c92f4f6
[ROCm/ROCR-Runtime commit: 40d1931209]
Memory from the suballocator may be exported via IPC. If this
happens then the allocating process should not reuse that memory
since it would still be connected to the remote process. IPC exported
memory must be released back to the driver.
Change-Id: I2ab0c814f63191f753fc3640cc4140ee144bf07f
Memory from the suballocator may be exported via IPC. If this
happens then the allocating process should not reuse that memory
since it would still be connected to the remote process. IPC exported
memory must be released back to the driver.
Change-Id: I2ab0c814f63191f753fc3640cc4140ee144bf07f
[ROCm/ROCR-Runtime commit: 29b660c91e]
All types which could be generated from a fragment need to take this branch.
Taking the branch is correct for all types, it was a performance optimization
only and was missing IPC. Branch removal simplifies updates for any future
fragment use and will allow CQE to report any performance issues that might
require bringing the branch back.
Change-Id: I8041788c422e880b764e144eb1877f5126ba76f3
All types which could be generated from a fragment need to take this branch.
Taking the branch is correct for all types, it was a performance optimization
only and was missing IPC. Branch removal simplifies updates for any future
fragment use and will allow CQE to report any performance issues that might
require bringing the branch back.
Change-Id: I8041788c422e880b764e144eb1877f5126ba76f3
[ROCm/ROCR-Runtime commit: 09ebc21d13]
Thunk may report nullptr for host base if the host does not have
access. Use agent base in this case.
Change-Id: I44883d35a3fff0941b1e3037d16b059591a6c511
Thunk may report nullptr for host base if the host does not have
access. Use agent base in this case.
Change-Id: I44883d35a3fff0941b1e3037d16b059591a6c511
[ROCm/ROCR-Runtime commit: 397608e2c0]
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]
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
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]
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
Chauncey Hui
Aryan Salmanpour
Sean Keely
Evgeny
jujiang
Christophe Paquot
kjayapra-amd
Joseph Greathouse