AMD Sends In Navy Flounder Support, More Sienna Cichlid For Linux 5.9

[phoronix]

Phoronix: AMD Sends In Navy Flounder Support, More Sienna Cichlid For Linux 5.9

At the end of June was the first batch of AMDGPU changes queued for DRM-Next to in turn go into the Linux 5.9 kernel when that cycle opens up in August. On Friday a second batch of feature changes for this open-source AMD Radeon kernel graphics driver was submitted...

http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-Round-Two-Linux-5.9

[NateHubbard]

That's a pretty impressive headline. I had zero idea what you were trying to say.

[Danny3]

I hope they will focus on video decoding too, 4K / 8K, 30 / 60 / 120 FPS, HDR and provide hardware acceleration for the most common codecs like H.264 / H.265, VP9 and AV1.
There are a lot of people out there who do not game, but like to watch movies or videos on online platforms.
And even for games good video hardware encoding and decoding is very important to stream or watch streams and even to play games from one computer to another in the local network with Steam's In-home streaming or whatever the feature is called.
Hopefully this way Steam can stop forcing us to use a Windows host for playing the game and streaming it.

[bridgman]

That's a pretty impressive headline. I had zero idea what you were trying to say.

That's the goal - to get upstream support in place before launch without anyone knowing what happened

[wizard69]

More good news from AMD. It is interesting that Arcturus was mentioned as there has been little or really nothing leaked about that lately. Hopefully Arcturus is delivered around the same time RDNA2.

[wizard69]

That's the goal - to get upstream support in place before launch without anyone knowing what happened

It is great to see these new fish but when will we be hearing about: Hoplostethus atlanticus aka Orange Roughy? My greatest fear right now is that these fish will start to smell well fishy, if not released soon. We don't want Navi to be swimming with the fishes before having a chance to evolve legs to walk into our PC's.

[bridgman]

It is great to see these new fish but when will we be hearing about: Hoplostethus atlanticus aka Orange Roughy? My greatest fear right now is that these fish will start to smell well fishy, if not released soon. We don't want Navi to be swimming with the fishes before having a chance to evolve legs to walk into our PC's.

Orange Roughy is in the list but I think we are picking out single-word fish names for now.

We are working under the assumption that digital fish don't get stinky as long as we test upstream code periodically. If that assumption doesn't hold up then we might have a problem.

[JMB9]

That's the goal - to get upstream support in place before launch without anyone knowing what happened

Would be nice if that would really happen - especially when upstream is distribution support and not just kernel support for technical interested users.
AMD is in great shape currently - but as an owner of Navi 10 (and Zen2) there is a lot to desire for the stable desktop use being possible only with at least kernel 5.6 (5.3 was the initial support - showing periodic errors in dmesg coinciding with intermittent system stalls - 5.4 and 5.5 even shows crashes) and Mesa 20.1 (using 5.7.9 and 20.1.3 right now without any issues).
So out of the box support by distros will emerge this autumn ... (even Ubuntu 20.04 LTS is currently not sufficient - will have to wait for 20.04.2):
I don't think that this support is great for a summer 2019 card, do you?
So are there plans to improve on that front (heavily!)?

When I understand this correctly RDNA2 (Navi2/Big Navi; without die shrink) is coming this year - so currently working on initial support for 5.9 would be extremely late again - and RDNA3 (incl. die shrink) is expected for 2021 - so those RDNA3 cards should currently see initial support ... or am I missing something?

We are also waiting for full Navi (RDNA1) support: is a configuration tool planned (sorry if I missed it if it already exists as free tool for Linux; something like a scaling option for games would be nice for 4k+ resolutions) and what about ROCm supporting Navi ... any information on that front would be very welcome.

[bridgman]

Would be nice if that would really happen - especially when upstream is distribution support and not just kernel support for technical interested users.

I would rather avoid blurring the definitions - upstream is upstream, nothing more - but between...

- upstreaming sufficiently early,
- stick-handling missing code directly into distro trees before release,
- testing distro-supplied upstream kernels on our hardware and
- providing ready-to-install packaged drivers

... we do need to make it easy for launch-time customers to use their new hardware. We are not quite there yet IMO (although Navi10 was worse than normal) and are still working on improving that.

You asked a lot of questions related to RDNA2 and RDNA3 launch dates that I can't answer, sorry.

[JMB9]

I would rather avoid blurring the definitions - upstream is upstream, nothing more - but between...

- upstreaming sufficiently early,
- stick-handling missing code directly into distro trees before release,
- testing distro-supplied upstream kernels on our hardware and
- providing ready-to-install packaged drivers

... we do need to make it easy for launch-time customers to use their new hardware. We are not quite there yet IMO (although Navi10 was worse than normal) and are still working on improving that.

You asked a lot of questions related to RDNA2 and RDNA3 launch dates that I can't answer, sorry.

Thanks for the reply - but there were some misunderstandings.
1) Your `upstream' is much more than what I would wish for (even testing distros on AMD side ...) - and I am happy not to use Navi 14 which I aimed at before but Navi 10, as Navi 14 would be more problematic. But `worse than normal' may be about the problems with 5.3-5.5 for Navi 10 (which are RDNA1 specific, not Navi 10 specific - or is this guess wrong).
My impression is that AMD is always too late for distro support 3 months after availability which should be the goal (as you state the points to be cleared by AMD for the users products).
2) Sorry if there is a fault on my side - I have seen slides from AMD with years and I thought RDNA2 was this year and RDNA3 was next year - as I am still in the game as I need a backup with my former Intel systems being broken due to mitigations ... But if those years are correct, AMD would be late to include RDNA2 in Linux 5.9. I don't rise questions about availability ... but of cause your comment could lead to guesses about availability ... OK. So when saying it is not too late one would not expect a release this year.
3) My real question was for ROCm support and tooling support (in Mesa, for example: scaling option to no longer see little stamps on the screen would be nice for old games) for RDNA1 (i.e. Navi 10 [and 12+14) which should be answered as these cards are available - Navi 10 for an entire year - and I have not seen those two points answered yet.
But again sorry if I just missed that info but would like if you could clarify this.
4) Just an addition - maybe you can tell if DisplayPort 2.0 is about to be used by AMD with RDNA2 / RDNA3 ... or if DP is delayed like former releases - as first devices were expected end of 2020. Maybe you can say something about future use without giving yet to be announced AMD products.
From my point of view this and getting more efficient (performance per W - incl. less power consumption when idle) are the two improvements I want to see for getting my 2nd AMD system - which would be worth the upgrade.

But about quality under Linux I am really happy with Navi 10 using Linux 5.7.9 and Mesa 20.1.3 - no crashes or other problems ...
Before switching to AMD I heard of problems (especially in this forum) - which are not present with Navi 10. The current AMD system works better than the fresh Intel systems which both had problems not solved with Linux in one year (but 2-4 years later) ... so the quality with Linux is really good (except maybe the second point above, of cause - if that functionality has still to be completed).