-
Notifications
You must be signed in to change notification settings - Fork 189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HIP issue list as discussed in the offline meeting #2973
Comments
That one was due to incorrect
Please merge the latest master branch, that issue has been fixed since #2937. |
https://gitlab.icp.uni-stuttgart.de/espressomd/espresso/-/jobs/142467 That one was reproducible on an Nvidia 2080, but we don't have that in CI. So one more case where AMD actually helped find a bug that can affect Nvidia too. |
|
The ROCm library rocFFT broke on multiple occasions:
|
That's an odd one. Why does that test even call into HIP code?
|
It happened again today, dedicated ticket: #3620 |
@mkuron I think the gpu initialization code if always run, to detect the devices present and so on, but I haven't checked. |
ROCm 3.3 was released last night (not sure what happened to 3.2). It's installed for testing on lama. It's still broken in multiple ways:
At least they fixed the |
|
No idea about that one, it's either a hardware or driver issue, and a heisenbug too. We don't have anyone here who understands the Barnes-Hut code, so our debugging abilities are rather limited. |
|
|
The first two cases were a due to a broken SSD, the other one was due to a crashed graphics driver. |
as long as we do not have redundancy for testing rocm, we cannot use it in CI. |
Closes #2973, closes #3895, follow-up to espressomd/docker#190 Due to their fast release cycle, ROCm packages are not stable enough for ESPResSo. We are currently supporting ROCm 3.0 to 3.7, which means supporting two compilers (HCC and HIP-Clang) and keeping patches for each ROCm release in our codebase. Maintaining these patches and the CMake build system for ROCm is time-consuming. The ROCm job also has a tendency to break the CI pipeline (#2973), sometimes due to random or irreproducible software bugs in ROCm, sometimes due to failing hardware in both the main CI runner and backup CI runner. The frequency of false positives in CI is too large compared to the number of true positives. The last true positives were 5da80a9 (April 2020) and #2973 (comment) (July 2019). There are no known users of ESPResSo on AMD GPUs according to the [May 2020 user survey](https://lists.nongnu.org/archive/html/espressomd-users/2020-05/msg00001.html). The core team has decided to drop support for ROCm ([ESPResSo meeting 2020-10-20](https://github.com/espressomd/espresso/wiki/Espresso-meeting-2020-10-20)). The Intel image cannot be built automatically in the espressomd/docker pipeline. Re-building it manually is a time-consuming procedure, usually several hours, due to long response time from the licensing server and the size of the Parallel Studio XE source code. When a new Intel compiler version is available, it usually requires the expertise of two people to update the dockerfile. The core team has decided to remove the Intel job from CI and use the Fedora job to test ESPResSo with MPICH.
unreadable error message at runtime
The text was updated successfully, but these errors were encountered: