AMD Clarifies ROCm Compute Support For GUI Applications

[coder]

Furthermore HPC applications don´t need ... decoders

Wrong. AI and other use cases need video decoders. So, MI100 has them.

[ms178]

The key question is pretty simple - what should the MLSE group have *not* done in order to free up budget for RDNA ROCm support. ?

Investments into HSAIL and HCC come to my mind but these don't match the time frame of RDNA. Of course I am aware that AMD had limited ressources and that ROCm began with a small team with a huge task. Underinvestment in terms of the scope of the tasks at hand was one factor here and I hope so that AMD's product successes and re-gain of some financial strength will cure these problems over time.

By the end of 2020 we had just finished building up the ROCM stack to the point where it was sufficient for most prospective customers - we would have had to delay that for a year or so if we prioritized RDNA support, which in turn would probably have cost us a number of business opportunities. Do you think that would have been a good decision ?

I know I gave you a hard time lately concerning a lot of different topics. I don't want to be mean to you or your collegues. I am just curious about some of these decisions and we normally don't get to hear the reasoning behind them, hence I appreciate your answers and insights even though I might have opinions of my own. You are right that other business opportunities were probably more worth it to AMD. On the other hand better communication from the start would have helped to know what to expect as keeping these users in the dark for over a year does not deliver a great signal to the market either. I also doubt that customers are willing to wait that long if there are other market options in the future, more competitive pressure might solve this after all.

[coder]

Of course I am aware that AMD had limited ressources and that ROCm began with a small team with a huge task. Underinvestment in terms of the scope of the tasks at hand was one factor here and I hope so that AMD's product successes and re-gain of some financial strength will cure these problems over time.

Yeah, let's not forget the dire financial situation they were in, shortly before Zen launched. Lisa Su barely managed to keep the lights on, with that Chinese licensing deal.

My employer has been chronically under-investing in my team, over that same timeframe, and they're a profitable Fortune 500 company! So, I can definitely empathize with the feeling of not getting the support you feel you need and deserve.

On the other hand better communication from the start would have helped to know what to expect as keeping these users in the dark for over a year does not deliver a great signal to the market either.

This. Better communication about the roadmap for ROCm, and setting realistic expectations for RDNA support could've gone a long way towards avoiding some of the betrayal now felt in the community. It might've even lead to the community finding more creative workarounds, leading to a sort of win-win.

[tuxd3v]

Well, OpenCL3. The big question is if they support any optional features of OpenCL3. Otherwise: no news here. Just good ol' OpenCL 1.2 with a new name.

Well, I would be already satisfied with clover AMd Image Support within OpenCL1.2

[castlefox]

To be able to download a package and have openCL support in distro of choice would be nice, 6800xt is of no use in things like [email protected] atm moment. Having said that neither is my VII with rocm using manjaro.

Can someone please tell me what this clarification from AMD will mean for [email protected]? It needs openCL to work on their video cards.

[oleid]

Well, I would be already satisfied with clover AMd Image Support within OpenCL1.2

What card do you have? Doesn't the amdgpu-pro driver work for you as a stop gap?

[oleid]

Can someone please tell me what this clarification from AMD will mean for [email protected]? It needs openCL to work on their video cards.

It is working for some time now with amdgpu-pro. If you can run that driver you're fine.

If not, you can try mesa OpenCL. The following thread says it works with mesa 20.3.

https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/opengl-vulkan-mesa-gallium3d/1211540-opencl-1-2-support-merged-for-mesa-s-gallium3d-clover-while-opencl-3-0-is-being-tackled/page2

[tuxd3v]

What card do you have? Doesn't the amdgpu-pro driver work for you as a stop gap?

Has a stop Gap yes, but that it a closed source, when you have Clover which is a opensource one.. do you see the difference?

btw, using the Clover you are using opensource APIs ,
Not the closed source ones that amdgpu-pro has..and so freedom is better than closed source

[oleid]

btw, using the Clover you are using opensource APIs ,
Not the closed source ones that amdgpu-pro has..and so freedom is better than closed source

Well, the latest version of the amdgpu-pro opencl driver is open source as well, just the latest bits didn't get released, yet, to the ROCm repo. But I fully agree, freedom is better than closed source.

[LinAGKar]

I'll confirm, but AFAIK we were only using PAL for OpenCL on Vega on Linux and that has now moved to ROCr. We do use PAL for Vega and newer on Windows, but Polaris and earlier parts still use legacy aka Orca code paths on both Windows and Linux.

What's ROCr? Is that different from ROCm? Anyway, I was under the impression that ROCm would be used only on fairly high end GPUs, while low-end GPUs and APUs would use PAL (https://www.phoronix.com/scan.php?pa...OCm-PAL-Future). Do all RDNA GPUs work with ROCr, and will RDNA APUs do so?

But yes, open-sourcing PAL OpenCL would still leave a place for Clover on Polaris and older, except those that work with ROCm.

BTW, why can't PAL OpenCL be used on Polaris and earlier, given that AMDVLK works on these?