AMD Radeon Open Compute 4.2 Is Released

The latest AMD ROCm compute stack has nothing new for Linux desktop users, and there is no mention of OpenCL in the release notes. It is still incapable of providing compute capabilities to desktop applications like Blender. Data center customers can enjoy new platform macros and several other improvements to the ROCm tools and libraries.

written by 권유리 (Kwon Yu-ri)  2021-05-13 - last edited 2021-05-13. © CC BY

ethminer benchmarking with Radeon Open Compute 4.2.

AMDs Radeon Open Compute (ROCm) is currently the best way to get OpenCL 2.0 support on GNU/Linux. That's a bit sad since it is severely lacking in some areas. The latest AMD Radeon Software For Linux provides ROCm as the default OpenCL stack. The other alternative for OpenCL 2.0 on GNU/Linux with AMD cards, the "orca" driver, is still available in the "AMD Radeon Software For Linux" driver package as a "legacy" option. ROCm is what AMD will be supporting going forward.

The latest ROCm 4.2 release has nothing new for typical GNU/Linux desktop users. OpenCL is not even mentioned in the release notes. Enabling ROCm 4.2 provided OpenCL as a Cycles device under Edit ▸ Preferences ▸ System ▸ Cycles Render Devices in Blender 2.92 results in a crash. And it doesn't work with DaVinci Resolve 17. Incompatibiltiies with OpenCL desktop applications isn't new to ROCm 4.2, desktop application support is just a use-case we like to test when AMD releases ROCm new versions since it is what's most interesting to non-datacenter users.

The highlights in ROCm 4.2, targetted at AMDs datacenter customers, are:

