AMD Radeon RX 5500 XT Linux Performance

[JMB9]

I think we are saying 8K HDR 60 Hz on a single DP 1.4 link with data compression for Navi10, and I expect the same would hold for other dGPUs in the Navi family.

Thanks for your two replies ... and I have to accept that AMD does no longer provide a future vision of even half a year - I just longing to get the times back where companies like IBM did 10 years visions and met their goals exactly.

So what you are saying is that one can hope (not 100% safe) that Navi driven dGPUs will always have at least DP 1.4 HDR and HDMI 2.0, so perfectly for 4k (midrange games) and 8k (work and low end of games). And this is exactly what I need (in the near future).
What I don't get is why this is not doable with an APU - i.e. CPU+APU with about 65 W TDP capable of 8k for work and 2k and sometimes 4k to play with.
That's exactly what Haswell provided with 35 W to reach 4k (and games in FullHD or little less) - with no screens available when Haswell was released.
From your formulation I should lower my hope to see an AMD APU with 8k max res within Navi family (or at least 5k).

I am curious - is AMD capable of testing 8k res right now - i.e. are there 1st prototype displays to be connected with 8k@60Hz via DP 1.4 HDR?
Even if this has nothing to do with future products of any company but with testing possibilities you may not be able to answer this.
I would be quite interested in knowing how Intel managed to support 4k without the HW available at the time they had 1st chips and how currently companies support 8k. 8k prototypes had been there when 4k came up for < 500$ - but not with the needed DP/HDMI standards.
It is funny that Intel "supports 8k" only with less than 20 W for ultra thin laptops (Icelake; while their 95+W monsters are stuck below 5k using DP1.2 and HDMI 1.4 like old Haswell) which can not even reach 35 W Haswell performance (i.e. bad at FullHD with
mid range games) and AMD seems not willing (due to small demand ... so maybe understandable) to support below 70 W capable of supporting 8k.

But with Navi 14 capable above 4k (5k and 8k) there is one last question still open:
Is the support for DSC 1.2 currently in place for Navi 14 so that 5k+ is supported with the next gen of distributions like *ubuntu 20.04 LTS with the free Linux graphics stack or at least with the AMD driver for Linux?
This should be possible to be answered by AMD - right?

[Slartifartblast]

The distance of this seems to be about 1-3 years into the future when AMD/Nvidia replace the current generation RDNA/Turing GPUs with the next generation RDNA2/Ampere.

Given that AMD is a process node ahead of Nvidia, I would have expected better, AMD should be worried about what Nvidia can do at 7nm.

Opens popcorn, closes wallet.

[Lanz]

Michael, could we get some testing of the mobile version of this card?

[Michael]

Michael, could we get some testing of the mobile version of this card?

Extremely unlikely, AMD has never provided me any mobile devices for testing.

[agd5f]

Thanks for your two replies ... and I have to accept that AMD does no longer provide a future vision of even half a year - I just longing to get the times back where companies like IBM did 10 years visions and met their goals exactly.

What exactly are you asking about? We do provide roadmaps for the future. All companies do. Obviously the further out you go, the less concrete things are. I doubt anyone know exactly what version of DP or HDMI will be prevalent in 10 years. I think you can expect most vendors will follow the standards.

So what you are saying is that one can hope (not 100% safe) that Navi driven dGPUs will always have at least DP 1.4 HDR and HDMI 2.0, so perfectly for 4k (midrange games) and 8k (work and low end of games). And this is exactly what I need (in the near future).
What I don't get is why this is not doable with an APU - i.e. CPU+APU with about 65 W TDP capable of 8k for work and 2k and sometimes 4k to play with.
That's exactly what Haswell provided with 35 W to reach 4k (and games in FullHD or little less) - with no screens available when Haswell was released.
From your formulation I should lower my hope to see an AMD APU with 8k max res within Navi family (or at least 5k).

I am curious - is AMD capable of testing 8k res right now - i.e. are there 1st prototype displays to be connected with 8k@60Hz via DP 1.4 HDR?
Even if this has nothing to do with future products of any company but with testing possibilities you may not be able to answer this.
I would be quite interested in knowing how Intel managed to support 4k without the HW available at the time they had 1st chips and how currently companies support 8k. 8k prototypes had been there when 4k came up for < 500$ - but not with the needed DP/HDMI standards.
It is funny that Intel "supports 8k" only with less than 20 W for ultra thin laptops (Icelake; while their 95+W monsters are stuck below 5k using DP1.2 and HDMI 1.4 like old Haswell) which can not even reach 35 W Haswell performance (i.e. bad at FullHD with
mid range games) and AMD seems not willing (due to small demand ... so maybe understandable) to support below 70 W capable of supporting 8k.

