How to deal with AMD's new amdgpu-installer 20.40

I’m sure I’m not the only person to have noticed this, but now that AMD isn’t providing RPMs directly, the new ‘amdgpu-install’ script is totally broken on Fedora, now. Yes, I know Fedora isn’t officially supported, but it’s been that way for 20 years, and it’s always worked, anyway.

amdgpu-install now tries to install a real yum remote repository, which sounds great, but the script produces a bad repo path, which causes the install to fail:

AMDGPU 21.40.1 repository                                            343  B/s | 178  B     00:00    
Errors during downloading metadata for repository 'amdgpu':
  - Status code: 404 for https://repo.radeon.com/amdgpu/21.40.1/rhel//main/x86_64/repodata/repomd.xml (IP: 13.82.220.49)
Error: Failed to download metadata for repo 'amdgpu': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Ignoring repositories: amdgpu
Last metadata expiration check: 0:18:33 ago on Mon 27 Dec 2021 17:14:43 PST.
No match for argument: amdgpu-lib
No match for argument: amdgpu-dkms
Error: Unable to find a match: amdgpu-lib amdgpu-dkms

Without studying the script in full, I’m not sure what is wrong, but I suspect it just doesn’t have a true code path for fedora, even though the string ‘fedora’ is in the script in a few places.

I’m going to try manually installing the RHEL8.5 repo, which should get me back to the old situation where I could at least try to install any AMD pkg I want.

Okay, maybe I am the only person to experience this. I was able to restore functionality by manually installing more packages, ignoring installation errors, and rebooting, repeatedly–same as always. There seems to be no way to tell what are required and what are not. What a nightmare. Will this pain ever end?

I’ve just found out that problem is in repo link in these files
/etc/yum.repos.d/amdgpu-proprietary.repo
/etc/yum.repos.d/amdgpu.repo

script doesn’t defines $amdgpudistro variable. I fixed link locally - replaced $amdgpudistro with “8.5”. After replacement amdgpu-install works fine. Running fresh Fedora 35

You seem to be installing on fedora but the “8.5” refers to a RHEL version. Guess that the problem is due directly to using 3rd party repos, since the variable you noted ($amdgpudistro) is not set by dnf in fedora and the amdgpu repos seem to use something other than the fedora distro naming for the installation.

What is the actual URL for the installer to use for downloads? (from those repo files)

1 Like

Tengo ese mismo problema.
vengo de Debian 11 y allí funcionaba correctamente mi tarjeta gráfica AMD RX570
con drivers de propietario AMG GPU PRO, resulta en fedora me devuelve que el link está reportado exploro el sitio y cambio de ubicación y están los archivos RPM pero a pesar que se instala 1 por uno no me acepta.
espero con ansias alguna solución

1 Like

Please, when posting in the ‘Ask in English’ forum use the english language. If you wish to use spanish then please post in the ‘Ask in Espanol’ forum so the users are all able to read and reply in your language of choice.

Also, if this is a new problem for you please start your own thread so it gets the attention it deserves and can be easily found when searching.

Hmm, interesting questing. I put:
https://repo.radeon.com/amdgpu/21.40.1/rhel/8.5/main/x86_64

But, that isn’t right, because it doesn’t get updates. There is a ‘latest’ directory, and I think that is probably what we should use:
https://repo.radeon.com/amdgpu/latest/rhel/8.5/main/x86_64/

AMD, to my knowledge, has never supported Fedora for amdgpu-pro and whenever I’ve tried to install it on Fedora, it’s always been a very messy process that broke on the next kernel update. This is unfortunately a very real pain point for Radeon graphics that otherwise work wonderfully out of box on Fedora. As these are proprietary from AMD, there’s also not much of anything that can be done about it on the Fedora side. I would love for this to change so I could contribute more to BOINC projects like World Community Grid via OpenCL with my powerful RX cards. The best thing you can do is contact AMD support and hope that they’ll hear us.