• HIP ("Heterogeneous-Computing Interface") target support in the platform marcors for HIP projects. HIP_PLATFORM_AMD and HIP_PLATFORM_NVIDIA can now be used to check if a HIP platform targets AMD or Nvidia.
• The HIP header directories have been changed to being platform-specific (amd_detail/ and nvidia_detail/
• Stream Memory Operations now supports direct direct synchronization between Network Nodes and GPUs using four new APIs: hipStreamWaitValue32, hipStreamWaitValue64, hipStreamWriteValue32 and hipStreamWriteValue64.
• The ROCm Data Center Tool has a new plugin called "Reliability, Accessibility, and Serviceability (RAS)".
• The ROCm Math and Communication Libraries rocBLAS, rocRAND, rocSOLVER, rocSPARSE and hipSPARSE have all seen minor improvements.

The source code for ROCm 4.2 can be acquired from github.com/RadeonOpenCompute/ROCm/releases. The better option, if you are using Ubuntu, CentOS/RedHat/Fedora or SLES 15, is to add a distribution-specific ROCm 4.2 repositoriy with binary packages using the instructions at rocmdocs.amd.com/en/latest/Installation_Guide/Installation-Guide.html. Do note that ROCm 4.2 installs itself to /opt/rocm-4.2.0/ without making the GNU linker aware of that path, so OpenCL won't work unless you manually add the ROCm library path to your LD configuration:

echo "/opt/rocm-4.2.0/opencl/lib/" > /etc/ld.so.conf.d/amd-rocm.conf

(You can, alternatively, edit /etc/OpenCL/vendors/amdocl64_40200.icd so it provides a full path to /opt/rocm-4.2.0/opencl/lib/libamdocl64.so instead of just libamdocl64.so)

The OpenCl 2.0 support ROCm 4.2 provides isn't entirely worthless even though it doesn't work with Blender and a few other desktop application. It does work fine with LibreOffice Calc, you can run benchmarks in LuxMark and you can mine digital currencies like Ethereum using ethminer. It may be worth the trouble of installing it if you have one of the AMD graphics cards it supports.

The officially supported AMD graphics cards are, as of ROCm 4.2:

• Vega (GFX9) GPUs (RX Vega 64, Radeon Instict MI25, Radeon Instinct MI 50, Radeon VII)
• CDNA GPUs (MI100)

There's also "unoffial" perfectly fine support for

• Polaris (GFX8) GPUs. Those would be the RX 400/500 series GPUs from some years back

The ROCm 4.2 release notes also list "unofficial" support for the older Hawaii (GFX7) GPUs such as the R9 390X and the FirePro W9100. ROCm, and the ROCm OpenCL package, hasn't worked with Hawaii GPUs for quite some time, and that's still the case with 4.2. It seems like someone at AMD tested an old ROCm version on a Hawaii GPU years ago and added it to the release notes, and now someone else at AMD keeps blindly copy-pasting it into new release notes even though ROCm hasn't worked with it for more than a year.

There is absolutely no support, "official" or not, for ROCm 4.2 on newer AMD graphics cards like the Radeon RX 5000 and RX 6000 series GPUs (GFX10/GFX10.3) - yet the OpenCL package from ROCm works fine on those newer totally "unsupported" AMD graphics cards. Radeon Open Compute 4.2 is worth a try if you just want OpenCL support on a brand new AMD GPU, though you shouldn't expect that the rest of the ROCm compute stack works at it should (or at all).

You can read the entirety of the ROCm 4.2 at the top-level page on the GitHub repository at github.com/RadeonOpenCompute/ROCm.

0.00

(0 votes)

Sort by date Sort by score

Enable comment auto-refresher

You are ignoring the author of this comment

Show comment | Manage ignore list

Anonymous (cabe4f8a)

31 months ago

Score 0

"The latest AMD ROCm compute stack has nothing new for Linux desktop users, and there is no mention of OpenCL in the release notes. It is still incapable of providing compute capabilities to desktop applications like Blender."

It's already been announced and debated that ROCm is not for GUI based compute Acceleration for those Applications like Blender 3D that use a GUI under Linux"

Actually Blender's Cycles-X announcement is more revealing for AMD and Intel as Cycles-X will not have any OpenCL support so it's Back to Nvidia's GPUs only Via CUDA/OptiX and just the same as it was 10 years ago when Cycles first was released and Only Nvidia took the time to get its Proprietary Compute API lock-in established on Linux based devices. AMD eventually Helped the Blender Foundation get AMD's 2nd generation GCN cards working(For Cycles GPU compute acceleration) via the OpenCL Compute API. But now we are back to that Nvidia GPUs only for Cycles-X and Nvidia putting in the developer time there where Both AMD and Intel will hopefully move to Vulkan Compute!

Now MESA is very supportive of the Vulkan and OpenGL graphics APIs but Vulkan happens to be a Graphics/Compute API in one API, so the Linux/MESA folks with the Help of Valve will always be more supportive of Vuklan Graphics, and Compute is along for the ride there, so maybe less issues with the OpenCL unwanted stepchild treatment in the Linux community all these years!

All the Desktop Linux Distros ship with support for Vulkan plumbed in, no need to download and Install AMD's OpenCL Drivers there that's limited to the major distros and AMD's focus there on OpenCL for Headless servers and not Desktop linux Applications that use GUIs! So What's AMD and Intel's Response to Cycles-X going to be for the creative end users and some needed GPGPU compute support via the Vulkan Compute Side of that Vulkan Graphics/Compute API that's very likely to always support GUI based applications(Games from Lord Gaben) and Thus by extension, hopefully, Blender 3D, Gimp, Dark Table, Inkscape, Krita, etc!

Ray Tracing on GPU's Shader cores is a GPU Compute Related workload whereby the GPUs Shader cores are put to the Task of calculating the Ray/BVH computations so that's any of the older generation GPUs that lack the dedicated Ray Tracing Hardware of the more Modern GPU designs but instead have support for OpenCL/CUDA based methods to utilize GPU Shader Cores for compute oriented workloads! So With dedicated Ray Tracing IP Starting with the PowerVR Wizard(Ray Tracing In Hardware IP) line of GPUs that Imagination Technologies Pioneered circa 2014 and now Others Brands of Ray Tracing that has since become available since Nvidia's Turing/RTX and AMD's Navi/RDNA2 GPUs. So for Linux Vulkan is the future but the GPU makers need to Focus more on the Various Graphics/Audio/Other Open Source, and Proprietary, Applications that need that GPU Compute Related Acceleration of certain Tasks Like Ray Tracing and Others that can be done more quickly on GPUs than the fallback option of doing all that on CPU cores at a great loss of time and efficiency!

Nvidia's appears to be the one GPU maker that Prioritizes making sure that it's Proprietary APIs like CUDA and OptiX are supported on Blender 3D/Other Applications ASAP while AMD and Intel do not appear to be as interested on making the effort there but Vulkan has a wider Industry and Linux Community level of support there so now it's on AMD's and Intel's side to step up and support the creative end users as much as the gaming end users. And strangely enough it's the creative folks that are responsible for the games creation in the first place so What are you Doing Lord Gaben to help out with that disparity in support on Linux!

Permalink | Reply

You are ignoring the author of this comment

Show comment | Manage ignore list

Yuri

31 months ago

Score 0

You lost me when you said Gimp, Dark Table, Inkscape and Krita should use Vulkan compute. What for? None of them use OpenCL or anything else for anything today. I guess GIMP could get a RealSR plugin for image up-scaling..?

I do agree that Blender, LibreOffice, Kdenlive and other free software project using OpenCL 2.x should move to Vulkan Compute and ever look back (if that's possible). Every time I want to run something that's made for Cuda and I look for alternative implementations (like waifu2x), it's always a Vulkan compute implementation - not a OpenCL implementation - that ends up being the practically usable alternative.

Permalink

You are ignoring the author of this comment

Show comment | Manage ignore list

Anonymous (e4468cc0)

31 months ago

Score 0

I may be utterly mistaken. But GUI has virtually *nothing* to do with compute until you are computing visuals and/or you want to visualize results. This one thing has bothered me since I first read about broken support for creativity software. It seems silly to say "we only support headless compute software" when it sounds like the real problem is not a program using a GUI, but a program needing the cl_khr_gl_sharing optional OpenCL extension in order to show compute results (in GPU memory) directly and efficiently on the screen(s) attached to the same GPU.

In the worst scenario, something like Blender could still (optionally) copy the results *back* to system memory and show them like any other data that gets sent *out* to the GPU through the usual display system. Of course it would be somewhat less performant, somewhat more painful, and offensive to the good engineering sense of many.

Permalink | Reply

You are ignoring the author of this comment

Show comment | Manage ignore list

Yuri

31 months ago

Score 0

That's interesting, I didn't know cl_khr_gl_sharing is the missing puzzle-piece. I guess LuxMark doesn't use it since that (and LibreOffice) actually work with ROCm?

As for AMD's "we don't want to support GUI programs", I've always read that as "We only care about our big data center customers, the few desktop Linux users who use compute aren't profitable enough for us to care". That this is the case is somewhat obvious if you look at how little they contribute to Mesa in general and the Mesa Clover OpenCL implementation in particular; AMD could easily hire a few more developers and make OpenCL work perfectly on AMD hardware on Linux out of the box, without installing any additional ROCm packages. It's a bit sad that they don't, they same way it is a bit sad that they waste time on that AMDVLK Vulkan implementation of theirs (it's slower than Mesa RADV, and much slower at Vulkan compute, so what's the point?)

Permalink

You are ignoring the author of this comment

Show comment | Manage ignore list

Anonymous (e4468cc0)

31 months ago

Score 0

@Yuri

It might be that, and it might not be. It is only a hunch and the place I'd start looking. You say LuxMark is working, and LuxMark doesn't rely on that extension; it has no mention of CreateFromGL such as clCreateFromGLBuffer (as expected). Blender is supposed to be broken but it doesn't seem to call any function like that, either. It's only mentioned in their bundled clew and handled as any other part of the API. So it looks like a dead end.

Yes, it's a bit sad.

Permalink

You are ignoring the author of this comment

Show comment | Manage ignore list

Anonymous (cabe4f8a)

31 months ago

Score 0

Yuri, Blender 3D uses OpenCL for Ray Tracing on the GPU Via Cycle's GPU accelerated rendering unless you prefer your CPU cores all tied up at 100% doing a Cycles CPU accelerated rendering Run and taking a lot longer than any GPU Accelerated Cycles rendering workload to do that.

So in your opinion the creators do not count to AMD or Intel but I see they sure do to Nvidia as far is Blender 3D is concerned and here from the gimp 2.10 release notes: "GPU-side processing is still optional, but available for systems with stable OpenCL drivers." (1)

You do understand that GPUs have a bit more Cores(Hundreds to Thousands) in which to benefit any Graphics/other Application end user and get some things done much quicker than the limited numbers of CPU cores(16 for Mainstream CPUs on PCs via AMD's Ryzen processors) and even AMD's Threadropper Pro processors have only 64 cores maximum which is not a lot compared even integrated graphics!

And Yes all the Programs that you mention above should be using Vulkan but they have not been refactored to do that just yet so are stuck with OpenCL as the Application Projects need assistance getting that done and for Nvidia's Proprietary CUDA/OptiX(Blender Cycles rendering on Nvidia's GPUs) Nvidia sure helps the application developers(Blender Foundation) get that Nvidia only GPU compute option supported!

And you're assuming that Just Because some Earlier version of ROCm's OpenCL component works fine for LibreOffice does not mean that any newer ROCm versions will have that supported! And really Vulkan is the Better Supported API going forward there I agree. But Until AMD and Intel work with the Open Source Graphics software community then that's not going to go well for the Open Source application projects as the creators will have to get their work done in the present and not be able to wait for AMD and Intel to come around to assisting the open source projects that I have listed get that done ASAP.

Vulkan sure gets supported with Zero effort on the part of the Linux Based PC's/Laptop's end users whereas OpenCL for AMD GPUs requires some system administrative skills. It's really why Windows is still utilized for Desktop Applications as MS/AMD, and Nvidia/Intel sure makes sure all that OpenCL support is out of the Box available there! But I'm sure not happy doing any of my day to day PC/Laptop work booted into windows as I'll do that booted into Linux Mint! But from your replies to my Posts it's easy to see that Linus Torvalds is correct in his assessment about the Linux desktop's issues and adoption rate unlikely to improve anytime soon!

(1)

"GIMP 2.10 Release Notes"

https://www....mp-2.10.html

Permalink | Reply

You are ignoring the author of this comment

Show comment | Manage ignore list

Anonymous (ce17d095c1)

30 months ago

Score 0

that! And Intel is Behind on Process Node and Integrated/Discrete graphics to AMD/TSMC but Intel's Way ahead of AMD with developers on staff. So AMD's Better Graphics will be not be so much used if Intel gets ahead of AMD with Cycles-X support that currently only works for Nvidia's GPUs For that Future Cycles-X rendering that will not have any OpenCL support.https://ninj...blender.html

Permalink | Reply

Add your comment

LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.