AMD ROCm 4.3.1 Released With RHEL 8.4 + SLES 15 SP3 Support

[phoronix]

Phoronix: AMD ROCm 4.3.1 Released With RHEL 8.4 + SLES 15 SP3 Support

ROCm 4.3 released at the start of August with support for HMM memory allocations, support for indirect function calls and C++ virtual functions with the ROCm compiler, improved data center tool integration, better rocBLAS performance, and a range of other improvements. In approaching the end of August, ROCm 4.3.1 is now available...

https://www.phoronix.com/scan.php?page=news_item&px=AMD-ROCm-4.3.1

[MadeUpName]

Considering RHEL 8.4 released at the end of May, it's rather surprising it took AMD until now to officially support this latest RHEL point release.

Doesn't surprise me.

[extremesquared]

Would be handy to include status of hardware support in these announcements, considering the ROCm team is currently running somewhere around two years behind.

[osw89]

Would be handy to include status of hardware support in these announcements, considering the ROCm team is currently running somewhere around two years behind.

"It will be released in 2021, but no specific timelines as of now. Please stay tuned."
"Yes, we have plans to add support in this year. Please stay tuned.
We can not add details of future plans in our wiki/docs as per the process."

I have been seeing such statements in their issues(github) since early 2020 and there's still no progress, the general lack of information and the vagueness is really frustrating. It's really interesting because they released some RDNA2 workstation GPUs too.

[aufkrawall]

Just don't expect anything at all, even their Windows OCL RDNA driver can't properly render Luxmark 3.x, while it works on Intel Gen 9 graphics. Blender performance is likely still broken too. AMD have definitely contributed a nice share to the demise of OCL.

[Kemosabe]

Just don't expect anything at all, even their Windows OCL RDNA driver can't properly render Luxmark 3.x, while it works on Intel Gen 9 graphics. Blender performance is likely still broken too. AMD have definitely contributed a nice share to the demise of OCL.

And so did nVidia but simply not supporting 2+ and pushing their cuda everywhere.
Sadly, the best way to go these days is headless Vulkan.

[aufkrawall]

Sadly, the best way to go these days is headless Vulkan.

Until AMDVLK once again misses some required extension and you (and the users of your program) are actually forced to use Linux with RADV.

[Kemosabe]

Until AMDVLK once again misses some required extension and you (and the users of your program) are actually forced to use Linux with RADV.

Not sure what extensions you're talking about. Mind to elaborate? Does headless_surface tend to be not implemented anywhere?
Also, it's scientific software, I can afford to ignore windows users

[Jabberwocky]

And so did nVidia but simply not supporting 2+ and pushing their cuda everywhere.
Sadly, the best way to go these days is headless Vulkan.

It's a ****-show where everyone is to blame to some degree, even adopters. I reserve my blame for the industry's progress in GPGPU compute over the past 20 years to Intel, AMD, Nvidia and Apple... but mostly Nvidia. There's no single-source vendor-neutral solution for compute that works on more than one OS nevermind web support. I guess you're right about the headless Vulkan especially if you are targeting end-users and not HPC specific hardware/software. OpenCL compatibility has proven extremely challenging even for open source software let alone ease-of-use orientated commercial users. I am not insulting these users. If I buy software I want it to "just work" too, not to debug for days and then end up buying a new computer to get support for a piece of software. Vulkan's out of the box support in most OSs is not bad.

I'm looking for something more HSA-like, meaning I want to be able to run on both CPU and GPU while sharing resources between each other. Vulkan shaders are not as accurate as most compute frameworks, but for my use-case inconsistent results isn't a showstopper at the moment.

Hopefully this can help out the industry: https://www.hpcwire.com/off-the-wire...-for-amd-gpus/ . I just hope this Codeplay design is compatible with open source proposed stacks, specifically the execution/runtime parts. Perhaps airlied could sit in an hour meeting with them to ask that one upstream question.