I’m not talking about their proprietary drivers; I’m talking about their OSS support. -pro works just like it does in Windows and no better on that platform than on Linux, so I don’t really care what they do over there. I’m talking about the stuff they keep promising to deliver, but always seem to fall short. You do not need -pro to crunch for BOINC, now or ever.

I’ve been crunching for BOINC for 22 years. And for the last 10 years, maybe more, I’ve been doing it with ATi/AMD GPUs. In the beginning, OpenCL just worked, no extra drivers necessary. Then it became necessary to install Catalyst, or at least I though it did, and that was about 4 years of my life I’ll never get back. Then there was another period where the OSS OpenCL worked without any extra AMD pkgs. But, since AMDGPU, it’s generally worked fine without -pro, and that is by design. (Contrast this with NVidia, where their drivers are required even for the desktop because nouveau lacked a lot of features–from what I gather, I only read stuff in passing about team green <boooo!>.)

The trouble is that the installer sucks, has always required root priv, and the documentation is terrible. But, there is nothing to tell AMD because they are always saying the right things in public about their support for the OSS community, and they make new commitments to bring new feature support to the OSS stack every year. I just wished they would contribute more, quicker.

It’s true, they have always excluded Fedora from the list of “supported” distros. But, they include plenty of RPM-based distros and they’re just being obstinate about it. Also, the “support” isn’t very good, so I fail to see what we are loosing by not having a case statement in the terrible installer just for Fedora. The RPM dependencies are all messed up, so you get this problem of trying to figure out what you need without any documentation. But, you have that same issue on any distribution.

The last few years have been pretty good. They have real RPMs for RH, which they didn’t in the beginning. But, now, without telling anyone, they actually have an RPM repo that will get updates. Why is it so hard to explain what they are doing?

I’m thrilled that I found this repo, today. I swear I checked for it before and I don’t remember finding the ‘latest’ directory back then. Anyway, this is another incremental step in the right direction. Now, after you get the right pkgs installed, which is trouble, you can at least update them like any normal RPM! Big milestone.

1 Like

NO NO NO!

So, I tried to update my system and everything broke. Firefox wouldn’t even start. OMG, AMD, you drive me insane. I had to unstall AMDGPU. I’ll try to start all over again. Maybe 21.50 doesn’t work on F35.

Well, there goes another 5 hours of my life. Just after I gave AMD praise, too. They got me again! I have no one to blame but myself, I guess. I really shouldn’t keep falling for it.

So, that “update” idea didn’t work at all. I finally got my system back and, as usual, it was so difficult that I don’t even remember how I ended up fixing it.

I did learn one thing very useful, though: it took way fewer packages than I had installed the last several times I did this. Check this out:

amdgpu-dkms.noarch                                1:5.13.11.21.50.50000-1373477.el8       @amdgpu-prd
amdgpu-dkms-firmware.noarch                       1:5.13.11.21.50.50000-1373477.el8       @amdgpu-prd
amdgpu-pro-core.noarch                            21.50-1373477.el8                       @amdgpu-proprietary
ocl-icd-amdgpu-pro.x86_64                         21.50-1373477.el8                       @amdgpu-proprietary                                                                                             

So, here’s one thing to watch out for: if you have amdgpu-install pkg installed, upgrading it will recreate your /etc/yum.repos.d/files, destroying any modifications you made to make the damn thing work in the first place. So, hint #1: build your own repo files so amdgpu installer cannot mess them up.

Also, it doesn’t look like you need amdgpu-install for exactly the reason I sited before: You’re better of without it! Hint #2: DO NOT INSTALL AMDGPU-INSTALL. Pretty much the worst thing you can do is follow AMD’s instructions. I think amdgpu-install is now worse than it has ever been for Fedora. It used to limp a long and work with some cheating, but not anymore.

So, here’s something else: when I finally gave up and decided to start over, I ran amdgpu-install --uninstall…but that failed, of course, and left me with a bunch of installed pkgs. I used dnf’s reporting of the install repo to find everything and back out. That’s Hint #4 if you didn’t already know about it.

