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

[nissen22]

The big effort is getting RDNA1 support in - I expect that RDNA2 and subsequent generations would be enabled and tested as soon as RDNA1 support and RDNA* HW became available. We have certainly been doing that with the lower level ROCm components.

If you are saying that RDNA support (not just CDNA) is in the works, perhaps you could correct some of the statements in this github issue?

If I knew I could do machine learning with consumer grade AMD GPUs I would buy into RDNA2 in a heartbeat as I plan on committing 100% to Linux gaming in Wayland with my next pc build (but I also need to be able to run Tensorflow and Pytorch)

[bridgman]

Yep, you're asking all the right questions.

[JMB9]

... although we don't normally talk about our customers as "the masses"

Thanks for your reply ...

``The masses'' was meant to describe those people not spending too much time in looking for PPAs, building kernels, creating boot images, changing graphics cards or harddiscs ... just to get a system up and running - not indicating something along the lines of lack of knowledge or inferior quality of work - as they use GNU/Linux and AMD.

[bridgman]

Ok, ROCm have to wait ... but one year is long ... support for RDNA1 when RDNA3 may be sold would be ... sub-optimal. So this priority should soon change.

The big effort is getting RDNA1 support in - I expect that RDNA2 and subsequent generations would be enabled and tested as soon as RDNA1 support and RDNA* HW became available. We have certainly been doing that with the lower level ROCm components.

And concerning tooling my point was about old (and no longer really supported) games running in `Fullscreen' with big black fringe and using only a tiny area of the screen. Some gamers mentioned using tooling for AMD (and Nvidia) cards to correct for this using "scaling option" ... there is tooling in Mesa but I am not aware of the capabilities ... will have to check.
But being curious - is AMD actively helping on this front? I am sure this would be very welcome!

Again, I thought this support was built into SDL2 and available today. Don't remember hearing about a scaling option in Mesa but will go look.

This leads to coming back to your support point - another misunderstanding on my part.
I thought you meant all those points being addressed by AMD - not at least one of this.
Actually GNU/Linux support means being in Kernel and Mesa - it is nice to have an alternative though.
So when buying a new system it's necessary to have graphics support at first boot (or it gets complicated ...).
Thus only Kernel & Mesa (incl. RADV) counts ... some additional drivers are typically not provided by (all) distributions - and lead to introducing the tainted flag in the kernel.
So off-tree components (concerning Kernel and Mesa) don't count concerning that support - as we typically don't buy workstations or computers with Linux preinstalled and have to rely on components being part of all current distributions.

But maybe I got the second statement wrong concerning "sufficiently early upstream support was only one of those".
My use of "sufficient" means that the masses running a current GNU/Linux distribution can use the card right from the start - booting the unchanged image with the new card. Right?

Right.

Strictly speaking either "sufficiently early upstream" or "stick-handling missing code directly into distro trees before release" would enable the masses in the way you describe...

... although we don't normally talk about our customers as "the masses"

[JMB9]

Can you help me figure out which is the second point ? ...

Thanks for clarifying some points.

My second point about lacking functionality was about tooling and computing stack for Navi.

Ok, ROCm have to wait ... but one year is long ... support for RDNA1 when RDNA3 may be sold would be ... sub-optimal.
So this priority should soon change.

And concerning tooling my point was about old (and no longer really supported) games running in `Fullscreen' with big black fringe and using only a tiny area of the screen. Some gamers mentioned using tooling for AMD (and Nvidia) cards to correct for this using "scaling option" ... there is tooling in Mesa but I am not aware of the capabilities ... will have to check.
But being curious - is AMD actively helping on this front? I am sure this would be very welcome!

This leads to coming back to your support point - another misunderstanding on my part.
I thought you meant all those points being addressed by AMD - not at least one of this.
Actually GNU/Linux support means being in Kernel and Mesa - it is nice to have an alternative though.
So when buying a new system it's necessary to have graphics support at first boot (or it gets complicated ...).
Thus only Kernel & Mesa (incl. RADV) counts ... some additional drivers are typically not provided by (all) distributions - and lead to introducing the tainted flag in the kernel.
So off-tree components (concerning Kernel and Mesa) don't count concerning that support - as we typically don't buy workstations or computers with Linux preinstalled and have to rely on components being part of all current distributions.

But maybe I got the second statement wrong concerning "sufficiently early upstream support was only one of those".
My use of "sufficient" means that the masses running a current GNU/Linux distribution can use the card right from the start - booting the unchanged image with the new card. Right?

[bridgman]

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).

Sorry, I think of Navi10 and Navi14 as pretty much the same code, so comment applies to both.

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).

IIRC we had been doing better than that, other than unrelated delays in Vega10 from getting DC/DAL accepted upstream.

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.

I don't remember saying that upstreaming in 5.9 on its own wasn't late (what I said was that there were several ways to provide launch time support and having sufficiently early upstream support was only one of those) so please don't make any conclusions based on what I didn't say

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.

My impression was that SDL2 included code to automatically upscale older games - is that not correct ? I had not thought of this as something that needed to be implemented explicitly in Mesa.

I have said a few times that we are working on Navi support for ROCm, that the lower level parts of the stack are running well but that we have a few higher priority things to finish (not related to Navi ROCm other than competing for time) before we can get the rest of the stack ready. Won't have a committed date until the higher priority tasks are done.

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.

No, I can't say something about future use without giving away info on 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).

Good to hear. Can you help me figure out which is the second point ? I looked at the text following "2) " above but it didn't seem to fit.

[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).

[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]

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]

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.