Radeon RX 6800 Series Has Excellent ROCm-Based OpenCL Performance On Linux

[MadeUpName]

How many distros contain Linux 5.9 out of the box? Arch/Gentoo/LFS? They are not distros for normal people.

Fedora hits the trifecta

# uname -r
5.9.8-200.fc33.x86_64

mesa-libOpenCL-20.2.2-1.fc33.x86_64

rpm -qa |grep llvm
llvm-libs-11.0.0-1.fc33.x86_64

[pal666]

Weird, seems like the Linux OpenCL performance is way better than it is on Windows

even quality of life is better on linux than on windows

[MadeUpName]

The two biggest disapointments I have seen so far is a short segment from LTT that makes it look like AMD didn't do any thing to improve their hardware encode support. It is still an expensive macro block generator. Whether that can be improved via drivers or firmware is some thing I don't know but I was really hoping they would put some effort into it. A 4 hour software render is half my day that I can't use my computer, a 10 min hardware render is a bathroom break.

The other thing is that while on Windows the consensus is that AMD is still slightly behind AMD for gaming, on work loads like editing etc it appears a lot slower than NVidia. It's still early and we may see some driver improvements over the next few weeks. But it appears AMD still hasn't decided to care about creators yet. They should change their attitude towards that community as creators are also some of the most powerful influencers.

[extremesquared]

I'll be curious to see what the thermals and power consumption target of the future 6500xt will be like. Looks like a decent efficiency jump occurred.

[extremesquared]

rx6500. ddddxt is cpu.

[andre30correia]

then for having opencl driver the 5000 amd wait a year, nice and to use this we need the closed driver? They already resolve the hangs in navi cards or Iwill need to wait another year?

[AdrianBc]

How many distros contain Linux 5.9 out of the box? Arch/Gentoo/LFS? They are not distros for normal people.

As I've said before a hundred times already, Linux kernel development model is bonkers as you either get stability or support for new hardware but never both. Drivers must be decoupled from the kernel to make Linux even remotely interesting as a desktop OS. Thanks to Google we'll soon have an open source kernel which works exactly like I expect: Zircon. I will gladly replace Linux with Zircon if NVIDIA starts supporting it. Don't wanna deal with regressions, bugs and GPL madness each three months.

To make clear that I am not normal, I am a Gentoo user :-)

I have seen some negative comments directed to this post of birdie, but it is obvious that whoever disagreed has never written or maintained a Linux kernel device driver.

I have to agree that the Linux development model for kernel device drivers is extremely annoying.

I am using some kernel drivers for some esoteric hardware, which are extremely unlikely to be ever included in the official kernel.

Typically about every other new Linux kernel version, to which I update, breaks my device drivers.

Because I cannot expect that whoever wrote those open source device drivers, and graciously published them initially, will also have time to maintain them, I must every time write myself patches to fix those kernel device drivers.

The changes in the Linux kernel that break so frequently the device drivers are usually things like moving some definitions from one kernel C header file to another kernel C header file, adding members to a structure definition or deleting members from a structure definition.

Fixing broken device drivers is usually not difficult, but it is very difficult to find which is the correct fix.

There is no adequate documentation about the changes, the change log of the Linux kernel usually includes no information about the changes that break device drivers.

The only way to solve the problem is to search the Linux kernel mailing lists for the words you hope to be related to the debugging information that you get while attempting to compile and run the old device drivers with the new kernel.

After some work, you finally discover some e-mail message from a kernel developer, which describes the change made to the kernel sources.

Nevertheless, the problem is not solved, because in most cases the e-mail message does not contain any information about how other people should alter their device drivers to work around the change made by that developer.

Very frequently, due to that change, you have to either delete some arguments from a function invocation to work with the new kernel, and you have no idea whether this will work as before or some other instructions must be inserted elsewhere, or, worse, you must add arguments to that function invocation and you have no idea what values should be put in the new arguments for the invocation to work as before.