Finally, I don’t even think the amdgpu-dkms pkgs do anything. Boot just throws a bunch of errors about them. So, I uninstalled them, and they didn’t affect the other pkgs. So, after all that pain, all I needed was TWO packages???

Oh, also, the gpg repo keys are in the amdgpu-install pkg. So, I guess you can either disable that for your repos or install it, copy the keys, and then uninstall it??? Whatever. I’ll fix it later. Need sleep.

1 Like

Ranting Section

Okay so, I can’t stop picking at this…

I managed to mess it up, again, but recovered by reinstalling some installed packages. So here is my MWE for amdgpu 21.50:

$ sudo -i dnf list installed '*amdgpu*' '*rocm*' '*roct*' '*hsa*' | grep -v 'procmail|setproctitle'
Installed Packages
amdgpu-pro-core.noarch       21.50-1373477.el8           @amdgpu-proprietary-prd
hsa-rocr.x86_64              1.5.0.50000-49.el8          @rocm-prd              
hsakmt.x86_64                1.0.6-17.rocm3.9.0.fc35     @fedora                
hsakmt-roct-devel.x86_64     20211222.1.5.50000-49.el8   @rocm-prd              
ocl-icd-amdgpu-pro.x86_64    21.50-1373477.el8           @amdgpu-proprietary-prd
rocm-core.x86_64             5.0.0.50000-49.el8          @rocm-prd              
rocm-ocl-icd.x86_64          2.0.0.50000-49.el8          @rocm-prd              
rocm-opencl.x86_64           2.0.0.50000-49.el8          @rocm-prd              
rocm-runtime.x86_64          3.9.0-2.fc35                @fedora                
rocminfo.x86_64              3.9.0-2.fc35                @fedora                
xorg-x11-drv-amdgpu.x86_64   21.0.0-1.fc35               @fedora

But, that doesn’t tell the whole story. Consider these confusing factors:

  • There are no pkgs installed from the non-proprietary repo. That makes no sense at all, right? I’m trying to use the non-pro stack. Why are the pkgs I need both labelled ‘-pro’.
  • dnf tried to install amdgpu-core, but it failed, but that’s always been true, since amdgpu-core pkg was first introduced.
  • one of the most critical files is libamdocl64.so…but that’s not in amdgpu-pro-core
  • amdgpu-pro-core has only one file, the EULA agreement. Gee, thanks a lot.
  • libamdocl64.so is actuall in rocm-opencl
  • But, rocm-opencl is not a dependency of any other installed pkg!
  • Also, file /etc/ld.so.conf.d/10-rocm-opencl.confis required to get linking work. It points /opt/rocm-5.0.0/opencl/lib which contains libamdocl64.so
  • BUT no package owns /etc/ld.so.conf.d/10-rocm-opencl.conf! So, I have no idea what pkg install created it or how. Why would a package create a simple file with a script instead of just delivering the file?
  • Also, there are two copies of libOpenCL.so.1.2. I think one is for ROCm-based access to OpenCL and one is for, uh, normal OpenCL?
    /opt/rocm-5.0.0/opencl/lib/libOpenCL.so.1.2
    /opt/amdgpu-pro/lib64/libOpenCL.so.1.2
  • I don’t know if the ROCm stuff is strictly necessary for what I’m doing with OpenCL. ROCm seems critical from the way AMD talks about it, but that might be marketing. But, my system did seem to break when I uninstall it.

Arrgh!!!

What I learned: How to get OpenCL to work without installing AMDGPU-PRO (21.50)

  1. I suggest installing amdgpu-install, first. It will install some .repo files and the gpg key for those repos.
  2. Copy all of those and make your own .repo files with them; you have to have different names. It took some time, but now my repo configs are nice and clean, and I can install/remove pkgs from the remote repos.
  3. Then, uninstall amdgpu-install; it will delete the .repo files.
  4. Then, install
    amdgpu-pro-core
    ocl-icd-amdgpu-pro
  5. Now, check you configuration with clinfo. I know if my system is working when there are 2 “plaforms” detected. One is old OpenCL/Mesa/Clover and doesn’t work (although it should, it used to), and the other one is newer OpenCL and says “AMD-APP ([version])”, where [version] is what changes when you get an update. It’s worth keeping track of this!
  6. If you are lucky, in the future, try dnf update ??

