This reverts commit 4de1e4094a.
DRM device id does not always match GPU ID in the rocm_smi.py. This leads to cases where wrong device is checked by os.path.isfile().
Change-Id: Ib6f2b9be123b7eb64334d3feec57f63d7eb37d6f
[ROCm/amdsmi commit: be66d67ef2]
This reverts commit 2ba625e569.
DRM device id does not always match GPU ID in the rocm_smi.py. This leads to cases where wrong device is checked by os.path.isfile().
Change-Id: Ib6f2b9be123b7eb64334d3feec57f63d7eb37d6f
[ROCm/rocm_smi_lib commit: be66d67ef2]
OCLCreateImage test passed when the image was not supported at all.
Add a warning.
For ASIC without image support, let the test pass.
Change-Id: I13c015561a51879f052c2c2d56c672ffbdbe0641
[ROCm/clr commit: 0d29a523d3]
OCLCreateImage test passed when the image was not supported at all.
Add a warning.
For ASIC without image support, let the test pass.
Change-Id: I13c015561a51879f052c2c2d56c672ffbdbe0641
Otherwise the test failed because KFD returns failure to map or prefetch
the SVM range to those GPUs which don't support SVM.
Change-Id: Ideaec2a686bfabb2fd6ae41b1a690da144121a89
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
Otherwise the test failed because KFD returns failure to map or prefetch
the SVM range to those GPUs which don't support SVM.
Change-Id: Ideaec2a686bfabb2fd6ae41b1a690da144121a89
Signed-off-by: Philip Yang <Philip.Yang@amd.com>
[ROCm/ROCR-Runtime commit: c05c66e756]
- Got rid of `source/lib/omnitrace/include` and `source/lib/omnitrace/src` and merged into `source/lib/omnitrace`
- Updated perfetto submodule to v25.0
- Updated papi submodule
[ROCm/rocprofiler-systems commit: 1f66e23fdd]
- Got rid of `source/lib/omnitrace/include` and `source/lib/omnitrace/src` and merged into `source/lib/omnitrace`
- Updated perfetto submodule to v25.0
- Updated papi submodule
In the LLVM rework, a line was accidentally changed from
isaBuffer1 to isaBuffer, causing VramCacheCoherenceWithRemoteGPU
to fail. Change it back.
Signed-off-by: David Francis <David.Francis@amd.com>
Change-Id: Ie1f3465b5c46556f18682d1b3d1f086bb790c648
In the LLVM rework, a line was accidentally changed from
isaBuffer1 to isaBuffer, causing VramCacheCoherenceWithRemoteGPU
to fail. Change it back.
Signed-off-by: David Francis <David.Francis@amd.com>
Change-Id: Ie1f3465b5c46556f18682d1b3d1f086bb790c648
[ROCm/ROCR-Runtime commit: 4b041a8ad9]
Set release scope as system for dispatch AQL when events are passed to
hip*LaunchKernelGGL*
Change-Id: I93b91591e0ab023f1ecc5247f7905eca26147358
[ROCm/clr commit: 02566677cf]
This test stresses the concurrent writing of trace buffer records while
frequently allocating new storage to hold the records.
Due to race conditions, this test fails with the current trace buffer
implementation.
Change-Id: I0b77c64005e776319bf21f1ee1e6d7c99ddccfff
[ROCm/roctracer commit: 200e27f12d]
This test stresses the concurrent writing of trace buffer records while
frequently allocating new storage to hold the records.
Due to race conditions, this test fails with the current trace buffer
implementation.
Change-Id: I0b77c64005e776319bf21f1ee1e6d7c99ddccfff
- channel format should be consistent accross parameters
Signed-off-by: sdashmiz <shadi.dashmiz@amd.com>
Change-Id: I1e7680ab9262a66e7bea4aaa21f061044b0f7956
Update HIP's unsafeAtomicAdd to:
- Compile properly even when not compiling for gfx90a
- Fall back to safe atomic add on non-gfx90a architectures
- use flat atomic add for FP64 on gfx90a, instead of dynamically
checking memory spaces.
In addition, when the compiler is passed -munsafe-fp-atomics, it
will define __AMDGCN_UNSAFE_FP_ATOMICS__. When this happens, the
compiler is requesting that the HIP headers force all HIP
atomicAdd() calls on floats or doubles to use their unsafe versions.
This patch thus causes unsafeAtomicAdd() calls when that define
is seen. This call to unsafeAtomicAdd() is also done for atomicSub(),
since that calls atomicAdd underneath. This is not done for
system-scope atomicAdd because, on gfx90a, system-scope atomic FP
add instructions would need to target fine-grained memory, which is
always unsafe.
This patch also creates safeAtomicAdd() functions for float and double.
These functions will create a standalone safe atomic, even when the
application is compiled with -munsafe-fp-atomics.
Finally, this patch adds wrappers in the Nvidia path of HIP so that
these HIP functions call through to atomicAdd there as well.
Change-Id: I8af0621d3d28ea30c9278bfeea7393d03bbdac6d
[ROCm/hipother commit: b712a51e74]
Update HIP's unsafeAtomicAdd to:
- Compile properly even when not compiling for gfx90a
- Fall back to safe atomic add on non-gfx90a architectures
- use flat atomic add for FP64 on gfx90a, instead of dynamically
checking memory spaces.
In addition, when the compiler is passed -munsafe-fp-atomics, it
will define __AMDGCN_UNSAFE_FP_ATOMICS__. When this happens, the
compiler is requesting that the HIP headers force all HIP
atomicAdd() calls on floats or doubles to use their unsafe versions.
This patch thus causes unsafeAtomicAdd() calls when that define
is seen. This call to unsafeAtomicAdd() is also done for atomicSub(),
since that calls atomicAdd underneath. This is not done for
system-scope atomicAdd because, on gfx90a, system-scope atomic FP
add instructions would need to target fine-grained memory, which is
always unsafe.
This patch also creates safeAtomicAdd() functions for float and double.
These functions will create a standalone safe atomic, even when the
application is compiled with -munsafe-fp-atomics.
Finally, this patch adds wrappers in the Nvidia path of HIP so that
these HIP functions call through to atomicAdd there as well.
Change-Id: I8af0621d3d28ea30c9278bfeea7393d03bbdac6d
Update HIP's unsafeAtomicAdd to:
- Compile properly even when not compiling for gfx90a
- Fall back to safe atomic add on non-gfx90a architectures
- use flat atomic add for FP64 on gfx90a, instead of dynamically
checking memory spaces.
In addition, when the compiler is passed -munsafe-fp-atomics, it
will define __AMDGCN_UNSAFE_FP_ATOMICS__. When this happens, the
compiler is requesting that the HIP headers force all HIP
atomicAdd() calls on floats or doubles to use their unsafe versions.
This patch thus causes unsafeAtomicAdd() calls when that define
is seen. This call to unsafeAtomicAdd() is also done for atomicSub(),
since that calls atomicAdd underneath. This is not done for
system-scope atomicAdd because, on gfx90a, system-scope atomic FP
add instructions would need to target fine-grained memory, which is
always unsafe.
This patch also creates safeAtomicAdd() functions for float and double.
These functions will create a standalone safe atomic, even when the
application is compiled with -munsafe-fp-atomics.
Finally, this patch adds wrappers in the Nvidia path of HIP so that
these HIP functions call through to atomicAdd there as well.
Change-Id: I8af0621d3d28ea30c9278bfeea7393d03bbdac6d
[ROCm/clr commit: f68149eafd]
Update HIP's unsafeAtomicAdd to:
- Compile properly even when not compiling for gfx90a
- Fall back to safe atomic add on non-gfx90a architectures
- use flat atomic add for FP64 on gfx90a, instead of dynamically
checking memory spaces.
In addition, when the compiler is passed -munsafe-fp-atomics, it
will define __AMDGCN_UNSAFE_FP_ATOMICS__. When this happens, the
compiler is requesting that the HIP headers force all HIP
atomicAdd() calls on floats or doubles to use their unsafe versions.
This patch thus causes unsafeAtomicAdd() calls when that define
is seen. This call to unsafeAtomicAdd() is also done for atomicSub(),
since that calls atomicAdd underneath. This is not done for
system-scope atomicAdd because, on gfx90a, system-scope atomic FP
add instructions would need to target fine-grained memory, which is
always unsafe.
This patch also creates safeAtomicAdd() functions for float and double.
These functions will create a standalone safe atomic, even when the
application is compiled with -munsafe-fp-atomics.
Finally, this patch adds wrappers in the Nvidia path of HIP so that
these HIP functions call through to atomicAdd there as well.
Change-Id: I8af0621d3d28ea30c9278bfeea7393d03bbdac6d
Eliminates the need for manually assembling the source of the
second level trap handler to produce the shader binary. Also
separated blit shaders' binary source and version one second
level trap handler binary sources into different header files.
Change-Id: If29a18ee06dc083ec880ea962f234c6b5cac806a
Eliminates the need for manually assembling the source of the
second level trap handler to produce the shader binary. Also
separated blit shaders' binary source and version one second
level trap handler binary sources into different header files.
Change-Id: If29a18ee06dc083ec880ea962f234c6b5cac806a
[ROCm/ROCR-Runtime commit: 1b0440e7b3]
Starting from rocm 5.2 there is a reorganization of the
include directories. This pr allows to compile
rccl on both the old and the new directory layout.
This solution is using find_package() for identifying correct
settings for rocm_smi starting from rocm-5.2, and the original (manual)
settings for all previous releases.
Tested with rocm-5.2, 5.1.1, 5.0.2, and 4.5.2.
[ROCm/rccl commit: 4c4a7cb696]
Elena Sakhnovitch
Alex Xie
Philip Yang
German Andryeyev
Jonathan R. Madsen
David Francis
Chauncey Hui
Tony Tye
Yifan Zhang
Kiumars Sabeti
Jaydeep Patel
Saleel Kudchadker
Laurent Morichetti
sdashmiz
Joseph Greathouse
Sarbojit Sarkar
Shweta Khatri
Jenkins
Edgar Gabriel
ROCm CI Service Account
Edgar