But with Navi 14 capable above 4k (5k and 8k) there is one last question still open:
Is the support for DSC 1.2 currently in place for Navi 14 so that 5k+ is supported with the next gen of distributions like *ubuntu 20.04 LTS with the free Linux graphics stack or at least with the AMD driver for Linux?
This should be possible to be answered by AMD - right?

I'm not sure what you are asking. We have access to new high res panels and we test them. On Linux at least, there is some core EDID functionality required to properly parse some of the newer 8k modes, but with that patched, you can use them depending on the asic. Raven doesn't support DSC, but as long as the bandwidth requirements fall into the capabilities of the chip is should be able to support most HBR modes. You might have to use multiple links depending on the color depth and refresh rate.

[JMB9]

What exactly are you asking about? We do provide roadmaps for the future. All companies do. ...

Well, in former times there would have been an announcement e.g. for something like DP2.0 that Intel will use it starting <Product> and AMD will use it starting with <Product> - and not going back to DP 1.4 with a product released after that point of time ...
CPU roadmaps would have month/year - structure size - number of transistors - cache sizes - pci version - TDP range - ... going years in the future. This had been possible (I know Intel provided those data till dropping such roadmaps altogether - I had been in the Intel camp since 8086 wiht IBM PS/2 model 30 in 1997).
So no, I am not aware of current roadmaps from Intel or AMD - PR material, yes - but no technical roadmaps.
And news articles speak of "leaked info" as the manufacturers won't give it, e.g. structure size of future Intel CPUs would be 1.4 nm in 2029 (provided by e.g. Heise two days ago - and yes, TDP is not given, so doing this with TDP 1 mW {yes, 0.001 W} will qualify to have reached that goal - sorry for extrapolating current conditions to the future - old tradition as scientist ).
It there would be roadmaps, one could tell me e.g. "APUs supporting 8k res are expected in, e.g., June 2019 - and not being forced to say
`Sorry, as always "unable to comment on possible future products" ' - so these are confidential info under NDA (which I do respect!) - roadmaps from news magazines should be open information anyone can get and share - and "leaked information" should not be possible at all as this indicates that someone did illegal things to provide that information (leaked info should be legal if criminals are revealed by that, of cause).

But it is much worse - a product is available (e.g. Navi 14 - bad example as all technical news sites do give these data in THIS case) and you don't get info about DP and HDMI versions.
PC Builders ask manufacturers as they don't have standard info for products sold by them for months (not kidding - they could not tell me what maximum resolution Raven Ridge has - especially as one can find statements that `Vega is internally 8k capable' ... very interesting, isn't it).
And I was told it would be chipset limited on purpose - whatever that should mean.
From my point of view: if information is not available speculations and lies can prosper - no company should want this ...

I made a request at AMD to get info for APUs and got
"The maximum supported resolution with integrated graphics will depend on the motherboard being used and what type of display connections are available to the integrated graphics via the motherboard." so "with motherboard ... you get DP ...", and I don't get the point AMD did not nail such specifications so e.g. 3400G can be stated with max resolution ...
and force vendors to use the required parts. And of cause to keep standards fully so Linux will run without problems ...
IF such basic information would be given (sometimes I have the impression it is more chance than purpose what port version is used), the former statement "I expect the same would hold for other dGPUs in the Navi family" would not be given but Navi dGPUs and APUs will have at least ... - as updates could be possible. AMD could have clearly stated that as Navi was optimized for 4k and 8k it will provide DP 1.4 HDR and HDMI 2.0 "or higher" - but this seems not to be the case. I don't think it is much cheaper to use of DP 1.2 and HDMI 1.4 - which should have been died when DP 1.4 and HDMI 2.0 got available in production amount.
Looking on AMD technical specification you can see DP yes, HDMI yes - sorry, but these are not technical data, are they?
And now I hope it is clear what I want to see as roadmap - clear technical details in a timeline - as was standard in former times - nothing unheard of.

