Re: Revisiting ROCm packaging
> Nice work! Thanks :) > The only x86 32-bit use I can think of would be wine if it supports ROCm. Yeah I looked into it, and it looks like rocm-runtime fails on 32bit due to some assumptions for 64bit in the code. I don't think there's too much value to 32bit, so it's not really worth trying to rework the code. > The answer in Fedora is usually: work with upstream to unbundle. If > ROCclr is used by more than one package then there's value in unbundling > it and making it a shared library. Same for the others. Yeah, upstream seems a bit uninterested. Last time I checked, you could build ROCclr independently as a static lib, but it's deprecated. I might try that when I have time, and then see how easy it is to convert to a shared lib. Thanks for the feedback ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Revisiting ROCm packaging
On Thursday, 07 April 2022 at 06:40, Jeremy Newton wrote: > I made a thread late last year inquirying about interest in ROCm > packaging; in that time I've introduced a few packages amd updated a > few existing packages to the latest version. Right now, Fedora is > just short of making good use of ROCm, as it needs a frontend like > OpenCL or HIP. I have a COPR where I've been experimenting on x86_64, > aarch64, and ppc64le: > https://copr.fedorainfracloud.org/coprs/mystro256/rocm-opencl/ Nice work! > I would like to know if anyone is interested in maintaining, testing, > or providing feedback on these packages. They're a bit rough around > the edges, but ultimately I don't have the ability to be a primary > maintainer for these. With that said, I encourage anyone to freely > take my work as a starting point. I would also be intested in > non-commitally helping keep packages up to date if they land in > Fedora. I would've been interested, but I'm afraid my AMD GPU is too old to be supported by ROCm (Radeon HD 7950, a.k.a. 1st GCN, Tahiti). Until I can get my hands on some newer GPU, I'm afraind there's little point in me maintaining the stack. > If you missed the original thread, I am an AMD employee, but my > involvement in Fedora and packaging ROCm in Fedora is completely > unrelated to my employment. I've been tinkering with rocm-opencl to > make it better to package and I have a few patches in my COPR that > I've been informally sharing with the developers. I didn't try to > enable 32bit OpenCL given that 32bit has been falling out of favour, > but I don't mind attempting to build it if there's a use for it. The only x86 32-bit use I can think of would be wine if it supports ROCm. > HIP has a few more complicate issues to deal with, such as this: > https://src.fedoraproject.org/rpms/clang/pull-request/156 > > I think the one thing that bugs me the most is the bundling. Both of > them bundle a static library called "ROCclr" and some older OpenCL > headers. HIP also bundles some of rocm-opencl, along with a khronos > header. If anyone is interested, I would like some feedback on how to > tackle this. The answer in Fedora is usually: work with upstream to unbundle. If ROCclr is used by more than one package then there's value in unbundling it and making it a shared library. Same for the others. Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Revisiting ROCm packaging
I made a thread late last year inquirying about interest in ROCm packaging; in that time I've introduced a few packages amd updated a few existing packages to the latest version. Right now, Fedora is just short of making good use of ROCm, as it needs a frontend like OpenCL or HIP. I have a COPR where I've been experimenting on x86_64, aarch64, and ppc64le: https://copr.fedorainfracloud.org/coprs/mystro256/rocm-opencl/ I would like to know if anyone is interested in maintaining, testing, or providing feedback on these packages. They're a bit rough around the edges, but ultimately I don't have the ability to be a primary maintainer for these. With that said, I encourage anyone to freely take my work as a starting point. I would also be intested in non-commitally helping keep packages up to date if they land in Fedora. If you missed the original thread, I am an AMD employee, but my involvement in Fedora and packaging ROCm in Fedora is completely unrelated to my employment. I've been tinkering with rocm-opencl to make it better to package and I have a few patches in my COPR that I've been informally sharing with the developers. I didn't try to enable 32bit OpenCL given that 32bit has been falling out of favour, but I don't mind attempting to build it if there's a use for it. HIP has a few more complicate issues to deal with, such as this: https://src.fedoraproject.org/rpms/clang/pull-request/156 I think the one thing that bugs me the most is the bundling. Both of them bundle a static library called "ROCclr" and some older OpenCL headers. HIP also bundles some of rocm-opencl, along with a khronos header. If anyone is interested, I would like some feedback on how to tackle this. Anyway thanks for reading :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
