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

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

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]

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]

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

Yep, you're asking all the right questions.

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