I'm not sure what you are asking. We have access to new high res panels and we test them. On Linux at least, there is some core EDID functionality required to properly parse some of the newer 8k modes, but with that patched, you can use them depending on the asic. Raven doesn't support DSC, but as long as the bandwidth requirements fall into the capabilities of the chip is should be able to support most HBR modes. You might have to use multiple links depending on the color depth and refresh rate.

{Just out of focus: you mention DSC along Raven Ridge - is Vega not limited to DP 1.2 which was specified without DSC or did I miss something ... I got hints from AMD people that for 8k I should look towards Navi ... as DP 1.4 spec has DSC ... and Navi was optimized for 4k and 8k ...}

Yes, that's exactly what I was interested in - and I would ask: is Navi 10 and Navi 14 tested with 8k@60Hz using DP 1.4 (i.e. one cable; MST is a mess) and running with the free Linux stack or at least with the AMD Linux stack?
And I may get the answer yes, it was tested with Motherboard ... with Revision ... - no, I had been too long in IT business to be amused - shocked would meet it much better.
And as both products are available the AMD developer could provide that information - and IF necessary with a huge table giving boards and versions which will work under GNU/Linux.

I am going further to ask "why were the Linux users not warned that Raven Ridge is not working with Linux and the free graphics stack" .... I read it first here on Phoronix - that was nice as I would have bought one - but I would feel much better if that warning came from AMD and Phoronix would report "as informed by AMD we got trouble with ... AMD will report when this got fixed" or something similar.
I might get the answer if I would create a request for this that Raven Ridge will work but the chipset for ... was buggy which is not the responsibility of AMD.
Right? So what is the lessons learnt by users? You can not be sure AMD product work under GNU/Linux even in case free drivers do exist due to problematic chipsets.
I would wish AMD, people using GNU/Linux, and all people providing technical news to be able to give/get statements about compatibility.