So, because of this recent disaster, upgrading with dnf is still untested on Fedora. I suppose I could go back and test, but…no. I will report back here after then next release.

More about clinfo and why things are so difficult

The clinfo that comes with rocm (/opt/rocm…/) doesn’t give any errors. But, the default clinfo that is part of the base Fedora distro might give an error like this:

fatal error: cannot open file '/usr/lib64/clc/gfx1010-amdgcn-mesa-mesa3d.bc': No such file or directory

This is the reason the old OpenCL “platform” doesn’t work anymore. But, AFAIK, this is only a problem with NAVI10 (gfx1010/5700XT) GPUs. This missing file is the “secret sauce” that Mesa hasn’t been able to include, but is included for other, older cards, and is known to work without any extra amdgpu packages from AMD. It may also be a problem for the latest gen (6800s); I don’t have one to test. :frowning: But, don’t assume you need extra AMDGPU stuff to make OpenCL work; it didn’t used to be like this!

1 Like

Okay, here we go! Looks like some admgpu packages were updated in the ‘…/latest/…’ RHEL 8.5 RPM repository. DNF seems to be doing the right thing by identifying them as updated, automatically. I’ll update and reboot and see how it goes…

Hey, I think it worked. I installed the new pkgs from the AMD repo (manual repo config) with many other system updates and…no problems detected.

$ sudo -i dnf list installed '*amdgpu*' '*rocm*' '*roct*' '*hsa*' | grep -v 'procmail|setproctitle'
Installed Packages
amdgpu-pro-core.noarch       22.10-1395274.el8           @amdgpu-proprietary-prd
hsa-rocr.x86_64              1.5.0.50100-36.el8          @rocm-prd              
hsakmt.x86_64                1.0.6-17.rocm3.9.0.fc35     @fedora                
hsakmt-roct-devel.x86_64     20220128.1.7.50100-36.el8   @rocm-prd              
ocl-icd-amdgpu-pro.x86_64    22.10-1395274.el8           @amdgpu-proprietary-prd
rocm-core.x86_64             5.1.0.50100-36.el8          @rocm-prd              
rocm-ocl-icd.x86_64          2.0.0.50100-36.el8          @rocm-prd              
rocm-opencl.x86_64           2.0.0.50100-36.el8          @rocm-prd              
rocm-runtime.x86_64          3.9.0-2.fc35                @fedora                
rocminfo.x86_64              3.9.0-2.fc35                @fedora                
xorg-x11-drv-amdgpu.x86_64   22.0.0-1.fc35               @updates               
$ clinfo                                                             
Number of platforms                               2                     
  Platform Name                                   AMD Accelerated Parallel Processing
  Platform Vendor                                 Advanced Micro Devices, Inc.
  Platform Version                                OpenCL 2.1 AMD-APP (3423.0)
...

I guess I should update the solution to this thread, now that I have been able to confirm that, at least for the most recent update, AMD’s public RPM repository can be made to work as expected.

Start here if you don’t have a copy of AMD RPM GPG signing key AND/OR you don’t want to create the RPM repository config files from scratch

  • Temporarily install amdgpu-install
  • Make a copy of all the new dnf/yum repo files in /etc/yum.repo.d for yourself.
  • Make a copy of the AMD RPM GPG signing key referenced by the gpgkey key in those repo files. You’ll need it for later. A good place to put it might be /etc/pki/rpm-gpg/ with all your other ones.
  • Uninstall amdgpu-install

