RADV's ACO Compiler Back-End Now Supported For Older AMD "Sea Islands" GPUs

[YamashitaRen]

hey, does anyone know if aco is compatible or will be supported on GCN 1.0 (R280X ?).
It's really frustating the see this lack of support of not newest cards.

se
It looks like AMD has given up on GCN 1.0. Amdgpu for GCN 1.0 is basically a proof of concept. They do not seen to have any plan to port any new feature to theses hardwares : https://gitlab.freedesktop.org/drm/amd/issues/371

[humbug]

first, they can't enable it by default until it has all missing features implemented, like uvd. second, then they have to validate it, which also requires resources. and i'm sure they weren't hiding this information

they were making progress on ticking off the required features and defintely planned to make it default for gcn 1.1, but at some point it was abandoned.

[LoveRPi]

AMD's software development is contract driven which is a horrible way to run software engineering. There's no technical direction so after more than half a decade, they have little to show for it (HSA, OpenCL, Compute). They seriously need to get an software engineering head that is given resources to organize and set technical direction rather than fulfilling contractual goal posts. You can't develop software like you run a business.

[agd5f]

For example, https://www.techpowerup.com/gpu-spec...n-r9-390.c2664 vs https://www.techpowerup.com/gpu-specs/radeon-rx-570.c2939 can be used to determine basic differences between the cards from consumer viewpoint.

Most of that information comes from this page:

https://www.x.org/wiki/RadeonFeature/

[agd5f]

Um that's not true. Bridgman himself has previously said that CIK support was enabled by default in their separate kernel branch, the one they recommended for some clients. But for mainline they haven't bothered enabling it by default, and no one knows why.

This is largely up to distros. They are the ones shipping the whole stack (kernel through userspace) and they are the ones who can make sure the proper user mode bits are in place to handle mixing old and new userspace and kernel in a why that doesn't break a user. At this point amdgpu has been shipping long enough that most recent distros should be fine, but there may be some odd ones out there...

The bigger issue is that radeon has been out there and working for years on these generations. It's had years of testing and usage on a wide variety of parts. Way more than anyone could reasonably test at this point. Do you chance breaking lots of users that are working just fine with radeon for some new features that they may or may not be interested in? It's trivial to enable amdgpu rather than radeon for these asics on most modern distros, so if you want to run amdgpu you can.

On top of this, both drivers are open source. Anyone that is interested can port features either way.

[arQon]

It seems you are comparing previous generation higher-end card (R9 390, launch price 329 USD) with current generation mid-range card (RX 570, launch price 169 USD).

I am, but that was exactly my point, and that of the OP: that the GCN 1.0 cards, despite being superior or at least equivalent in performance and functionality to 1.1 / 1.2, are being excluded from this in a way that is essentially arbitrary, thus accelerating a false obsolescence rather than a "real" one of them not being up to the task any more.

The "arbitrary" part is basically "We don't have the resources / will to test against this only-fractionally-different capset, so, tough". And we all UNDERSTAND that RTG is desperately "poor" compared to NV: we just think it's a shame that it causes scenarios like this one to play out the way they have.

You clearly understand that point, which is good - I'm just confused by your confusion over it having been presented as anything other than how it was.

[smitty3268]

Um that's not true. Bridgman himself has previously said that CIK support was enabled by default in their separate kernel branch, the one they recommended for some clients. But for mainline they haven't bothered enabling it by default, and no one knows why.

False. They've said exactly why - they don't have the time to spend to enable it by default when the old driver works and the new one would no doubt expose new bugs/etc. that they don't want to deal with. Which is why they won't ever try to enable it by default.

If Red Hat or some other interested party wanted to, then they could make it happen. But AMD isn't going to do it themselves.