Thus a "Linux conformant" label {not limited to the kernel, i.e. incl. Mesa and Userspace - but LF won't use the term GNU/Linux I assume} provided by Linux Foundation would be a good idea - as we have found too much examples for which it went miserably wrong - and this situation appears not to improve.
And I don't want to blame AMD {at least alone} - when Intel Skylake appeared, it was even a larger disaster (they got it later - much later - so maybe Raven Ridge might work some times ... maybe) - and there was an Intel controller only supported in a special mode under Linux - and Motherboards of ... (ASUS provided an aged but interesting list about their motherboards and Linux compatibility - at least Google can find it - and other may have or at least should start providing info, too).
And I just wonder why problems are not known the day the product is officially released. That would be possible ... in most cases at least.
I ran a test set to get go for new workstation HW for an automotive company - after getting good testers we got really good results and typically fixed all problems BEFORE those new system and Unix images got available.

And what I would wish for is just AMD providing information about Linux support of a product (e.g. "runs on Linux despite ability to overclock" or whatever may cause trouble or is simply not available [yet - which should be updated when ready with e.g. "using Mesa 20.3+ and Linux 5.8.0+"). Too much to ask for?

Personal bottom line: I will try to get a customized PC from a builder I know to make it as silent as possible with e.g. Ryzen 5 3600 (Zen2) & Radeon RX 5500 XT (RDNA Navi 14) and will make sure an image like L|Xubuntu 20.04 LTS with minimum kernel and Mesa as given by Phoronix is available (about Feb.+) and will test it myself as far as can right now (up to 4k).
And when 8k screens are available for < 600$ I will buy one and if it won't work I will learn a lesson and replace the graphics card (new thing when using iGPUs for more than 10 years).
So I have to test it myself and may give the PC back or pay a price in wasting a graphics card + losing last bit of trust in statements of the involved companies.
In that case maybe the next but one would be a POWER, RISC V or ARM CPU ... in 2026 or so ...
Linux Torvalds is right very often ... in some cases it would be better if it isn't so and the world would be a better place ... )

But there is still hope that things improve [or using the business term: "Lessons Learnt"] - with clear technical data and a clear statement about Linux support ... which may require several changes ... and learning several things from the past which were right and are just screwed today (not isolated to a single company - just hinting on scientific papers before 2000 about possible security problems with OoOE - long before Spectre&Meltdown was even coined as terms ... with shiny CPU manufacturers involved ... absolutely not limited to PCs).

[bridgman]

What I don't get is why this is not doable with an APU - i.e. CPU+APU with about 65 W TDP capable of 8k for work and 2k and sometimes 4k to play with. That's exactly what Haswell provided with 35 W to reach 4k (and games in FullHD or little less) - with no screens available when Haswell was released.

For clarity, I'm not saying it will not be do-able on APU - if anything APUs tend to pick up new display engines faster than dGPUs - it's just that I can't talk about APU plans without getting into that "unreleased products" thing.

Talking about future products is a marketing/business team responsibility; we're not going to be doing it from inside the engineering teams.

[JMB9]

For clarity, I'm not saying it will not be do-able on APU - if anything APUs tend to pick up new display engines faster than dGPUs - but I can't talk about APU plans without getting into that "unreleased products" thing.

Talking about future products is a marketing/business team responsibility; we're not going to be doing it from inside the engineering teams.

Thanks for this clarification. As being conservative I at least had to assume it is not safe that a Navi APU would be 8k capable. But of cause I am aware of your situation and I won't demand something I would not provide if I would be in your position.
So if a Navi APU is released before I had to buy a PC, this might be an option.

Concerning worldwide energy concerns I think a Zen2+Navi with 35 to 65 TDP would be a great system - for most office and even for workstation usage.
And if I haven't made wrong guesses Raven Ridge (and even a 35-65 W Icelake - which doesn't fully reach Raven Ridge performance) would be enough to work with 8k (desktop publishing, image manipulation etc.) and to play games in FullHD and even some in 4k.
Thus 120 W is a lot - but if it is not used it consumes 7 W (I read it for Windows - and it is about the threshold in the graph `power consumption monitor' of this article) so it would not hurt that much even concerning my workflow.

And I think that Nvidia is wrong that iGPUs/APUs are just there to be replaced by a dGPU - which of cause is neccessary to play high quality/graphically demanding games.
So having the fastest CPU/GPU out first is OK - but I would wish for an APU at least half a year after the architecture (RDNA Navi in this case) was introduced and to be announced the day the 1st Navi product is released (which was done in the past).

I think this should have advantages even visible for marketing/business team ... while announcing things longer (as was common in the past) could cause problems if competitors don't make such early announcements for the future and thus could react to be superior (concerning marketing at least).
Maybe the users had more power or must be pleased in the past - at least business customers do have access to such roadmaps (even not under NDA, just my personal experience).

[Danny3]

My experience with MSI Radeon RX 570 ARMOR in Linux:

Zero RPM does not work in Linux. By default the fans are rotating at about 1000 RPM in idle and at 2000+ RPM under load in case of this GPU. 2000+ RPM is very audible (unless wearing headphones). If the user wants zero RPM with this GPU, he/she will have to find (or develop) a small app watching the GPUs temperature and adjusting RPM via files in the directory "/sys/class/drm/card?/device/hwmon/hwmon?". Setting fan rotation below 250 RPM will physically stop the fans (zero RPM).

The idle power consumption is about 8 Watts with amdgpu.ppfeaturemask=0xffffffff on kernel command-line, and about twice as much Watts without the ppfeaturemask. However, using ppfeaturemask might result in heavy display flickering when multiple displays are connected to the GPU, which can be solved by manually (or via a small script) fixing the GPU's memory clock when multiple displays are connected and disconnected.

The RX 570 GPU halts the system about 20% of the time when the system is resumed from suspend-to-memory, which basically means that you won't be able to suspend your machine ever if you want to avoid the risk of the machine failing to resume.

This is very bad and one of the main things that make me feel disappointed about AMD.
I assume the case with Navi it's the same.
I wonder if AMD will ever release a control panel where we can change these things like human beings...

Thank you very much for sharing this!

[Danny3]

just to let you know, HDMI does not support freesync. Not on Linux: https://www.amd.com/en/support/kb/faq/gpu-754

• FreeSync via HDMI is not supported for this feature. Only DP FreeSync displays will work.

Better buy display port cables

I know that HDMI does not support Freesync.
I am more interested into High freame rate at 4K, anything over 60 Hz, let's say 120 Hz.
And DisplayPort is good, but it's mostly for monitors only, I haven't seen yet a tv with it, just with HDMI