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]
Enqueue a handler callback for hipEventRecords(aka marker_ts_) for every
64 submits, This recycles the memory if we dont end up calling
synchronize for the longest time.
Change-Id: I3d39fe76d52a5d81387927edd85b5663b563682c
[ROCm/clr commit: fa76f03654]
Enqueue a handler callback for hipEventRecords(aka marker_ts_) for every
64 submits, This recycles the memory if we dont end up calling
synchronize for the longest time.
Change-Id: I3d39fe76d52a5d81387927edd85b5663b563682c
Disable hostcall buffer in OCL for now. COv5 can add hostcallbuffer
metadata for unknown reason. OCL may fail the buffer allocation
and kernel launch.
Change-Id: I34a6a45bac86c57422b764c0d69760c96920d6c5
[ROCm/clr commit: 934149ff0a]
Disable hostcall buffer in OCL for now. COv5 can add hostcallbuffer
metadata for unknown reason. OCL may fail the buffer allocation
and kernel launch.
Change-Id: I34a6a45bac86c57422b764c0d69760c96920d6c5
- hipHostRegister should return hipErrorInvalidValue when size is 0 or
size doesn't match the actual allocated size
- hipMemAllocPitch should return hipErrorInvalidValue when width or height
is 0 and elementSizeBytes should be 4, 8 or 16
Change-Id: I43c9fe4ac1ef0a6ac2f953908d301508a7bc5aa3
[ROCm/clr commit: 06203c251e]
- hipHostRegister should return hipErrorInvalidValue when size is 0 or
size doesn't match the actual allocated size
- hipMemAllocPitch should return hipErrorInvalidValue when width or height
is 0 and elementSizeBytes should be 4, 8 or 16
Change-Id: I43c9fe4ac1ef0a6ac2f953908d301508a7bc5aa3
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
ROCm CI Service Account
Satyanvesh Dittakavi
Christophe Paquot