RUNPATH in libraries will be : $ORIGIN
RUNPATH in binaries will be : $ORIGIN/../lib
Change-Id: Iafa66a8e02cc8c5783903d40927b63652042d2f1
[ROCm/ROCR-Runtime commit: ad002f1e7b]
Update documentation for hsa_amd_pointer_info to clarify which fields
are invalid when the allocation type is HSA_EXT_POINTER_TYPE_UNKNOWN.
Change-Id: Idaed985962c4a98d281ebe01bef8ec2459da3985
Update documentation for hsa_amd_pointer_info to clarify which fields
are invalid when the allocation type is HSA_EXT_POINTER_TYPE_UNKNOWN.
Change-Id: Idaed985962c4a98d281ebe01bef8ec2459da3985
[ROCm/ROCR-Runtime commit: 39feb83b88]
hipcc and clang++ both have logic to detect the installed hardware
and to automatically select the appropriate AMDGPU target when it is
left unspecified. When the AMDGPU_TARGETS property is initialized with
a set of default values, it results in the addition of an explicit set
of --offload-arch flags being passed. These explicit architecture flags
disable the architecture autodetection in the compiler.
The resulting behaviour from setting fixed defaults makes it unpleasant
to compile with CMake because they increase the build times for projects
unless they are overriden (as most users do not need to build for all
five default architectures). The fixed defaults are also troublesome for
users with hardware not included in the default set (e.g., gfx1011,
gfx1031, gfx1100).
A possible alternative might be to detect the architecture within
hip-config.cmake rather than running the detection logic on each
compiler invocation. However, this approach is simpler.
Change-Id: I9495d766b7eed03852eb4dc72b0aabe4100bc32c
Signed-off-by: Cordell Bloor <Cordell.Bloor@amd.com>
[ROCm/clr commit: e1bed6f354]
hipcc and clang++ both have logic to detect the installed hardware
and to automatically select the appropriate AMDGPU target when it is
left unspecified. When the AMDGPU_TARGETS property is initialized with
a set of default values, it results in the addition of an explicit set
of --offload-arch flags being passed. These explicit architecture flags
disable the architecture autodetection in the compiler.
The resulting behaviour from setting fixed defaults makes it unpleasant
to compile with CMake because they increase the build times for projects
unless they are overriden (as most users do not need to build for all
five default architectures). The fixed defaults are also troublesome for
users with hardware not included in the default set (e.g., gfx1011,
gfx1031, gfx1100).
A possible alternative might be to detect the architecture within
hip-config.cmake rather than running the detection logic on each
compiler invocation. However, this approach is simpler.
Change-Id: I9495d766b7eed03852eb4dc72b0aabe4100bc32c
Signed-off-by: Cordell Bloor <Cordell.Bloor@amd.com>
HIPRTC_INIT_API can have nullptr in the arguments and ClPrint
can crash while printing
Change-Id: Iecade5c3867196509c8cc0647b9aa24be0960a02
[ROCm/clr commit: c98fad1edc]
Some workloads running on multi-GPU create 1 process per GPU. So each
process creates a GPU agent on every GPU, but will only create queues on
one GPU. This would cause un-necessary scratch reservation.
Change-Id: I50a216f0bcc0b5f707f3943147390b0ecec1ac22
Some workloads running on multi-GPU create 1 process per GPU. So each
process creates a GPU agent on every GPU, but will only create queues on
one GPU. This would cause un-necessary scratch reservation.
Change-Id: I50a216f0bcc0b5f707f3943147390b0ecec1ac22
[ROCm/ROCR-Runtime commit: 38e832a682]
If the required scratch allocation is too large, ROCr will attempt to
reduce it by lowering the dispatch's targeted occupancy. The reduction
loop however was prone to overflow if waves_per_cu was not a multiple of
waves_per_group. Ensure no overflow by aligning waves_per_cu to
waves_per_group.
On GC 9.4.3 dGPU, dispatches with a large grid size and a
waves_per_group of e.g. 16 may require to reduce occupancy such that
waves_per_cu is less than waves_per_group to ensure the allocation size
is small enough. Allow this while also ensuring the tmpring scratch wave
count is kept divisible by the number of SEs per XCC.
Signed-off-by: Graham Sider <Graham.Sider@amd.com>
Change-Id: Ie4016dcd8166a9ae69e9decc26a3eec882b49480
If the required scratch allocation is too large, ROCr will attempt to
reduce it by lowering the dispatch's targeted occupancy. The reduction
loop however was prone to overflow if waves_per_cu was not a multiple of
waves_per_group. Ensure no overflow by aligning waves_per_cu to
waves_per_group.
On GC 9.4.3 dGPU, dispatches with a large grid size and a
waves_per_group of e.g. 16 may require to reduce occupancy such that
waves_per_cu is less than waves_per_group to ensure the allocation size
is small enough. Allow this while also ensuring the tmpring scratch wave
count is kept divisible by the number of SEs per XCC.
Signed-off-by: Graham Sider <Graham.Sider@amd.com>
Change-Id: Ie4016dcd8166a9ae69e9decc26a3eec882b49480
[ROCm/ROCR-Runtime commit: bd63e5045c]
When we merge thunk into ROCr, kfdtest will be in a different folder
structure. Add the new location to ensure that we can build now and in
the future with no disruptions
Signed-off-by: Kent Russell <kent.russell@amd.com>
Change-Id: I6517e061cb0da7137d903abbc380bfc7126f40d4
When we merge thunk into ROCr, kfdtest will be in a different folder
structure. Add the new location to ensure that we can build now and in
the future with no disruptions
Signed-off-by: Kent Russell <kent.russell@amd.com>
Change-Id: I6517e061cb0da7137d903abbc380bfc7126f40d4
[ROCm/ROCR-Runtime commit: d966243783]
Scratch cache reserved memory is only available for scratch memory use
so do not report this memory as available to the user via the
HSA_AMD_AGENT_INFO_MEMORY_AVAIL api.
Change-Id: I52f96e62536458bcaa52b9f4be5de856d5680dc4
Scratch cache reserved memory is only available for scratch memory use
so do not report this memory as available to the user via the
HSA_AMD_AGENT_INFO_MEMORY_AVAIL api.
Change-Id: I52f96e62536458bcaa52b9f4be5de856d5680dc4
[ROCm/ROCR-Runtime commit: 3477fbc661]
Temporarily disabling rocrtstNeg.Queue_Validation_InvalidGroupMemory
until it is fixed.
Change-Id: Ifc1973a960c8d0bae27e2628e4bfddc60f70325d
[ROCm/ROCR-Runtime commit: 7b74271d5e]
Starting with GFX11, wptr BOs must be mapped to GART for MES to determine work
on unmapped queues for usermode queue oversubscription (no aggregated doorbell)
Change-Id: I10e30fdc2bec587cef9427faa4874957988c34b3
Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
Starting with GFX11, wptr BOs must be mapped to GART for MES to determine work
on unmapped queues for usermode queue oversubscription (no aggregated doorbell)
Change-Id: I10e30fdc2bec587cef9427faa4874957988c34b3
Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
[ROCm/ROCR-Runtime commit: d319660838]
If MES is enabled, wptr has to be non paged memory,
Add an API to check this condition.
Change-Id: I53af1f6687d5332d102e7062c3d760e33b96e722
Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
If MES is enabled, wptr has to be non paged memory,
Add an API to check this condition.
Change-Id: I53af1f6687d5332d102e7062c3d760e33b96e722
Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com>
[ROCm/ROCR-Runtime commit: 53ed978c3d]
gobhardw
Ammar ELWazir
Ranjith Ramakrishnan
David Yat Sin
Cordell Bloor
Cole Ramos
Satyanvesh Dittakavi
Jatin Chaudhary
Graham Sider
Kent Russell
Ioannis Assiouras
Yifan Zhang