Of course, because the Linux kernel is open source, that means that any problem has a solution and eventually you will find it, sooner or later, after reading and understanding various other kernel files.

However, the Linux kernel is large and it becomes larger and larger, so fixing broken device drivers can waste a lot of time, because you practically have to redo the work of whoever made the changes that broke your device drivers and was too lazy to think about those who are not core Linux developers and document appropriately the changes.


While there are many people that believe that Linux should maintain a stable API for device drivers, like most other operating systems, I do not think that such a restrictive policy is required.

Nonetheless, if a stable device driver API is not kept, to avoid the continuous rewriting of the device drivers to keep up with the rest of the kernel, then the minimum requirement is that anyone who makes a kernel change that breaks other existing device drivers should also have the obligation of writing instructions for the other device driver developers, containing what modifications must be done to rewrite the device drivers from the old API to the new API.


Unfortunately I have never seen, until now, anyone applying such a common-sense documentation rule for device drivers.

Maybe there are other more thorough kernel developers, who document better their work, because there are many of them and I had to work just around the changes made by a small percentage of them, and I did not have time to check what others do, just out of curiosity, but what I say is true for all the kernel changes that I was forced to search in the mailing lists.

[illwieckz]

Fortunately there isn't that level of driver fragmentation on the OpenCL side.

Michael there is a lot of fragmentation on the OpenCL side: https://gitlab.com/illwieckz/i-love-compute#frameworks

Well, that's probably the most fragmented thing out there.

[birdie]

Yep, but AMD titles look much better (than Nvidia) so congratulations on the nitpicking for misreppresentation.


I bet more than 1% use either libreoffice, blender, or darktable, ... just to name a few.


The word that you are looking for is called competition. We all benefit from it. For example, Nvidia did not sell their high end (Ti and Titan) GPUs at reasonable prices until big navi happened.

I've tolerated your crap long enough but it's enough. Not gonna see your fanboyish posts any longer.

1. I'm not sure how non-RTRT AMD titles have anything to do with RTRT performance. AMD has always had games which were developed for its GPU archs. This is 100% inconsequential. People don't play only AMD optimized games. Lastly, there are no AAA native games for Linux, so, what the hell are you even talking about? A Linux website and a dude is talking about Windows games, LMAO.
2. I am running LibreOffice - I am not using OpenCL and so are most users. Blender and DarkTable? Again absolute minimum people use these two applications - I'm pretty sure less than 1% of people here on Phoronix. Also both work just fine while using multi-core CPUs.
3. The word you're looking for is "fuck off": when AMD wasn't so cool and trendy, they competed with Intel and AMD fiercely by offering much better performance per price. For the RX 6000 generation:

Priced at $650, the Radeon RX 6800 XT is positioned similarly to NVIDIA's RTX 3080, which has an MSRP of $700. At that price point, the 6800 XT matches the 3080 almost exactly in performance per dollar.

Keep on singing praises to your company which used to actually compete. Vs NVIDIA they now match performance per dollar and vs Intel the new Ryzen 5000 CPUs offer a worse value for the same money.

Again, if you're not their shareholder, your posts look miserable. You create free advertising for AMD and you don't get paid for that. Lastly AMD don't give a damn about you personally.

Looks like lots of Open Source fans just cannot imagine their world without being bitches to their favourite companies and that's truly cringe worthy.

[birdie]

Fedora hits the trifecta

# uname -r
5.9.8-200.fc33.x86_64

mesa-libOpenCL-20.2.2-1.fc33.x86_64

rpm -qa |grep llvm
llvm-libs-11.0.0-1.fc33.x86_64

That's after updates - F33 installation media doesn't contain this kernel. Kinda hard to imagine, but it's my main OS right now. And Linux is known for often being unable to boot when your hardware is too fresh - no one likes to speak about it but it's been like that for ages. Meanwhile I can install Windows XP on my 2019 PC.