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.
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.
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¹.
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.
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.
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.
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.
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:
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.
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.
Your comment suggests ignorance on three fronts. First, you're suggesting that because Wayland is a "super-process" of Xorg, it has no value or purpose. This is not accurate, as Wayland may offer certain advantages over Xorg, such as improved performance or greater security.
Second, you're implying that because Wayland is a newer display server, it lacks the software support that Xorg has. This is not the case, as many popular Linux applications and desktop environments now support Wayland (Firefox, GNOME, Gimp, LibreOffice) and more are being added all the time.
Third, you're suggesting that Wayland is built on top of Xorg and is not distinct from it. Wayland and Xorg are two different display servers, that have two completely different architectures.
Also, there are many reasons why parent would want to use Wayland: it's supposedly more secure, and lighter to run.
Chrome, Firefox, Emacs. (And because of Chrome you get the long tail of electron apps.) It's quite rare that I use an xwayland applications anymore.
Getting multiple monitors of different resolutions to display content nicely is literally impossible on X, so I've been very happy with the improvements since moving to Wayland.
I have a dual monitor setup, with one 1440 and a ultra wide 2560x1080, and I don't have any issues with X11. It just works out of box. Something that I can't say of Wayland crashing every time that I try it.
Different scaling ratios in X11 do not work - period. You can define different ratios per monitor, but application windows will take the scale of the monitor they open on and never change.
Most distros are now on Wayland by default for a reason.
Gnome support is excellent.
Sway support is excellent.
KDE support is... not as excellent, but still pretty good at this point.
Ubuntu 21.04+ is on Wayland by default.
Fedora 35+ is running Wayland by default (minus KDE, where they default to x11 still, but ship a plasma-wayland session).
OpenSUSE Leap 15+ is running Wayland by default.
Debian Buster+ is running Wayland by default.
Garuda is running Wayland by default.
Manjaro Sway & Gnome are Wayland by default (again KDE is not - but the plasma-wayland session is included).
Basically - Wayland is not "the future" anymore. It's the "Right fucking now" across basically every major distro. Even KDE based distros are discussing moving to plasma-wayland by default at this point, since it's improved a lot in the last two years.
Which mostly just works as long as you have Pipewire and xdg-desktop-portal-kde installed (the base plasma-wayland session usually includes them)
This one is a bit less polished - some users still have problems with keyboard input, depending on the distro and other installed packages.
For Sway:
xdg-desktop-portal-wlr works just fine for screen sharing, and you can use https://github.com/any1/wayvnc for VNC access (including having a completely headless machine).
It's... not X... why would it do X forwarding? that's like criticising windows for not doing X forwarding (there's enough stuff to criticise windows about as it is, there's no need to add imaginary things to it).
I think what's really meant here is different pixel densities -- e.g. a high-dpi laptop screen and a low-resolution external monitor. I'm not sure exactly how Wayland handles this, but X doesn't do a very good job.
Correct, I should have said a mixture of HighDPI screens, and non high-dpi screens rather than mentioning resolution. Thanks for the clarification.
What I used to have on X was one model with 2x the pixel density as another. You either have things being tiny on one, and massive on the other or vice versa. What I did for a while was configure everything to be halfway between them so everything would be just _slightly_ off on both, but it was kind of horrible (and made the fonts look terrible).
Chrome does default to x11, but it is easily changeable via chrome://flags.
With other electron apps, it depends. Some are easy, some are not. The notably difficult one is vscode, which handles its args itself, ignores (electron|chromium)-flags.conf and processes the cmd line flags only after the electron framework is initialized (thus the ozone flags having zero effect).
As vetinari says (you can also put chrome config in ~/.config/chrome-flags.conf).
He also pointed out quite rightly, that it very much depends on the version of electron that's used and how it's used, so it's something of a crapshoot for whether they'll support things nicely.
I have to use Xorg from time to time because Wayland on Ubuntu 22.04 (Intune only supports LTS) is pretty broken when it comes to screen sharing. This is why someone would prefer Wayland:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7183 jono 20 0 25.9g 187448 103628 R 52.0 0.6 41:44.25 Xorg
I've uninstalled X and XWayland from my primary laptop and don't miss it at all! Zero tearing is beautiful, and PipeWire has completed the equation very nicely, so all the usual suspects that used to be problems (e.g. screensharing) work seamlessly.
on their desktop application? I use their web version which does support it. Either way, their desktop version always used to say that screen sharing on my platform is unsupported.
I thought they used some gnome only screenshot api which doesn't work very well?
Thanks! I wasn't aware. I needed to set a couple of environment variables, and it's still broken, but it shows something. (very strange artefacts, looks like it's capturing garbage.).
