Mystro256/rocm-hip

Description

Test/exploratory builds for ROCm on Fedora (non-OpenCL related). Expect this repo to be unstable.

WARNING: REPO IS FOR TESTING PURPOSES ONLY. PLEASE USE AT YOUR OWN RISK.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Installation Instructions

Instructions not filled in by author. Author knows what to do. Everybody else should avoid this repo.

Active Releases

The following unofficial repositories are provided as-is by owner of this project. Contact the owner directly for bugs or issues (IE: not bugzilla).

* Total number of packages downloaded in the last seven days.


This is a companion discussion topic for the original entry at https://copr.fedorainfracloud.org/coprs/mystro256/rocm-hip/

Thanks @mystro256 for setting this up! Do you have any plans to update this package in the near future to the latest release (i.e. 5.2.1 at the time of writing)?

From what I understand, the latest version has several (if not all) of the extra patches included already which would simplify the spec file as well. However, I think you have a better overview of the patch situation which is why I thought to reach out to you before I start tinkering myself with this.

@awehrfritz yeah most if not all of the patches can be dropped, but I ran into compilation issues likely due to a GCC bump in fedora. I’ll get around to it eventually, but I’ve been a bit too busy lately.

I totally understand, this is not really urgent for me either at the moment, especially since ROCm OpenCL installed via the official Fedora package works like a charm so far.

Though, I was hoping to also get HIP working as that is the primary target for my HPC software development efforts.

Is this package meant as a solution for enabling HIP support in blender? I tried it, and it didn’t work for that purpose on my RX 6700XT. Any suggestions if that is not the purpose of this package?

Hi @morgana,
In principle, blender should work with this package installed. However, in practice it seems there are still quite some issues to be sorted out.

I have created a largely reworked and updated ROCm-hip package here: awehrfritz/rocm-hip Copr
And the respective spec file is here in case you are interested: GitHub - awehrfritz/rocm-hip-rpm: ROCm HIP Fedora Copr rpm package

However, even with the updated package there are still a whole lot of problems. I found in particular that the Perl wrapper scripts around clang/llvm are full of hardcoded paths and essentially only work if the entire stack is installed in /opt/rocm. I have reported some of those issues in upstream bug reports or pull requests, let’s see how fast they can fix them.

Thanks for the info. This is my first time using COPR, so I just want to confirm that i am doing this correctly. As root, I type dnf copr enable mystro256/rocm-hip for this repo or dnf copr enable awehrfritz/rocm-hip for the reworked repo. Then, it’s as simple as sudo dnf install rocm-hip? Again, I thank you for your help. Hopefully this gets resolved in the official Fedora release soon.

Yes, that should get you the packages installed. Just to mention, I have only Fedora 36 enabled at the moment as that is the only system I have tested.

Also, as mentioned above, there are still a lot of problems with these packages, all of which are due to bugs or shortcomings in the upstream source code or build system. For instance, so far I have not managed to correctly compile any of the examples out of the box, I have to manually fix the compiler commands to get that done since there are various issues still in the stack.

Furthermore, Debian and Gentoo have similar issues and implemented various workarounds for older versions. Arch Linux takes a different approach, i.e. install everything on /opt/rocm, and thus seems to have fewer problems.

I don’t think that this will be resolved any time soon, mainly because upstream doesn’t seem to have any interest in getting their software into the distros and moves rather slowly on any bug reports or pull requests.

Yeah I’ve been working with them to resolve a lot of these issues, so they’re known. The Debian guys also are trying to get this packaged too, so I can connect you with them if it helps.

Unfortunately the scale of the problem makes it difficult to resolve in a timely manner.
Please make sure you keep me in the loop and I can see what I can do; my username is Mystro256 on github. If you have any patches in a pull request, I can try to use my connections to attempt to hasten the review process. :slight_smile:

I don’t think this is true:

mainly because upstream doesn’t seem to have any interest in getting their software into the distros

But rather it’s not a priority due to resource constraints. As I said in my previous comment, if you have open pull requests, I can try to help give them a bit more attention if you CC me.

OK, @mystro256, you might have more insight to this than I do. This is just how it appears to me, and is largely based on the number of obvious issues that are in the build and configuration scripts for the entire ROCm stack.

For instance, the OpenCL and HIP packages, require still a whole lot of patches from the development branch, even for the latest release, as well as additional workarounds and fixes to at least get OpenCL side working. HIP is still not yet usable in Fedora - and that is after a major effort from you over the past half a year or so.

Here a list of issues/PRs which address some of the issues in the HIP packages for Fedora (and apply equally to Debian/Gentoo):

In a comment in the first issue (hipamd/#43-comment), I also describe another issue with a link to a patch in Debian. I will open a separate issue for that as requested by one of the developers.