Hacker News Reader

Comment by halotrope | Hacker News Reader

Running an ARC 770 Gpu on my linux workstation. After Nvidia messed up wayland support so badly, the switch is easy. Fully open source drivers. Everything is smooth as butter and event Pytorch, Blender etc are (experimentally) supported. Pretty great if you ask me.

View on HN

> even Pytorch, Blender etc are (experimentally) supported.

Certainly better than the joke that is ROCM support for AMD GPUs.

Yes I mean everything beta and such. But fully open source and what I saw from oneAPI they are doing all the right things recently. Let's hope that Gelsinger is to Intel what Nadella is to Microsoft.

Let’s not.

What specifically is your issue with ROCm & HIP that makes it a joke? It has actually worked great for me on both Blender and Pytorch (Stable-Diffusion) with Debian on my 6700XT.

More details in a prior comment: https://news.ycombinator.com/item?id=32908918

Extremely limited support for one. Why is it locked behind the 6000 series cards? The project has been around since the 500 series cards days and they utterly ignored the entire market for years.

What exactly is locked to 6000 series cards? I can't speak specifically to having had any old 500 series, but I was using even more ancient 400 series cards (rx480 from 2016) with ROCm for years up until recently. So I am not sure what what issue you would have with 500 series other than probably being old slow hardware, but I don't see why they wouldn't work otherwise¹.

¹ https://community.amd.com/t5/knowledge-base/amd-rocm-hardwar...

AMD doesn't support any recent consumer GPUs, and they have long-standing support issues failing to build which are sometimes only resolved a year or more after launch.

Just see this thread for an example of the frustration people feel: https://github.com/RadeonOpenCompute/ROCm/issues/887

This hasn't been an issue with day one CUDA and ML functionality on any recent Nvidia GPUs.

While AMD might not have "official" support for their consumer hardware lineup on offerings that have traditionally been a non-consumer area of GPGPU, there is plenty of evidence that it will indeed still work just fine on most of them (once compiled properly and sometimes with the right environment flags); as witnessed by me and even people in the link you reference. I agree that "official" support would be great eventually, but for me as long as it works, that's adequate enough for me on consumer hardware.

I think the thread I linked shows there is substantial frustration here, and the reason I didn't purchase a Navi card was in part due to widespread reports that ROCm was untenable on the platform.

> once compiled properly and sometimes with the right environment flags

Not interested in apologism for the corporation. If AMD wants to compete with CUDA, they have to support the consumer GPUs that are accessible to hobbyists and non-experts. This is user hostile support.

Historically Intel has the best Linux open-source drivers, with OpenCL and OpenGL support (unlike AMD ROCM which requires a custom kernel and closed-source components, and the fully closed Nvidia stack).

Unfortunately for ARC they pretty much marketed it solely for gaming applications, where the chip and drivers don't really excel in. Linux support, AV1 encoding, and so on are its strong points, not raw performance. You can argue that those things don't make as much money as the gaming market, but if Intel's beaten by the competition on the performance side they'll need to find another route to sell this.

Raw performance is not there yet but the "Max" gpus seem to be quite powerful and on par with Nvidia (on paper). Blender and also gaming (via Proton) works quite well under Linux too already which is great considering the drivers are not even fully merged into mainline yet.

Not sure what you are talking about as far as AMD?

This statement in particular:

> "unlike AMD ROCM which requires a custom kernel and closed-source components"

As far as my experience, ROCm does not require a custom kernel nor special kernel modules as it works just fine for me with stock distro kernels, nor does it require closed-source components. OpenCL and OpenGL have pretty much always worked fine for a long time now. I think that AMD drivers are just as good as Intel ones especially when it comes to how open-source they are. While it's cool that Intel already has AV1 encoding on their new cards, I fully expect AMD will have just as good AV1 encoding on their next gen RDNA 3 cards too when they come out soon.

Did some research into this and it looks like ROCM is much easier to set up now as you mention. I remember in the past it required a lot of changes to the stock system to get working, but I haven't touched ROCM in a long time.

In Fedora, the 37 release (released about two weeks ago) is the first time ever I got OpenCL working on Vega, via rocm-opencl. Until 37, rocm was not packaged at all, and the upstream packages support only Ubuntu and CentOS.

Even with 37, rocm is not complete. HIP is missing, blender doesn't work and asks for the proprietary driver (which, again, works only with Ubuntu and CentOS).

I think you have gotten to the crux of it, distro package maintainers seem to have not done a particularly good job in many distros when it comes to AMD, but that is hardly AMD's fault as they have done a fairly good job at running their own full binaries repo¹ for various package formats. I also would recommend therefore that you change to AMD's repo as it definitely contains the HIP runtime. It would appear that you just need to add https://repo.radeon.com/rocm/yum/rpm to your package manager for Fedora. For ROCm OpenCL, my only pointer is that you have to make sure that you are adding the dynamic library path, for example:

  $ env LD_LIBRARY_PATH=/opt/rocm-5.4.0/opencl/lib clinfo

I am pretty sure that you should be able to resolve both OpenCL and Blender+HIP support given your configuration details given so far and I hope you figure it out.

¹ https://repo.radeon.com/rocm

I wonder if Intel will keep providing good Linux support in the future. I read a comment on LWN saying the person responsible for that has left Intel.

I've been waiting so see a Arc GPU usage experience on Linux in HN so thank you for sharing.

Due to the first class Linux support on even Intel's IGPU, I was expecting Arc to be a great fit.

More over I don't have to sell my Kidney to buy Intel products in my country, Unlike the Red team & Green team products.

Reply on news.ycombinator.com