5 ms·

In 2017, when I got Vega, OpenCL didn't work yet. Today, in 2023, Vega is already not supported. Meanwhile, during this period, ROCm was unbuildable by mere m

In 2017, when I got Vega, OpenCL didn't work yet. Today, in 2023, Vega is already not supported. Meanwhile, during this period, ROCm was unbuildable by mere mortal distribution maintainers; you either used the binaries thrown over the wall by AMD (for specific versions RHEL/Centos, SuSE and Ubuntu only), or didn't run anything at all. Also in 2023, Fedora managed to package basic ROCm packages for Fedora 38; I can finally run darktable and blender (but it is crashing!) on Vega. Woohoo!

a-french-anon 3y ago
Support for Gentoo existed for a long time in https://github.com/justxi/rocm https://github.com/justxi/rocm before being merged in the main Portage tree.
- AstralStorm 3y ago
  By existed you mean maybe built and sometimes worked. That's not support. That's throwing things over the wall. More importantly, even with Vega it had numerous crashes. Anything else, like Polaris or RDNA? Forget about it. Even the AMD docker setups weren't quite good enough at times.
  - a-french-anon 3y ago
    No I know, but pretending it was so hard to build it could be considered as good as closed sourced isn't needed to shit on it.
    - vetinari 3y ago
      It is hard to build. AMD uses cpack deb/rpm generators; and the build process requires random things in path (some built from git checkouts of other projects). If you want to create standard deb or rpm build script for building in distro build infra, or inside mock, for rpm-based distributions, the cmake build actively makes steps to make it as difficult as possible. There used to be a talk titled something like "How to make distribution maintainers hate you" (I cannot find a link to in now); it seems that ROCm developers have seen it, took it to their hearts and then wrote several new chapters themselves. That's building. Do not even think about testing. There's a reason why it took distributions years to package it (still not done completely). The upstream project was like student projects, thrown over the wall once students stopped working at it, including the build "system".
hedgehog 3y ago
We didn't use ROCm, the non-ROCm OpenCL path worked fine for us on Polaris and Vega. None of this is a major reason AMD cards are vastly inferior for ML dev and research purposes. At the time they made a decision not to invest heavily in ML framework and workflow support, and so they never had a product really usable for those applications. I find it annoying they didn't do more but I'm not sure they were wrong. AMD managed to tread water in GPUs, integrate Xilinx, and go from meh to a very strong position on CPUs, and all of that with a relatively small company.

a-french-anon 3y ago

Support for Gentoo existed for a long time in https://github.com/justxi/rocm https://github.com/justxi/rocm before being merged in the main Portage tree.

AstralStorm 3y ago
By existed you mean maybe built and sometimes worked. That's not support. That's throwing things over the wall. More importantly, even with Vega it had numerous crashes. Anything else, like Polaris or RDNA? Forget about it. Even the AMD docker setups weren't quite good enough at times.
- a-french-anon 3y ago
  No I know, but pretending it was so hard to build it could be considered as good as closed sourced isn't needed to shit on it.
  - vetinari 3y ago
    It is hard to build. AMD uses cpack deb/rpm generators; and the build process requires random things in path (some built from git checkouts of other projects). If you want to create standard deb or rpm build script for building in distro build infra, or inside mock, for rpm-based distributions, the cmake build actively makes steps to make it as difficult as possible. There used to be a talk titled something like "How to make distribution maintainers hate you" (I cannot find a link to in now); it seems that ROCm developers have seen it, took it to their hearts and then wrote several new chapters themselves. That's building. Do not even think about testing. There's a reason why it took distributions years to package it (still not done completely). The upstream project was like student projects, thrown over the wall once students stopped working at it, including the build "system".

hedgehog 3y ago

We didn't use ROCm, the non-ROCm OpenCL path worked fine for us on Polaris and Vega. None of this is a major reason AMD cards are vastly inferior for ML dev and research purposes. At the time they made a decision not to invest heavily in ML framework and workflow support, and so they never had a product really usable for those applications. I find it annoying they didn't do more but I'm not sure they were wrong. AMD managed to tread water in GPUs, integrate Xilinx, and go from meh to a very strong position on CPUs, and all of that with a relatively small company.