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

[AresMinos]

Hm, didn't AMDGPU-PRO just replaced OpenCL pal with ROCr? Does this mean AMD doesn't officially support any OpenCL driver for GUI app workflows??!

[bridgman]

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?

There are two parallel activities going on:

#1 - as you might have seen with the inclusion of ROCR-based OpenCL in the 20.45 AMDGPU-PRO packaged drivers, we are working on unifying the stacks so that users do not have to pick and choose between stacks depending on the work they want to do.

The ROCm stack was developed independently at first so we could move more quickly but we are reaching the point where having multiple stacks is no longer a necessity. There is still quite a bit of work to do in order to get everything unified, however.

#2 - in the short term we are trying to beef up the messaging to avoid confusion - the ROCm stack does not include all of the required graphics userspace components at the moment (eg Mesa) and does not go through graphics testing so we want to make that more clear.

The one thing that the messaging does not make clear is that the limitations are mostly related to (a) kernel driver testing and (b) absence of userspace graphics components. In general installing ROCm userspace on top of a working graphics stack with sufficiently new kernel should work, and we want to ramp up testing and documentation in that area over time. We already organize the ROCm packages so that you can install userspace compute components separately from the kernel driver.

[bridgman]

Hm, didn't AMDGPU-PRO just replaced OpenCL pal with ROCr? Does this mean AMD doesn't officially support any OpenCL driver for GUI app workflows??!

It's the other way round - it means that the ROCm components shipped with AMDGPU-PRO are part of a solution that does officially support both OpenCL and GUI apps.

The messaging about not supporting GUI apps only applies to the ROCm *stack* (see previous post for more specifics), not the individual ROCm *components*.

[AresMinos]

There are two parallel activities going on:

#1 - as you might have seen with the inclusion of ROCR-based OpenCL in the 20.45 AMDGPU-PRO packaged drivers, we are working on unifying the stacks so that users do not have to pick and choose between stacks depending on the work they want to do.

The ROCm stack was developed independently at first so we could move more quickly but we are reaching the point where having multiple stacks is no longer a necessity. There is still quite a bit of work to do in order to get everything unified, however.

It's still unclear to me. So you are unifying the stacks but also unifying them in AMDGPU-PRO and not ROCm. So does this mean that AMD is going back to closed source stack?

In general installing ROCm userspace on top of a working graphics stack with sufficiently new kernel should work

So what combination would that be for let's say DaVinci Resolve that most users seem to be having issues with?

[oleid]

In general installing ROCm userspace on top of a working graphics stack with sufficiently new kernel should work, and we want to ramp up testing and documentation in that area over time. We already organize the ROCm packages so that you can install userspace compute components separately from the kernel driver.

Personally, I don't really care much about graphic testing with ROCm. The mesa drivers are fine. What I'd like to see is being able to use working compute on consumer hardware - for personal needs. I sadly cannot buy a GPU and dedicated compute hardware just for training tensorflow models every few months.

[pete910]

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

It would be even better if it actually works though!

F@H, Luxmark ect all fail with my 6800xt and VII with rocm.

I've now given up trying

I even tried the windows user approach and did a fresh install of Manjaro to see if that solved it !

[qarium]

There are two parallel activities going on:

AMD can also do this: Put an RDNA chip and CDNA chip on one card.

i have a good idea about chiplet design for radeon cards.
we all know that chiplet design is very hard to do for realtime 3D graphic's and you do chiplet for the next generation CDNA.
why not build a graphic card like this: you put one RDNA chip on the card and one CDNA chip
then you do graphics on the RDNA chip
and all the compute stuff on the CDNA chip like: game physics or AI of the NPC in the games
games become more and more complex with complex physic and more and more AI for the NPC characters of the game.
if you do cards with both one RDNA and one CDNA chip you can also win gamers who do mining if they don't play games.

people will buy it even if there is only one good game like cyberpunk2077 for it.

in this way you can do chiplet design without the need of having multible RDNA gpu chips on the card.

[qarium]

So does this mean that AMD is going back to closed source stack?

... really... how can you think this ?... AMD ONLY has the trouble because they try to open-source it.
they do it all at the same time to make the customers happy...

[AresMinos]

... really... how can you think this ?... AMD ONLY has the trouble because they try to open-source it.
they do it all at the same time to make the customers happy...

I'm not saying it's a good thing that they go back to closed source development but that seems to be happening if they unify the stack under AMDGPU-PRO and not open source its parts fully. If they go closed source tho they are done. Finished. There will be no reason to buy it since Nvidia is way better anyway. Most people including me switched to AMD from Nvidia just to support their open source efforts. But since I can't actually get anything done with their broken drivers I'm kinda starting to regret that decision.

Going open source should be a good thing, investing in it, engaging with community, moving things forward, having a clear roadmap, addressing users issues, being responsible. But they kinda open sourced it and divested from linux at the same time.

[bridgman]

I'm not saying it's a good thing that they go back to closed source development but that seems to be happening if they unify the stack under AMDGPU-PRO and not open source its parts fully. If they go closed source tho they are done. Finished. There will be no reason to buy it since Nvidia is way better anyway. Most people including me switched to AMD from Nvidia just to support their open source efforts. But since I can't actually get anything done with their broken drivers I'm kinda starting to regret that decision.

Actually the AMDGPU-PRO stack is mostly open source already, with a couple of closed source components (our workstation GL driver and the closed-source version of Vulkan) along with an open source ROCm-based implementation of OpenCL.

We know that we need to separate out OpenCL (and compute in general) from the AMDGPU-PRO packages - the only reason they are tied together is historical, not technical (although I'm not sure about GL/CL interop with Mesa - it used to work but I think the current GL/CL interop testing is with the workstation driver.

I'm not sure where the idea about going closed source came from - certainly not from us.