Radeon ROCm Updates Documentation Reinforcing Focus On Headless, Non-GUI Workloads

[phoronix]

Phoronix: Radeon ROCm Updates Documentation Reinforcing Focus On Headless, Non-GUI Workloads

The Radeon ROCm open-source compute documentation has been updated to more clearly spell out what was already implied: their focus is on compute for headless, GUI-less workloads and not OpenCL or compute for conventional desktop applications...

http://www.phoronix.com/scan.php?pag...n-ROCm-Non-GUI

[aufkrawall]

On Navi, Blender performance is much lower with the amdvlk-pro CL vs. Windows, while [email protected] is faster. Hopefully this driver will continue receiving some love.

[ripper81]

Even Rocm would support my Radeon RX 5700 i would avoid it. Distributionsupport is too limited and it is way to hard to keep it updated.

AMD should make the proprietary OpenCL driver available for all distributions outside of the radeon software for linux. Rocm could be a great rival for Nvidias CUDA, but in its current form it is not realy useable outside the HPC space.

[skeevy420]

Even Rocm would support my Radeon RX 5700 i would avoid it. Distributionsupport is too limited and it is way to hard to keep it updated.

AMD should make the proprietary OpenCL driver available for all distributions outside of the radeon software for linux. Rocm could be a great rival for Nvidias CUDA, but in its current form it is not realy useable outside the HPC space.

IMHO, AMD doing things a distribution at a time is their biggest weakness on Linux. While I wouldn't buy Nvidia any more, back in the day I did prefer their "Here's a list of requirements, figure it out" approach to Linux software and drivers over AMD's current "Pick one of these or hope the free stuff works" method.

FWIW, while unofficial, you can use the Pro OpenCL driver on other distributions. It's in the AUR if you're on Arch/Manjaro.

[andrei_me]

It's in the AUR if you're on Arch/Manjaro.

Is it working fine for what GPUs using the AUR approach?

[acowley]

This is very disappointing. It would be one thing if ROCm devs showed the causes of reported bugs to be due to GUI applications doing something with shared contexts or something else GUI-specific, but if computations are coming out wrong, and no answer is ever given, how can one have faith that things will work in a headless scenario?

[OneTimeShot]

Well it's AMD's money to waste, but haven't they learned that Mesa/Clover is the way forward yet? How many years did they maintain that Catalyst driver for "professional users" on Linux?

If they can't get enough resources on ROCm to keep it working, then move development resources to the "shared" OpenCL implementation. It's not like anyone is clamouring for an AMD-specific compute stack...

[WolfpackN64]

At this point I´m just hoping Clover will pick up the slack.

[oleid]

They not claim that it won't work, it is just not their primary target. They probably have more than enough to do with their current supercomputer wins. Having that said, I'd love to use a recent RNDA2 card for compute (i.e. train some tensorflow model). Currently I'm using a used 1080X I bought from someone who managed to get some 3080 when they got released.

bridgman What is your view of this article and the general direction of ROCm?

[FireBurn]

I wonder if that explains why I couldn't get the open source ROCm stack working with luxmark