AMD Sends In More Radeon "Navi 2" Updates For Linux 5.10 Kernel

[JMB9]

I reckon that most RDNA2 owners that use AMD supported distributions will be just fine since they'll have access to AMDGPU-Pro which, traditionally, has better launch support than using a distribution provided, open source driver. Users outside of the AMD supported distributions, it'll depend on their level of skill on Linux and how easy their distribution makes it to add new kernels and firmware to add support.

Since Ubuntu is one of AMD's supported distributions, you should be just fine buying one when it's released. That said, I'm gonna sit on my RX 580 until I start seeing favorable RDNA2 posts around these parts. I'm still very happy with my RX 580 and mostly ultra settings getting a very pretty 1080p60 in most games.

You may be right that one can get early support via the proprietary stack - but officially only supported on outdated Ubuntu version (LTS) you won't use with fresh HW.
Concerning this being the inferior solution I would state three additional arguments:
1) As reported several times on Phoronix the free Linux/Mesa stack is much better (faster and more stable concerning games) than the proprietary driver (but the latter is welcome, as most parts are available as open source and contribute to the good quality of the open source stack).
2) Additionally I personally think that it is much easier to install fresh Kernel and Mesa via PPA than to use the proprietary driver (I downloaded it, read their instruction for installing and the supported distro versions - and decided that it is even not worth trying for me - and I have worked more than a decade as Unix expert and using GNU/Linux on my personal computers since 1994 - but others are allowed to come to different conclusions).
3) The last point is that you need the distribution to come up to update/install things - AFAIK no desktop distro comes up with any proprietary driver - so the distro should have initial support for the used HW.

To make the third point clearer:
With Navi 10 (07/2019) - 1st card of Navi 1 to get available - it was Ubuntu 19.10 `Eoan' (no stable use, but a good start to install from PPAs and to thus get a stable system).
With reasonable assumptions for future Navi 2 it looks like Ubuntu 21.04 `H*' may be the 1st with initial support (as 20.10 is expected to come with 5.8 kernel - which has landed in the daily image for Groovy a few days ago - but Ubuntu 20.10 may have 5.10 or even 5.11 kernel, as STS releases are normally quite fresh concerning Linux, Mesa and X.org as those become the HWE stack for the freshest LTS; so e.g. Groovy will be used for Focal 20.04.2) - with AMD info stating that we will see RDNA 2 this year and RDNA 3 in 2021 - latter being the 5 nm die shrink (I think slide by AMD shown at Phoronix some time ago - but if wrong it may be corrected by one of the official AMD developers who are quite helpful in this forum to clarify things). So getting started with Navi 2 short after release date would require expert knowledge (like working on text console as no graphics is available, swapping HW like root disk or graphics card ...) - not something for beginners concerning system administration.

I really wish we could get back to the procedure of the good old days when we were clearly informed when products would be available and which features will be introduced more than 1 year before it happens (knowing e.g. the 1st product of each vendor using DP 2.0 would be quite helpful).
IBM even delivered precise roadmaps ten years in the future - and really kept them!
Therefor we are forced to do speculations to do the planning ... suboptimal ... but still not that bad ...

[bridgman]

We package two versions of the graphics stack - one using Mesa for OpenGL and one using the proprietary OpenGL WS driver. Right now the newest consumer and LTS versions of Ubuntu are the same (20.04) so as long as you don't update to 20.10 the moment it comes out you should be OK for Navi21 launch.

The packaged driver userspace can also be installed on top of the distro's built in kernel or on top of a newer kernel packaged by the distro maintainers, although we need to fix up the install instructions to make that more clear.

My understanding is that 20.10 will ship with the 5.8 kernel, for what it's worth.

I know CPUs have historically had a fair amount of advance visibility into the roadmap but I don't ever remember seeing that in the GPU market. Did I miss something ?

[JMB9]

We package two versions of the graphics stack - one using Mesa for OpenGL and one using the proprietary OpenGL WS driver. Right now the newest consumer and LTS versions of Ubuntu are the same (20.04) so as long as you don't update to 20.10 the moment it comes out you should be OK for Navi21 launch.

The packaged driver userspace can also be installed on top of the distro's built in kernel or on top of a newer kernel packaged by the distro maintainers, although we need to fix up the install instructions to make that more clear.

My understanding is that 20.10 will ship with the 5.8 kernel, for what it's worth.

I know CPUs have historically had a fair amount of advance visibility into the roadmap but I don't ever remember seeing that in the GPU market. Did I miss something ?

Thanks for your post!