Skip to here if you have a copy of AMD RPM GPG signing key AND you don’t need any help creating remote RPM repository configurations

  • Define your own remote RPM repository config files (/etc/yum.repos.d/) (or use the ones amdgpu-install installs as a guide from above) for each of the following:
    – amdgpu-[foo]
    – amdgpu-pro-[foo]
    – rocm-[foo]
    where [foo] is some string that differentiates your manually defined remote repositories from the ones amdgpu-install created. This is all so that it will not break when we uninstall it, or if you ever have to install amdgpu-install, again, it will not overwrite or ruin what you have done.
  • change the baseurl key configured for your new remote repos to point to the URL that will get updates, instead of the one amdgpu-install created, which points to a URL for just that specific version of amdgpu. (I know, it’s so crazy that it doesn’t make sense when you write it out.) There is still a different URL for each distribution, though. For F35, for example, I figure CentOS8 or RHEL/8.5 is the closest match, so, I used:
    amdgpu:https://repo.radeon.com/amdgpu/latest/rhel/8.5/main/x86_64
    amdgpu-pro:https://repo.radeon.com/amdgpu/latest/rhel/8.5/proprietary/x86_64
    rocm:https://repo.radeon.com/rocm/centos8/rpm
    The key is the part of the URL that is ‘…/latest/…’; that’s all we are really achieving by doing all this. For rocm, there isn’t a ‘latest’, but whatever. Make sure the URL you are specifying exists using a web-brower or curl or something.
  • Update software package cache. I assume this works from GNOME Software, but I didn’t test. I used sudo -i dnf makecache. That should list the new repositories you created and fetch the available packages. If it’s working, you can now browse the remote repository however you like.
  • install just the packages you want. I still don’t know what is MWE. I think you just need ocl-icd-amdgpu-pro (and it’s dependencies), but I found ldd was linking to a .so in rocm-opencl, so I’m leaving that installed, plus it’s dependencies. I don’t think you really need any HSA stuff.
2 Likes

Epilogue: Forget AMDGPU-PRO, You Only Need ROCm

I don’t think what I wrote above is “wrong”, but I now realize it’s not quite accurate. Here’s what I recently learned.

  • The above methods works fine; it will install a working OpenCL for AMDGPU. And I still think it’s worth the trouble if you want to have all the AMD repositories setup without amdgpu-install (which does not work on Fedora).
  • But, you could skip all that! You only need the ROCm repo (Index of /rocm/centos8/rpm/), which you can set up yourself, manually, without messing with amdgpu-install at all! The GPG key for those RPMs is downloadable, and you can just create a .repo file using any example you find. All you need to know is the following (and name it something unique, like myrocm)
    baseurl=https://repo.radeon.com/rocm/centos8/rpm/
    – gpgkey: https://repo.radeon.com/rocm/rocm.gpg.key
  • And, you don’t need (the old) OpenCL pkgs anymore! I mean, you need OpenCL support, but not the old packages. AFAICT, there is no direct support for OpenCL on AMDGPU for “newer” cards (i.e. Navi10+). A direct OpenCL layer only exists for cards prior to AMD Navi10. (Also, no MESA support, see below.)
  • New cards, meaning Navi10 and newer, provide OpenCL interface on top of ROCm, not directly.
  • So, you don’t need the “old” opencl pkgs with which you are familiar. By “old” OpenCL pkgs I mean amdgpu-core, ocl-icd-amdgpu-pro, and dependencies. This is great news, because those old pkgs had kernel dependencies and amdgpu-core would always fail to install. But, you don’t need it anymore!
  • What you really need is the ROCm-based OpenCL stuff: rocm-language-runtime, rocm-opencl-runtime, & rocm-ocl-icd (and deps)

My Working (AMD-supplied) PKG List

So, now, I have OpenCL working without any of the packages I used to think were absolutely essential. The world is changed!

