AMD Will Continue Maintaining Multiple Compute Stacks For Linux

[Brisse]

Switched from ROCm to Orca after the former stopped working after the 1.8 update, and I'm actually getting slightly better hash-rates in ethminer with Orca on my two Fury's so I guess there's still some room for optimization in ROCm. ~28MH/s per card became ~29.5MH/s. Not that I normally run them at full speed but there was a similar performance difference in lower power states as well.

[bridgman]

Other than that, i hope Mr Bridgman and company will provide us non ROCm compatible users with a nice traditional OpenCL solution, sometime in the future. I own an FX6300 (thus no pcie atomics) and a Tonga gpu and would like to have the option to run some decent OpenCL on my gpu. My next upgrade won't happen before 7nm AMD products because i am satisfied with my current desktop performance, so any OpenCL would be welcome in the meantime... Clover is so unfinished it hurts.

You should be able to install the 18.10 or 18.20 packaged drivers (pro or all-open) and include OpenCL. I think you'll need to use the -pro option if you want GL/CL interop, but a couple of people have already reported success running pure OpenCL with the all-open install option.

[juno]

You should be able to install the 18.10 or 18.20 packaged drivers (pro or all-open) and include OpenCL.

Are you talking about clover (CL 1.1)? Because if not, it's not "all-open" as long as OpenCL is involved, or am I missing something?

[schmidtbag]

If there's one thing about the AMD+Linux experience I really don't like, it's the amount of drivers for modern hardware that are still relevant within the past year. It seems very counter-productive to maintain so many of them, especially considering how much some overlap each other's abilities (in other words, there's a lot of unnecessary redundancy, in a user perspective). I understand that on a technical level, many of them function very differently from each other, and I understand that some of these drivers are in the process of obsoleting others. But, I feel like all this divided maintenance is just slowing down progress, and it gets real confusing. It's hard to know which drivers work with what hardware, which drivers perform best with which hardware, and which drivers perform best with which applications.

I find it ridiculous how there's currently 3 options for OpenCL, none of which (to my understanding) seem able of obsoleting either of the others. I'm glad at least Orca is planned on being dropped.

[GruenSein]

If there's one thing about the AMD+Linux experience I really don't like, it's the amount of drivers for modern hardware that are still relevant within the past year. It seems very counter-productive to maintain so many of them, especially considering how much some overlap each other's abilities (in other words, there's a lot of unnecessary redundancy, in a user perspective). I understand that on a technical level, many of them function very differently from each other, and I understand that some of these drivers are in the process of obsoleting others. But, I feel like all this divided maintenance is just slowing down progress, and it gets real confusing. It's hard to know which drivers work with what hardware, which drivers perform best with which hardware, and which drivers perform best with which applications.

I find it ridiculous how there's currently 3 options for OpenCL, none of which (to my understanding) seem able of obsoleting either of the others. I'm glad at least Orca is planned on being dropped.

While I am sure that some of this is due to the driver history and legacy hardware etc, I must agree that especially the OpenCL situation is pretty confusing. Particularly since there do not appear to be any plans for consolidating all these drivers. If you consider each driver separately, I am sure you can find a good reason for its existence. What I find somewhat surprising is that after all this investment into open source technologies and a shared Vulkan implementation, all other drivers seem to have absolutely nothing in common. ROCm (CL) is totally different from PAL (CL) which is totally different from MESA (GL). When the open source plans were made and development accelerated a couple years ago, a joint foundation could've been decided upon. The current situation must create lots of overhead on the dev side when new hardware needs to be enabled. Wouldn't it be easiest to go all PAL so not only the Vulkan driver but all the others can be deployed on all platforms?

[RussianNeuroMancer]

The part you are wrong is that HSA is hardware-reliant, not just driver-reliant.

This is actually exactly what I mean - OCL-on-PAL software implementation is easier than changing future hardware.

[stormcrow]

This means AMD really does something very wrong with some mainboard board partners like "MSI"

It's been my experience lately (lately being past several years) that it's almost invariably the main board vendor when you have hardware support issues. For example, my latest system (as of last April) is a Ryzen 1600 on a MSI mainboard with the B350 chipset. Originally the board would drop to the EFI setup screen on every reboot. It took me a month or so to figure out the firmware was getting confused with two EFI boot entries (Windows & Linux or BSD) in the EFI partition and silently dropped to setup each time.

When I notified MSI of the firmware bug they sent me a boiler plate response that they only support Windows and would therefore not bother to pass the bug on to engineering. Eventually after pointing out (angrily at the time I admit) that it affects Windows too, as it would happen regardless of what the other EFI entries were, and threatening to publicize the bug and their response I was politely responded to (without the scripted response this time) with a vague non-answer to wait and see in the next couple of firmware updates. Sure enough, two updates later the bug was fixed. I waited because the next firmware update was a week later and it was unlikely to have contained any such fix, it was too soon after reporting it.

AMD just provides the processor (or GPU) and chipset along with the hardware support package (that's the AESA version firmware updates often reference) needed to boot the CPU/Chipset, the rest of the details are up to the main board makers and quite often, they screw the pooch.

[bridgman]

Are you talking about clover (CL 1.1)? Because if not, it's not "all-open" as long as OpenCL is involved, or am I missing something?

No, I'm talking about the closed-source OpenCL driver which AFAIK can be added to the all-open stack (which, of course, would no longer be "all-open" after you add the closed source OpenCL driver).

[schmidtbag]

it is 4 not 3.... Orca,ROCm,PAL,Clover...

This is one of those very rare occasions I dislike being corrected, not because I'm wrong, but because it further supports my point.

[bridgman]

I find it ridiculous how there's currently 3 options for OpenCL, none of which (to my understanding) seem able of obsoleting either of the others. I'm glad at least Orca is planned on being dropped.

Where are you getting 3 from ?

Clover doesn't really count - there are still people working on it intermittently but it never really caught on as a community project AFAICS.

OpenCL-over-PAL is an up-to-date replacement for the Orca back-end, with the transition to PAL just starting now. I guess you could count that as two during the transition but it's pretty obvious what the relationship between them is.

The only non-transitional "option" I see is ROCm vs Orca/PAL when running on the ROCm stack.