Yes, the proprietary driver supports 20.04 - with version 20.30 it was said Radeon Software for Linux for Ubuntu 20.04.1 and RSFL for 18.04.4 - short before 18.4.5 was released with 20.04-Focal-HWE stack. So after that update - Radeon Software for Linux will no longer work - or maybe with luck?
So saying something about kernel versions supported (or other important components) may be a good thing - but those are aimed at LTS/SLE/RHEL distributions and there may even problems with STS versions.
Now the question is if one would ride mainline kernel - saying always starting with x.y.3, would it be reasonable or even possible to use a proprietary driver? I don't think so - but I may be wrong.

I will buy a new AMD system `soon' {directly after buying a system starting planning phase ... just for redundancy} - but it may be more than 2 years from now to see a difference - so Navi 3 - maybe an APU with that 5 nm die shrink - may be a good fit (if such APU are there: DP 2.0, 4k and 8k optimized ).

But even if I would want to get Navi 2 soon, I would use Groovy (20.10) but would buy Navi 2 when 1st distro with initial support gets available
to boot with (which may be 21.04 - which I would install one month before release) and would ride mainline kernel and Mesa to get support in shape.
Focal (20.04) was a really bad desktop system with components even older than before concerning former LTS releases. 19.10 had kernel 5.3 - 20.04 5.4 (and many big backports - reasonable for servers but never a good thing for the desktop) - application stack not really better in that respect (not to speak of the interesting packaging problems: deleting no longer used packages resulted in advertising to drop core packages ... nice ... which was fixed a few weeks after release - maybe I am installing too much ).
The first Focal version usable for me will be 20.04.2 - with a lot of PPAs - and maybe as KDE Neon to have a current and stable KDE stack and using it as reference - but working on current STS.

I thing that the proprietary driver is good for workstations (with certifictions being the big difference) which tend to have older components than the desktop and using tested and proved distributions (e.g. used for CAD/CAE - I worked here as Unix specialist for 5 years - and all people were happy when AMD won and not Nvidia ... clear sign of being a Unix guy ). But those well tested distros are from my point of view outdated - even from the point of a researcher ...
And this is not to blame AMD - it is great that they support the community with code and information which enables the free stack to be better than the proprietary driver. Would be easy to stop that when no longer playing fair (examples exist for that behavior) - so this is something which shows that Linux users buy AMD components for a very good reason.

We used in the 2nd half of 1990ies Debian Unstable without problems (testing updates on one machine and only updating all when it was working - with about 2 disruptive updates per year - a colleague was really good at stopping those to get installed on all systems) in an astrophysical research institute.
I don't think the pace slowed down concerning SW - it is only the HW which is really slowly changing (8k screens ... with first versions shown before 4k got cheap in 2015 - now more than 5 years later not even announcements ... that's impressive; CPUs are not remarkable on the desktop about speed - but USB and SSDs are - but CPUs show nice development - but no wow effect here: i.e.factor 2+, not just 10%+ which is nice but no game changer).

Roadmaps - well, in former times CPU was king - the most decisive component - thus the roadmaps of CPUs was what people want to see - and star performance diagrams of Intel - Alpha - ... CPUs concerning the 1990ies. Graphics card got important when (I don't know why; maybe you can explain it) roadmaps were NOT introduced. That is true. Who cared about accelerators when 3dfx were number 1? Private computers had typically Nvidia - was fun till the proprietary driver bites.
As stated above in astrophysics working on 2k x 2k CCD frames we used Matrox cards. It worked.
And now - when resolution is important - framerates (mostly gamers, videos are no problem even with 4k on current HW - this is not Polaris - and I would hesitate to open it for Vega ...) - and color depth (high color, true color, ...). So DP version is decisive.
So it would be nice to know "AMD will use DP 2.0 from ... onward for the entire line of GPUs and APUs" - this would be a wow effect of information, wouldn't it.
And thus I am frustrated or even angry when reading "DP - yes" even on pages of one of the most import graphics vendors - AMD.
You remarked that my term "the masses" is not what people use - but maybe you can explain who think "DP - yes" is information ...
And I would not dare to use any term here but say that speaking with students I explain that HDMI is for TV and not for professional usage as bearing a lot of shortcoming ... and DP is the professional one - starting to explain the importance of the versions and what results from a given transfer rate.

So my point stays valid (at least for me) - why were real roadmaps stopped (like a general agreement) on CPUs and why were roadmaps not introduced when the graphics card was no longer a dump device like an interface card for serial port but of similar weight like the CPU?
And where can one find information about DP port versions directly on release date?
And is there a place were AMD reveals which functionality is implemented in the open stack right now and which components are missing - and maybe even giving a deadline (e.g. computing stack for Navi should be ready when 1st computing card is released ... so that may be a hint of an internal roadmap - and I am sure AMD has one)?
To give an example - I want to connect an 8k screen with my Navi 10 as soon as it gets available.
On Phoronix (https://www.phoronix.com/scan.php?pa...r-In-Mesa-20.2) it was said about Mesa 20.2 "With Navi 1, the display DCC support was flipped on for only Navi 12 and Navi 14". So why is Navi 10 missing (the flagship product) and what are the implications. If 8k screens were there right now - would Navi 10 with Linux 5.7.17 and Mesa 20.1.5 be able to reach [email protected] with one cable?
[Hoping for a clear: "Yes!" here - while for DP - yes ... well ... I think you got it ]
Similar concerning the configuration or even tweaking tool. Is AMD supporting ADRICONF (I have not used it yet - but this is the official Mesa tool if I am not wrong here - i.e. would it provide similar functionality to the former AMD Catalyst Control Center - and if not, could AMD help in that respect)?

In the 1990ies everyone new what the HW was capable of ... and today information about that is hard to get - and as SW is evolving to get all functionality in place (lasting more than a year after release of that HW), there is a lot to wish for.
Thus stressing the need of roadmaps to plan, thus asking to have a place to show the current supported HW features (concerning DP/DSC/8k it would not be Mesa but the kernel side - amdgpu - or even both ...?) to keep tracking of what is already done and also full information in release date to know the deployment possibilities of that HW. Maybe also relevant for Linux Foundation?
Therefore hoping for more AMD developers improving the functionality of the free stack faster than it is today.

So I am happy with current Navi 10 with an 31.5" screen with 4k - but I wish for knowing before buying a card that it works - and maybe this is up to try and error - as the screens are simulated - but not tested as they had not been available when the card was disgned. So maybe asking to much ... but maybe you can even shed light on that question - at least in a more general way.

Thanks for your engagement!

[alex79]

Electricity isn't getting cheaper, wages aren't going up but PC's are getting more power hungry every year, need more physical space and need constant upgrades if you change 1 component. This sucks.

[skeevy420]

Electricity isn't getting cheaper, wages aren't going up but PC's are getting more power hungry every year, need more physical space and need constant upgrades if you change 1 component. This sucks.

Depends on how you look at it and what your target goal is. For example, take gaming at 1080p to 2K. At most we need an 8c16t and a sub-$250 GPU for pretty good results and most can get away with a 4c8t processor for that task. Everything in that range has been getting more and more efficient every year. 2K and under gaming and office systems -- those get less hungry every year and can be made into smaller and smaller form factors. All that will especially be true once the AMD 4000 and 5000 series CPUs and APUs are released on the CPU side.

On workstations and high end gear: every generation has increased core count at the cost of keeping power usage the same as the previous generation. Someone gaming over 2K, yeah, they need stupid-large GPUs that consume lots of power to use equivalent settings. Nvidia has reached their limit on efficiency so now they're releasing really-stupid-large GPUs that need their own power plants to operate to push lots of flash at 4K.

I don't expect Big Navi/Navi 2/WTF Ever to be any different. I predict that the 1080p/2K GPUs will be more efficient while the 4K+ GPUs, while technically more efficient, will still be stupid-large power suckers.

[Apoll]

Thanks for your post!

Yes, the proprietary driver supports 20.04 - with version 20.30 it was said Radeon Software for Linux for Ubuntu 20.04.1 and RSFL for 18.04.4 - short before 18.4.5 was released with 20.04-Focal-HWE stack. So after that update - Radeon Software for Linux will no longer work - or maybe with luck?

Actually the AMD distributed "pro" driver is still open source and not "proprietary"

[pal666]

But it is looking like AMD isn't going to be even remotely competitive on the graphics side any more.

did you get that feeling out of novideo slashing prices?

[pal666]

Next AMD video card series
codename = "BigNavi" (Not 100% but have seen this codename being used to online.)

bignavi refers to big navi card(i.e. higher end than rx5700)

[pal666]

For example, take gaming at 1080p to 2K. At most we need an 8c16t and a sub-$250 GPU for pretty good results and most can get away with a 4c8t processor for that task.

you forgot to define refresh rate

I predict that the 1080p/2K GPUs will be more efficient while the 4K+ GPUs, while technically more efficient, will still be stupid-large power suckers.

power limit of navi2 cards is already leaked in macos drivers, you are late with predictions

[skeevy420]

you forgot to define refresh rate
power limit of navi2 cards is already leaked in macos drivers, you are late with predictions

Because I figure that it's safe to assume either 60Hz fixed or some VRR range these days.