Installed Packages
hsakmt-roct-devel.x86_64         20220128.1.7.50100-36.el8           @rocm-prd  
rocm-core.x86_64                 5.1.0.50100-36.el8                  @rocm-prd  
rocm-language-runtime.x86_64     5.1.0.50100-36.el8                  @rocm-prd  
rocm-ocl-icd.x86_64              2.0.0.50100-36.el8                  @rocm-prd  
rocm-opencl.x86_64               2.0.0.50100-36.el8                  @rocm-prd  
rocm-opencl-runtime.x86_64       5.1.0.50100-36.el8                  @rocm-prd  

(You also need some official, Fedora pkgs, which are dependencies of these, but I didn’t show them.)
And, I’m sure you don’t need -devel either.

More about OpenCL and why things are so difficult (Continued)

  • Also, I was wrong about Mesa support; it’s not just NAVI10 that doesn’t work, it’s all “new” cards. The 6800XT needs gfx1030 mesa3d.bc data, which is missing, just like gfx1010 was missing for the 5700XT. I think these don’t exist anymore in part because support is moved to ROCm. Rather than helping MESA OSS, AMD is just doing it through ROCm, which is their OSS platform. I thought it was some kind of mistake and that MESA support would return, but now I think I understand why it never materialized for NAVI10. So, things are making a lot more sense, now.

Caveats: There are still problems

So, there are problems still to be fixed. You might want to install some ROCm packages that you can’t, due to Fedora/AMD packaging disagreements. Many of the new ROCm pkgs for Centos8 (which are the same as for RHEL8) require /usr/libexec/platform-python, which is depricated, AFIAKT, and Fedora has appropriately removed it since RHEL8 was introduced. This affects many of the packages that the install documentation for ROCm (see below) discusses, like HIP, ML, & OpenMP runtimes for ROCm. These are cool for programming, but are not necessary for getting compiled OpenCL programs to work over ROCm. So, not a problem unless you want to write or build code.

But, even here, there is hope. This issue about /usr/libexec/platform-python goes back to Python 2.7, so it’s old. And, I see an empty stub for RHEL9 (Index of /rocm/rhel9/) already on the ROCm RPM repo server. So, fingers crossed, we’ll get to install these pkgs when AMD publishes them for RHEL9, which, presumably, will have not just newer Python, but the Python pkgs built for Fedora that we are using now. So, there’s a chance that, as long as Fedora doesn’t go too far ahead, RHEL9 will be sufficiently like Fedora on launch that we’ll get to use those pkgs.

Background

I had a bit if a scare when I replaced my 5700XT with a 6800XT. I was supper excited because it seemed to be crunching BOINC Einstein@Home tasks very fast, but then I playing a game on it, which crashed, and, when I came back the next day, I noticed that all BOINC GPU tasks were running to completion but finishing with an “compute error” code. I freaked out, thinking there was something wrong with the whole setup. I removed amdgpu-opencl pkgs and went searching online for how it’s supposed to work, again, which I do every so often, and I can never figure it out. Well, after rebooting, I noticed that clinfo showed I still had a working OpenCL “platform”! This got me thinking in the right way, finally. I went to the ROCm page and started reading the install docs. Look what I found:


So, what you see is that there is the rocm-langauage-runtime layer interfacing all kernel layer communication, and you see an OpenCL layer on top of that, plus there exits an rocm-ocl-icd. So, that makes sense; that is now it works, now, and that’s how your OpenCL programs can work without anything like amdgpu-opencl-.

You might find these links useful for more information:

https://docs.amd.com/bundle/ROCm_Installation_Guidev5.0/page/Meta-packages_in_ROCm_Programming_Models.html#_ROCm_Package_Naming
https://docs.amd.com/bundle/ROCm_Installation_Guidev5.0/page/Overview_of_ROCm_Installation_Methods.html

Full Circle: What’s with amdgpu-install?

I think what I learned is a net positive for the Fedora community. ROCm seems to be making life easier for us because it exits as another layer of indirection. It looks like we don’t even need to mess with amdgpu-install any more…at least not for a while. I recommend upgrading to a NAVI10+ card for this reason.

1 Like

Yet More Epilogue

