Upstream soversion is at 5 for a while, but Debian's soversion has been set to
1 in the beginning of the rocm-smi-lib package. This is probably erroneous,
and the library should probably be better off being synchronized with upstream
so there is some kind of ABI compatibility between the two distributions.
.
FIXME: please use upstream soversion next time an ABI breakage justifies an
SOVERSION bump, instead of just incrementing the present version by one.
Author: Étienne Mollier <emollier@debian.org>
Forwarded: not-needed
Last-Update: 2023-09-17
Change-Id: I6c4d28bd26889359c0b83c474d5ae58a81741cf4
Co-authored-by: Étienne Mollier <emollier@debian.org>
Signed-off-by: Galantsev, Dmitrii <dmitrii.galantsev@amd.com>
Upstream soversion is at 5 for a while, but Debian's soversion has been set to
1 in the beginning of the rocm-smi-lib package. This is probably erroneous,
and the library should probably be better off being synchronized with upstream
so there is some kind of ABI compatibility between the two distributions.
.
FIXME: please use upstream soversion next time an ABI breakage justifies an
SOVERSION bump, instead of just incrementing the present version by one.
Author: Étienne Mollier <emollier@debian.org>
Forwarded: not-needed
Last-Update: 2023-09-17
Change-Id: I6c4d28bd26889359c0b83c474d5ae58a81741cf4
Co-authored-by: Étienne Mollier <emollier@debian.org>
Signed-off-by: Galantsev, Dmitrii <dmitrii.galantsev@amd.com>
[ROCm/amdsmi commit: 1775ae4b8d]
Upstream soversion is at 5 for a while, but Debian's soversion has been set to
1 in the beginning of the rocm-smi-lib package. This is probably erroneous,
and the library should probably be better off being synchronized with upstream
so there is some kind of ABI compatibility between the two distributions.
.
FIXME: please use upstream soversion next time an ABI breakage justifies an
SOVERSION bump, instead of just incrementing the present version by one.
Author: Étienne Mollier <emollier@debian.org>
Forwarded: not-needed
Last-Update: 2023-09-17
Change-Id: I6c4d28bd26889359c0b83c474d5ae58a81741cf4
Co-authored-by: Étienne Mollier <emollier@debian.org>
Signed-off-by: Galantsev, Dmitrii <dmitrii.galantsev@amd.com>
[ROCm/rocm_smi_lib commit: 1775ae4b8d]
When built with LTO enabled, the linking of liboam.so chokes on the
following error, which is somewhat similar to the Debian bug #1030876
affecting PA-RISC, although the symptoms subtly differs in that it
suggests to build using -fPIC:
/usr/bin/ld: /tmp/cc0wF8Kx.ltrans0.ltrans.o: relocation R_X86_64_PC32 against symbol `_ZTVSt9exception@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC
The -fPIC argument is passed appropriately down to the build command,
however it looks to be erased by the late introduction of -fPIE flag
by upstream build system. Erasing this flag allows the build to go
through, both with LTO and on PA-RISC.
Bug: https://github.com/RadeonOpenCompute/rocm_smi_lib/issues/111
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015653
Change-Id: I8b35fd4b62cfa1a9ddb145362464df5dd276e2f5
Signed-off-by: Galantsev, Dmitrii <dmitrii.galantsev@amd.com>
When built with LTO enabled, the linking of liboam.so chokes on the
following error, which is somewhat similar to the Debian bug #1030876
affecting PA-RISC, although the symptoms subtly differs in that it
suggests to build using -fPIC:
/usr/bin/ld: /tmp/cc0wF8Kx.ltrans0.ltrans.o: relocation R_X86_64_PC32 against symbol `_ZTVSt9exception@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC
The -fPIC argument is passed appropriately down to the build command,
however it looks to be erased by the late introduction of -fPIE flag
by upstream build system. Erasing this flag allows the build to go
through, both with LTO and on PA-RISC.
Bug: https://github.com/RadeonOpenCompute/rocm_smi_lib/issues/111
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015653
Change-Id: I8b35fd4b62cfa1a9ddb145362464df5dd276e2f5
Signed-off-by: Galantsev, Dmitrii <dmitrii.galantsev@amd.com>
[ROCm/amdsmi commit: c4c19e7917]
When built with LTO enabled, the linking of liboam.so chokes on the
following error, which is somewhat similar to the Debian bug #1030876
affecting PA-RISC, although the symptoms subtly differs in that it
suggests to build using -fPIC:
/usr/bin/ld: /tmp/cc0wF8Kx.ltrans0.ltrans.o: relocation R_X86_64_PC32 against symbol `_ZTVSt9exception@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC
The -fPIC argument is passed appropriately down to the build command,
however it looks to be erased by the late introduction of -fPIE flag
by upstream build system. Erasing this flag allows the build to go
through, both with LTO and on PA-RISC.
Bug: https://github.com/RadeonOpenCompute/rocm_smi_lib/issues/111
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015653
Change-Id: I8b35fd4b62cfa1a9ddb145362464df5dd276e2f5
Signed-off-by: Galantsev, Dmitrii <dmitrii.galantsev@amd.com>
[ROCm/rocm_smi_lib commit: c4c19e7917]
- Address corner cases that can arise with the new
hipMemcpyDeviceToDeviceNoCU enum
- Better log
Change-Id: I6035b901f8d616741054b7a5ff4f67956329ac57
[ROCm/clr commit: 5662d4037c]
If we submit a systemScope Barrier, we should reset this flag as there
is no need for dispatch AQL again to flush caches/HDP
Change-Id: I55710feb4ba6650852e785b5cadfa64c6b9ce14e
[ROCm/clr commit: de2b06a7a7]
If we submit a systemScope Barrier, we should reset this flag as there
is no need for dispatch AQL again to flush caches/HDP
Change-Id: I55710feb4ba6650852e785b5cadfa64c6b9ce14e
Change-Id: I74caa4ab89bd765e59686cfbaaf1ce44ab10fe19
- adds counter correctness tests for GRBM, SQWAVES and SQ INSTRUCTIONs
- pandas dependency
- made it compatible with test infra.
Change-Id: I74caa4ab89bd765e59686cfbaaf1ce44ab10fe19
Change-Id: I74caa4ab89bd765e59686cfbaaf1ce44ab10fe19
- adds counter correctness tests for GRBM, SQWAVES and SQ INSTRUCTIONs
- pandas dependency
- made it compatible with test infra.
Change-Id: I74caa4ab89bd765e59686cfbaaf1ce44ab10fe19
[ROCm/rocprofiler commit: 3f5ddfa0ab]
Add hipMemcpyDeviceToDeviceNoCU to force a non blit copy path. This
helps in cases where an app may determine that CU may be busy and copies
with SDMA may be quicker.
Change-Id: I59b415dd8f6022c244e8d75f265464d5c635df1e
[ROCm/clr commit: f316a30e5d]
Add hipMemcpyDeviceToDeviceNoCU to force a non blit copy path. This
helps in cases where an app may determine that CU may be busy and copies
with SDMA may be quicker.
Change-Id: I59b415dd8f6022c244e8d75f265464d5c635df1e
Maisam Arif
Aryan Salmanpour
Konstantin Zhuravlyov
Julia Jiang
Ajay
Étienne Mollier
Galantsev, Dmitrii
Saleel Kudchadker
Kiriti Gowda
Wenkai Du
Maxime Chambonnet
Rajy Rawther
Yifan Zhang
kjayapra-amd
Giovanni LB
Sriraksha Nagaraj
Ioannis Assiouras
Jaydeep Patel