AMD's GPU Performance API Library 3.5 Drops ROCm/HSA Support

[pegasus]

I still have no idea what AMD's Compute plan is

Let me guess ... whatever Oak Ridge sponsors them to develop for Frontier?

[FireBurn]

We only have one open offering - the ROCm stack - and are building that up for all our recent parts, not just for datacenter.

We spent quite a while trying to establish clover (Mesa) as a cross-vendor standard but even after a few years it was still pretty much AMD-only, so we went back to opening up our own code instead. That was around 2015 IIRC.

Any idea when my Tonga (M395X) or Raven will be supported with the fully open stack?

[bridgman]

I still have no idea what AMD's Compute plan is, none of their open offerings are complete, wish they'd get their finger out and commit to one of them

We only have one open offering - the ROCm stack - and are building that up for all our recent parts, not just for datacenter.

We spent quite a while trying to establish clover (Mesa) as a cross-vendor standard but even after a few years it was still pretty much AMD-only, so we went back to opening up our own code instead. That was around 2015 IIRC.

[bridgman]

I expect this is because it was broken and didn't actually work. I reported this a while ago and didn't get any response from AMD.

AFAIK we concluded that trying to maintain one low-level perf API for both kernel-submit (PAL/graphics) and userspace-submit (ROCm) programming models wasn't going to work out well over time. I think there's a separate API for ROCm but will confirm.

[FireBurn]

I still have no idea what AMD's Compute plan is, none of their open offerings are complete, wish they'd get their finger out and commit to one of them

[Naquatis]

Please AMD fix OpenCL >= 1.2 implementation in Mesa and everyone is happy and buy more Radeon stuff. In the moment people who buying some navi based graphics cards (like me) instantly wish they had thrown their money on something that will provide them with Optix.

[Madgemade]

yeah. reporting problems to amd is exactly just as equal as not reporting anything at all.

Check out the ROCm Github issues. A year ago or so you used to see AMD devs responding to almost every issue, definitely every valid one. Now they are nowhere to be seen. There are some big issues with ROCm, such as false advertising for many broken features, devices which are not supported etc. Only silence from AMD, it's a shame really.

[duby229]

I expect this is because it was broken and didn't actually work. I reported this a while ago and didn't get any response from AMD.

yeah. reporting problems to amd is exactly just as equal as not reporting anything at all.

but of course it's really easy to talk to their oss devs on irc, so if you really want to get help it's always better to skip amd altogether and go straight to their oss irc feeds.

[Madgemade]

I expect this is because it was broken and didn't actually work. I reported this a while ago and didn't get any response from AMD.

[ms178]

I think that they are preparing for ROCm/OpenMP (gcc and llvm) and ROCm/OpenACC (gcc).

ROCm/OpenMP/OpenACC are still needed even if they join the oneAPI/SYCL/DPC++ route as it is complementary, see: https://github.com/intel/intel-graph...iler/issues/62