Today, I noticed that some ROCm stuff got update…but not from the AMD RHEL 8 repo. They came directly from Fedora ‘updates’ repo!

So, now my system is in some type of hybrid state. I don’t like it, but so far, no issues to report. Although, I just rebooted so that could be misleading.

I’m reporting this here because I don’t even think I need any stuff from AMD’s repo any more. I didn’t try removing any pkgs, but I think I could. I now have rocm-runtime, rocminfo, and rocm-opengl pkgs from Fedora, offical-like. I think this is another good sign. I checked, and I don’t see those pkgs in the ‘fedora’ repo, they only exist in ‘updates’, so I don’t think I missed them before when I upgraded to F36.

$ sudo -i dnf list installed "*rocm-*" rocminfo "*hsa*" "*hip*"
Installed Packages
hsa-rocr.x86_64                                                        1.5.0.50200-65.el8                                                    @rocm-prd
hsa-rocr-devel.x86_64                                                  1.5.0.50200-65.el8                                                    @rocm-prd
hsakmt.x86_64                                                          1.0.6-23.rocm5.2.0.fc36                                               @updates 
hsakmt-roct-devel.x86_64                                               20220426.0.86.50200-65.el8                                            @rocm-prd
rocm-comgr.x86_64                                                      5.2.0-1.fc36                                                          @updates 
rocm-core.x86_64                                                       5.2.0.50200-65.el8                                                    @rocm-prd
rocm-device-libs.x86_64                                                5.2.0-1.fc36                                                          @updates 
rocm-language-runtime.x86_64                                           5.2.0.50200-65.el8                                                    @rocm-prd
rocm-ocl-icd.x86_64                                                    2.0.0.50200-65.el8                                                    @rocm-prd
rocm-opencl.x86_64                                                     5.2.0-1.fc36                                                          @updates 
rocm-runtime.x86_64                                                    5.2.0-1.fc36                                                          @updates 
rocm-smi.noarch                                                        4.0.0-5.fc36                                                          @fedora  
rocminfo.x86_64                                                        5.2.0-1.fc36                                                          @updates 

I think I’m okay, at least until the AMD and Fedora repos get out of sync; if AMD’s repo updates rocm-opencl but fedora doesn’t, I’m guessing DNF will overwrite the fedora pkgs with newer ones from AMD, which could be less compatible. I’d like to stick with fedora ones, assuming they’re going to keep them updated.

However, I checked for any “hip” stuff or “hsa” stuff from fedora, and there’s nothing. So, that’s still an issue yet to be resolved. But for pure OpenCL…I think AMD is actually doing it completely the right way and Fedora is supported???

I would (temporarily maybe) disable the ‘rocm-prd’ repo and see what happens with updates.

Fedora does not usually release packages that still depend upon a 3rd party repo. They also do not arbitrarily release packages that do not have a maintainer to keep them up to date. It seems likely that the packages (I see 7) that came from fedora are all that are needed. The others that have names ending in .el8 are probably superfluous and could be removed

Right, that was my conclusion, too. But, that doesn’t make sense, since these packages are completely new, so, does that mean F36 was incomplete when released? The changelog shows July 5 was the first rocm-opencl pkg for fedora.

It makes sense to not let these packages update from AMD’s official RHEL8 repo, but, on the other hand, we are desperate for a HIP RPM that is compatible with F36.

Hmm, I checked, and now, there are actually RPMs in the AMDGPU RHEL9 repo, new pkgs updated yesterday. But, still no rocm RHEL9 files. I think that’s what we are waiting for. Or, maybe we’ll get the other pkgs + hip in the near future. Fingers crossed!

Actually it does make sense.

Fedora always lags a bit behind the upstream source of packages, and they also tend to repackage things in a way that makes sense to the people at fedoraproject.

Sometimes upstream packages may be combined to fewer packages or may be split into more pieces depending on how it fits into the OS. The intent seems to be to make things just fit with less redundancy and to not overwrite already existing libraries/files (which could break something else). Package dependencies handle that.