Very nice! Hopefully, we will find more people who would like to help with the testing. So far, I can only extrapolate from my own experience and the issues on GitHub. Most of them are concerned with build failures and hardly address runtime issues with supported GPUs. Having first hand information on the performance of the ROCm stack on different GPU architectures is very important when shipping the binary packages.I own a RX 5700 XT (gfx1010), if specific testing is required.
Awesome! Regarding ML with ROCm I already had a short conversation with Konstantin (kgizdov) who's maintaining the ML packages for Arch Linux. He's eager to include a ROCm backend and is looking forward to my possible future contributions.Python scientific computing / data science ecosystem, with a focus on packaging, so I am looking forward to this, and helping out where I can.
That's (partly) done intentionally. Most of the ROCm packages enable a "Release" build by default, see [1,2] for instance. As I've been trying to stay a close as possible to upstream (and the official Debian packages) I haven't touched CMAKE_BUILD_TYPE. I'm of course willing to change this.I noticed was the missing -DCMAKE_BUILD_TYPE=None argument from CMake packages
+1 on the candidate for me!
Thank you! :) Best! Torsten[1] https://github.com/ROCmSoftwarePlatform/rocBLAS/blob/f4826cbfce09fb1ed6292d8378e1b8ac0de34470/CMakeLists.txt#L29 [2] https://github.com/ROCmSoftwarePlatform/rocSPARSE/blob/3a05469742e91841676f545ed1e62918f78cb3a8/CMakeLists.txt#L44
OpenPGP_0xAF5FF1C93CF09D12.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
