To execute set and reset commands, amd-smi needs sudo
privileges. Updated the subcommand help text to show
'sudo' requirement for these commands.
Signed-off-by: Bindhiya Kanangot Balakrishnan <Bindhiya.KanangotBalakrishnan@amd.com>
Co-authored-by: Arif, Maisam <Maisam.Arif@amd.com>
Change Versioning Scheme to match https://semver.org/
Dropping the year enum and API fields in a future release.
Should not impact library versioning since we are now starting from 25.2.0
---------
Signed-off-by: Joseph Narlo <joseph.narlo@amd.com>
Co-authored-by: Arif, Maisam <Maisam.Arif@amd.com>
Change-Id: Id090e23f156926d08f9c0b781447388adf268cf6
Changed amdsmi_get_rocm_version() to be an API in the python library only.
Updated usage and version detection
Updated path detection of librocm-core.so
Updated docs to reflect both amdsmi_get_rocm_version and amdsmi_get_lib_version() do not require initialization.
Signed-off-by: Arif, Maisam <Maisam.Arif@amd.com>
Update to break apart try/except clause around entire gpu clocks functions. Broke down to each individual gpu_metric which allowed valid data to populate.
Signed-off-by: Juan Castillo <juan.castillo@amd.com>
Updated get_cache_info to use level, type, cache_size_kb,
and num_cu_shared as key to increment num_cache_instance.
Signed-off-by: Juan Castillo <juan.castillo@amd.com>
Change-Id: I54c88263bce5a49713f15e2687ae05212423b186
Most sysfs reads do not require cross-process level mutex, and writes to sysfs
should be protected by the kernel already.
Users can still switch to the old behavior by setting the environment variable AMDSMI_MUTEX_CROSS_PROCESS=1.
After some update to amdclang a tag '--no-allow-shlib-undefine' began
being enforced. This caused compile failure when building with:
CC=amdclang CXX=amdclang++ cmake -B build
DRM_AMDGPU_LIB is never used.
DRM_LIBRARIES is the one set by pkg_check_modules(DRM...)
Change-Id: I031aa1325b7a09a027aba8ca5cc7cc44fe86d3be
Signed-off-by: Galantsev, Dmitrii <dmitrii.galantsev@amd.com>
Blacklisted TestVoltCurvRead for devices with gfx_target_version
90400, 90401 and 90402 as it is not supported on these systems.
Signed-off-by: Bindhiya Kanangot Balakrishnan <Bindhiya.KanangotBalakrishnan@amd.com>
1) When `clang` is used as system compiler, libraries were built without respecting LDFLAGS. For example, this affected LTO flags, if any (and it only affected clang, not gcc).
2) Linker flags are registered as CXX flags, which produces warnings during compilation:
```
clang++: warning: -Wl,-z,noexecstack: 'linker' input unused [-Wunused-command-line-argument]
clang++: warning: -Wl,-znoexecheap: 'linker' input unused [-Wunused-command-line-argument]
clang++: warning: -Wl,-z,relro: 'linker' input unused [-Wunused-command-line-argument]
clang++: warning: -Wl,-z,now: 'linker' input unused [-Wunused-command-line-argument]
```
3) Clang does not support `-Wtrampolines` flag:
```
warning: unknown warning option '-Wtrampolines' [-Wunknown-warning-option]
```
4) No linkers support `noexecheap` anymore. `noexecheap` linker flag was a part of PaX patches to GNU ld, (which were dropped in 2017)[https://www.gentoo.org/support/news-items/2017-08-19-hardened-sources-removal.html]. Now ld/ld.lld/ld.gold don't support it and protection of heap is managed by NX bit. Therefore every compiler produces this warning:
```
ld.lld: warning: unknown -z value: noexecheap
```
Change-Id: I2334a4d4c745df2abc12d543616ca179f85c3575
Signed-off-by: Galantsev, Dmitrii <dmitrii.galantsev@amd.com>
Co-authored-by: Sv. Lockal <lockalsash@gmail.com>
Pryor, Adam
Narlo, Joseph
Park, Peter
Arif, Maisam
Kanangot Balakrishnan, Bindhiya
dependabot[bot]
Williams, Justin
Mewar, Deepak
Pham, Gabriel
Galantsev, Dmitrii
Ramakrishnan, Ranjith
Castillo, Juan
Poag, Charis
Liu, Shuzhou (Bill)