Announcement

Collapse
No announcement yet.

Fedora Developers Look At Packaging Up The Radeon Open Compute Stack (ROCm)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • nanonyme
    replied
    Originally posted by bridgman View Post
    Yeah, I hate the idea of having binaries in different places depending on who builds them. If everyone thinks that putting our AMD-built binaries in /usr/local would be OK then I would prefer to always use that location instead.
    That sounds fine to me if you're not using the native packaging system of that distro. If you are, then totally directly under /usr.

    Leave a comment:


  • schwarzman
    replied
    Originally posted by bridgman View Post
    Yeah, I hate the idea of having binaries in different places depending on who builds them. If everyone thinks that putting our AMD-built binaries in /usr/local would be OK then I would prefer to always use that location instead.
    Personally I think /opt is better for 3rd party packages. However I don't care much because I don't use 3rd party packages from vendors often - I really prefer distro-supplied packages. These are usually easier to work with even if I have to rebuild them to apply a few extra patches.

    Tom Stellard now works for Red Hat and did some initial packaging of ROCm for Fedora. How about working with Tom+Fedora to see what issues distros are having with the ROCm build process? For example Tom mentioned that "hcc" is hard to package and he is waiting for HIP to drop its hcc dependency (if I understood him correctly). Bonus points if you could set up some wiki page (somewhere in the ROCm github repo pages?) where distro issues/missing mainline patches are listed so other distros get a bit of help as well.

    Other than Fedora maybe you should also approach Ubuntu/Debian. When Fedora+Debian are able to package ROCm this should mean all major issues have been resolved and other distros should be able to use their scripts as a blue print.

    I know that reaching out to big communities is not easy but I think there is a lot of interest on using Tensorflow with distro-supplied packages. IMHO having distro-supplied packages would be huge deal and worth a LOT of marketing dollars. Hopefully you can make a point internally to get some AMD funding. This can really be a chance to counter the argument "everyone is using CUDA -> need to buy Nvidia".

    Leave a comment:


  • bridgman
    replied
    Yeah, I hate the idea of having binaries in different places depending on who builds them. If everyone thinks that putting our AMD-built binaries in /usr/local would be OK then I would prefer to always use that location instead.

    Leave a comment:


  • zxy_thf
    replied
    Originally posted by bridgman View Post

    I thought the general rule was that packages built by the system administrator (or distro packager ?) usually went in /usr/local while binaries pre-built by a third party (like us) were supposed to go in /opt. Agree that we should be supporting both though, and I think there is some active discussion going on in those two pull requests.
    It seems not every application follows this rule.
    afaik Matlab, Wolfram Mathematica and CUDA installed themselves to /usr/local (and I'm fine with it so I could keep / minimal and leave /usr as an independent large partition).
    Meanwhile Google Chrome(!), Houdini, and Adobe Reader (not sure) use /opt.

    Leave a comment:


  • pal666
    replied
    Originally posted by bridgman View Post
    I thought the general rule was that packages built by the system administrator (or distro packager ?) usually went in /usr/local while binaries pre-built by a third party (like us) were supposed to go in /opt.
    correct with emphasis on "built by". when distro builds package from your sources, they have to go to different location. so build system has to accommodate this

    Leave a comment:


  • bridgman
    replied
    Originally posted by chithanh View Post
    If AMD had invested the work they did on the fragile "distro_install_scripts" instead into getting their CMake build into good shape, maybe that would have happened already.
    Sure, but the two are not interchangeable. The distro install scripts were written primarily for workstation drivers which are not a candidate for distro integration anyways.

    Leave a comment:


  • chithanh
    replied
    Originally posted by zxy_thf View Post
    (Last time I see a package installed to /opt is Intel's icc...)
    I remember Oracle JDK. Or Adobe Flash plugin. But these are not fond memories.

    Originally posted by bridgman View Post
    Until very recently our top priority was getting upstream kernel drivers caught up with our internal trees... without that we weren't going to get into distros anyways... but now that is largely done I think you will see a lot more focus on making the code easy to include in distros.
    If AMD had invested the work they did on the fragile "distro_install_scripts" instead into getting their CMake build into good shape, maybe that would have happened already.

    Leave a comment:


  • aiomix
    replied
    Really interesting, does this give hope for davinci resolve to works on fedora with AMD GPU?

    Leave a comment:


  • RahulSundaram
    replied
    Originally posted by bridgman View Post

    I thought the general rule was that packages built by the system administrator (or distro packager ?) usually went in /usr/local while binaries pre-built by a third party (like us) were supposed to go in /opt. Agree that we should be supporting both though, and I think there is some active discussion going on in those two pull requests
    Your understanding is correct. Regardless of licensing, third party tools can default to using /usr/local or /opt. As long as the locations are easily modifiable to support distribution defaults, that's fine.

    Leave a comment:


  • bridgman
    replied
    Originally posted by zxy_thf View Post
    Sounds like ROCm was designed as a property package and still not completely migrated away from this.
    (Last time I see a package installed to /opt is Intel's icc...)
    I thought the general rule was that packages built by the system administrator (or distro packager ?) usually went in /usr/local while binaries pre-built by a third party (like us) were supposed to go in /opt. Agree that we should be supporting both though, and I think there is some active discussion going on in those two pull requests.

    Until very recently our top priority was getting upstream kernel drivers caught up with our internal trees... without that we weren't going to get into distros anyways... but now that is largely done I think you will see a lot more focus on making the code easy to include in distros. Thanks for helping to push this along... I'll make sure the importance of these changes is understood and prioritized.

    Leave a comment:

Working...
X