Radeon ROCm 4.1 Released - Still Without RDNA GPU Support

[pete910]

Is your "vega 7" a Vega20 / Radeon VII or 7 CU integrated Vega on an APU ?

If it's a consumer Vega20 then strongly recommend that you not update to 4.1 on that system yet - there are some changes related to ECC on server cards that seems to have causing grief on consumer Vega20's, at least when used with upstream kernels.

Trying to understand the scope of the issue now.

Its a Radeon VII , ver 4.0 would'nt work with either.

[bridgman]

Not read all the posts but the 4.1 HSA/rocm-openCL release works for me with my 6800xt. Not tried the vega 7 yet as tied to a vm atm.

Is your "vega 7" a Vega20 / Radeon VII or 7 CU integrated Vega on an APU ?

If it's a consumer Vega20 then strongly recommend that you not update to 4.1 on that system yet - there are some changes related to ECC on server cards that seems to have causing grief on consumer Vega20's, at least when used with upstream kernels.

Trying to understand the scope of the issue now.

[pete910]

Not read all the posts but the 4.1 HSA/rocm-openCL release works for me with my 6800xt. Not tried the vega 7 yet as tied to a vm atm.

This is on Manjaro with kernel 5.11.6

[wizard69]

IO Die

RDNA Support in ROCm
It´s a pitty that they don´t support it.. But i do get that they focus on existing customers / HPC market with CDNA.. Still believe it´s a mistake that will materialize in the long run to not allocate more resources to it, to get a minimal RDNA Support such that academia / students can board the platform early on.

I would agree that it is a mistake but then again such talent does not grow on trees. If you are really concerned send the CEO a note asking for more support in the area. Considering how well things are going at AMD right now I can see more money going into software development and frankly it already has.

Your reasoning is pretty accurate too, you need to get the early adopters on board. Without a change in mindset, of the young developers, ROCm will have a very hard time over the long term. The young being those in academia or students, but AMD is also missing out with established researchers when using ROCm is so difficult on desktop systems. This is actually perplexing because if somebody wants to put a high performance box on his desk, AMD is the right choice when it comes to CPU's. Then again if you have money for a Thread Ripper you likely have money for a CDNA card.

I don't pretend to have all the answers here, but I do believe as you do that AMD is not gaining the mind share it needs. Hopefully all will be good with the next ROCm release.

[wizard69]

Good point - I don't think that all the fixes from 20.45 have worked their way into the ROCm release stream yet but we should definitely mention that once the functionality is there.

It's possible that we may have to work through at least conceptually separating "the upstream for our compute components" from "our datacenter releases" as a pre-requisite since right now the ROCm releases kinda serve as both. That is going to be an increasing problem as we expand support to consumer hardware.

Thanks !

I'm not sure I like that idea. I understand the focus on the super computing contract as that can have a huge impact on AMD. However I really believe that those running those professional compute systems would rather prefer to have the same ROCm running on their personal systems, at work or at home. To put it another way a split up ROCm is likely to turn a large number of people off. That is sorta like telling somebody they can run this magnificent C++ compiler at work but must run a junior implementation at home.

You need to consider how easy it is these days to run, at home, what would be consider super computer work less than a decade ago. Eventually I would expect CDNA too look a lot different than the mainstream GPU's of the day. I would hope however that the same code base can be easily compiled to run on either no matter how far they diverge.

[MadeUpName]

The goal shouldn't be to make it easier for every user to compile the driver from source. It should be to work with the distros to get it packaged by them and released through their repos It isn't 1991 any more.

[Grinness]

bridgman

Would it be possible to provide a unique git repo for the _entire_ ROCm stack pulling in all the components (hip, rocr, llvm-amd, ...) so to facilitate end users to retrieve and build it?

At https://github.com/ROCmSoftwarePlatform there is a lot of stuff, but it is an headache to navigate and understand what is needed.

There is an _absolute_ need to lower the requirements to allow ppl to use the stack.
Even the docs at:

https://rocmdocs.amd.com/en/latest/C...ase-Notes.html

do not describe what packages/repo are available/needed.

[PapadakosPanagiotis]

Can you confirm that no DKMS driver is required for mainline kernel starting 5.9?

I using rocm on 5.12.0-051200rc4-generic

[Seebi]

I’ve been using ROCm on RDNA for nearly a year now without many problems. Also tried RDNA 2 and it worked fine there. I just ran a few OpenCL samples with ROCm 4.1 on RDNA and linux 5.11.0.
So I don’t know why they don’t advertise support, but it’s working for me.

[chithanh]

The TR4 IO Die is different, it has much more IO and can talk to more chiplets..

TR4 CPUs do not have an I/O chiplet. Only SP3, TRX40, and WRX80 do.

Question is, is the AM4 IO Die a scaled down version of the TR4 IO Die, the other way arround, or are they completly different chips?

The I/O chiplet of Epyc 7002/7003 and Threadripper 3000 is divided into 4 quadrants with two CPU IFOP links, two memory channels, 32 PCIe lanes and latency penalty for cross-quadrant communication. So it appears like 4 AM4 I/O chiplets fused together.