AMD Radeon RX 7900 XTX + RX 7900 XT Linux Support & Performance

[AdrianBc]

Just installed my new 7900XT. Arch Linux, linux 6.1 from testing, mesa git (desktop wouldn't launch with something about gfx11 not being supported architecture).

Multimonitor power usage is a problem. I see my wall power drop by about ~60W when I turn off a monitor. But it is a 2560x1440@144Hz so that's not free either.

Games seem to run well initially. Waiting for the ROCm compile now to see if/how ML will work. AMD advertised ML this time around so it should work better. Right? I'm not particularly hopeful...

AMA or let me know if there's anything you want me to run/test

Please run some OpenCL benchmark that provides FMA throughput for both FP32 (single precision) and FP64 (double precision), for example clpeak:

https://github.com/krrishnarraj/clpeak

You could also run a benchmark that does the same thing using Vulkan, e.g. vkpeak:

https://github.com/nihui/vkpeak

This will show whether RDNA 3 supports FP64 or not.


You could also run ViennaCLBench:

https://viennaclbench.sourceforge.net/

https://sourceforge.net/projects/viennaclbench/files/

[Mahboi]

I could see someone getting eye strain from a low PPI monitor due to fuzzy/blurry text. I stick with 27”/4K and haven’t had an issue.

Every user I’ve given a 27” 1080p monitor to they complain about the blurry text.

Exactly. The crispness of every line is amazing. Coding is better, docs are better, web is better. If I had the card for it, 4K gaming would certainly be better, but no rush for me.
My little rx 6600 manages to get 3 to 4 Go consistently filled in its ram just running browser windows with 2 4K monitors though, a thing to consider, 4Go really is far too little these days. (Arch/KDE Plasma/Wayland)

[Mahboi]

For playing games or watching movies, it may be claimed that the benefits of 4k vs. 1080p are not essential.

However for reading text, it is objectively true that "the text reading experience is incomparable".

At desktop monitor sizes and 1080p resolution, there are too few pixels per character cell to render correctly any beautiful typeface.

Only the simplified typefaces with uniform line thickness and without contrast between thin lines and thick lines can be rendered acceptably well, e.g. Helvetica, Arial, Tahoma, Courier and many other such typefaces.

Wow, a true Font nerd! Rare breed!
Back in my student days I was told by a lad to try https://github.com/belluzj/fantasque-sans.
Never stopped using it in terminals or VScode since. It's excellent for long reading sessions. How do you feel about it?

[agartner]

Please run some OpenCL benchmark that provides FMA throughput for both FP32 (single precision) and FP64 (double precision), for example clpeak:

https://github.com/krrishnarraj/clpeak

Here's the clpeak output: https://gist.github.com/gartnera/4b9...b12e25c2b645db

[AdrianBc]

Here's the clpeak output: https://gist.github.com/gartnera/4b9...b12e25c2b645db

Thanks a lot for these results.

They show that FP64 has not been removed in RDNA 3, but the FP64:FP32 throughput ratio has been reduced, from 1:16 in the previous AMD consumer GPUs, to only 1:32, like in the NVIDIA GPUs up to Turing, or like in the NVIDIA "professional" Ampere GPUs (the NVIDIA "consumer" Ampere & Lovelace GPUs have an 1:64 ratio).

It has been super annoying that AMD has not published this essential information.

The 1:32 ratio was actually the most probable variant, because this means that they have kept the same FP64 execution units from RDNA 2, while they have doubled the number of FP32 execution units in each compute unit.


Nevertheless, there is little practical difference between the reduced 1:32 ratio and completely removing the FP64 execution units.

At an 1:16 ratio, the AMD GPUs would have still been competitive with CPUs for doing FP64 computations.

At an 1:32 ratio, the AMD GPUs have both a worse performance per dollar and performance per watt than CPUs (for FP64).

Moreover, an optimized software implementation of FP64 on GPUs should achieve a better ratio than 1:32, while a ratio better than 1:16 would not have been possible.

Unfortunately, no such software implementation exists yet. There are many libraries that implement FP128 with FP64, but implementing FP64 with FP32 is a much more complex task, because it is not enough to increase the number of bits in the fractional part, but also the size of the exponent must be increased, to avoid the frequent overflows and underflows that would happen when using FP32 exponents in scientific computations.

[sobrus]

This one line crosses out EVERYTHING you just said. 1600$, or 2000 Euro here in EU(wellcome to VAT TAX) - can be a freaking month of salary for a gamer.
And no, 30 FPS is not acceptable and 60 is too low in modern days. Not a valid argument. I mean, I can say, it's acceptable playing pacman as for of entertainment. It is still entertainment. NO. Just no.
Compare prices for gaming consoles and just GPU unit on it's own. It's crazy. I can't wait to see justification by AMD/NVIDIA for putting same more or less GPU units into Peasant Boxes for fracture of price of current GPUs.

Their predatory tactics it killing PC market. I starting to considering other less expensive and healthier hobbies. This is not a good place for monopolies to be in, where core customer consider to switch over to other industry.

60fps not enough? well, I beg to differ. It's certainly enough for me. And for millions of players on modern home consoles (which may not reach even 30fps sometimes at the end of their lifespan).

And Amiga, even though it was great value, it was actually VERY expensive. Wikipedia states that the simplest vanilla A500 was, in US, worth equivalent to $1,670 in 2021.
Nice price for a toy. Amiga 3000 would set you back over $8000 today (this model, however, was not just a toy).
(btw here in Poland even the cheapest model was worth literally YEARS of average income. Yes. Years. Compared to an Amiga in the 80s, 4090 is actually super cheap for me now, including 23% VAT. I can actually buy it without selling a house)

But everything is getting more and more expensive these days. For me, especially RX7900XT is overpriced. It should have been called a $650 RX7800XT. There are several reasons why it's getting so expensive. Look at the camera and lens prices, everything is getting CRAZY expensive these days. If RX7900XTX costs $999 then 4090 price, given how expensive to manufacture it must be compared to radeon, and how much feature complete and much faster with DLSS3 it is, is actually justified.
And Ryzen actually got more expensive than Intel nowadays so AMD is not a Robin Hood either. Intel ARC were expected to take prices down, but in fact they are vastly overpriced too.

If China invades Taiwan, where all Apple, nVidia, AMD and intel GPUs and many many more chips are being manufactured, you will consider current prices dirt cheap.

[AdrianBc]

Wow, a true Font nerd! Rare breed!
Back in my student days I was told by a lad to try https://github.com/belluzj/fantasque-sans.
Never stopped using it in terminals or VScode since. It's excellent for long reading sessions. How do you feel about it?

I have discovered Fantasque Sans Mono only a few months ago, but I like it very much for programming languages and for command line interfaces.

I like the excellent readability, the well-distinguished characters that are otherwise prone to confusion, the true italic style, the ligatures, the support for Greek and Cyrillic.

I find cute that the Regular style contains a few characters that are Italic, not Regular. Nevertheless, I think that it would have been less distracting if the tradition had been observed.

Because the author was inexperienced, the font metrics are wrong. When using Fantasque Sans Mono, it must be set to greater point sizes than normal, e.g. to 14 pt. for matching only approximately other "Mono" typefaces that are set at 12 pt. (which are designed to match typewriter Pica fonts, like IBM Courier).


Unfortunately, even if Fantasque Sans Mono is as good as the best programming fonts, e.g. Cascadia Code or JetBrains Mono, in some of my programming environments I want mathematical symbols, which are missing from Fantasque Sans Mono.

Therefore, even if I do not like the squarish forms of the JetBrains Mono letters, and I would have liked better Fantasque Sans Mono, because JetBrains Mono has the best Unicode coverage, and it also includes all the features needed in a programming font, that is the one that I most frequently use for this purpose.

[AdrianBc]

I didn't try that font yet, but obviously I will.

My favourite font for coding is Source Code Pro (usually at "regular" weight).
Here are my notes about Source Code Pro font:
- provides 7 different weights, which is very handy
- vertically condensed, more lines fit (modern monitor aspect ratio (16:9 or 16:10) is usually too wide for programming, but not sufficiently high)
- default line spacing slightly bigger than on other fonts
- has increased size of interpunction symbols
- serifs on characters I and 1, curved character l
- number 0 has a dot (easy to distinguish from letter O)
- letter g is double looped

Note: the "default" font size of Source Code Pro is too small, you have to increase it by 7% (compared to other fonts) to get a font of similar size.

Source Code Pro is an excellent programming font, and for a few years it has been my favorite programming/CLI font too.

However this year I have tested several more recent typefaces, among which there are some that I prefer now, e.g. Fantasque Sans Mono, Cascadia Code and JetBrains Mono.

For me, Source Code Pro has two defects, but for many other people these two defects do not matter, so for them Source Code Pro is a good choice.


One is that Source Code Pro does not have ligatures, the other is that Source Code Pro lacks many characters in certain Unicode ranges, e.g. mathematical symbols.


These two features are important for me for the same reason: I hate the straightjacket imposed by the ASCII character set to the programming languages.

Because of ASCII, all the popular programming languages use various ad hoc inappropriate characters instead of the traditional mathematical symbols, and many characters are too overloaded, e.g. the parentheses and braces.

Ligatures are a workaround for the limitations of ASCII when using legacy programming languages, Unicode characters corresponding to the traditional mathematical symbols are a solution for custom languages.

[jaxa]

AMD's flagship RX 7900 XTX GPUs discovered to integrate A0 silicon revision affected by serious hardware issues

Rumors Allege AMD Shipped Unfinished RDNA 3 Navi 31 A0 GPU Silicon In Radeon RX 7900 Series

As discovered by Kepler_L2, it looks like early RDNA 3 silicon had a non-working shader prefetch HW. This was featured in three chips, the GFX1100 (Navi 31), GFX1102 (Navi 33), & GFX1103 (the APU lineup consisting of Phoenix chips). Now based on the latest GitHub submission. Kepler is also suggesting that Navi 32 GPUs are actually based on the 'GFX1103' IP whereas Navi 33 chips feature the 'GFX1102' IP. The same issues are found on every other chip besides Navi 32 which is going to be featured in several mainstream discrete GPUs on desktop and mobility platforms by early 2023.

According to Kepler, this is something that cannot be fixed or revised in a few weeks and will take several months if AMD even plans on fixing this. It would be a major blow if newer silicon with a fix comes out a few months later because the majority of gamers would already have bought the early revision of the Radeon RX 7900 series with the unfinished silicon. What's likely is that AMD may prepare a refresh a year later that would address these issues but for now, the Radeon RX 7900 series may have to depend massively on driver-level optimizations to address the unfinished GPU nature of their top RDNA 3 silicon.

But that's not all, other major features such as the VOPD instructions featured on the RDNA 3 GPUs claimed to offer a big improvement in performance but in reality, they only managed to deliver a 4 percent improvement over RDNA 2 in ray tracing titles. The RDNA 3 silicon was designed to handle dual Wave32 instructions for twice the floating point performance by utilizing 64 multi-precision & multi-purpose ALUs implemented across 2 SIMD32 units. Talking to an AMD representative, folks over at HardwareTimes were able to confirm that AMD is currently in the process of fine-tuning the performance here and expects optimizations along the way

[AdrianBc]

Here's the clpeak output: https://gist.github.com/gartnera/4b9...b12e25c2b645db

While your first OpenCL results appear to settle the question about the FP64 implementation, it is weird that at least the values for single precision and half precision are about twice lower than expected.

Could you please also run vkpeak, to see if under Vulkan the same anomaly is present?


AMD claims:
Peak Half Precision Compute Performance: 103 TFLOPs
Peak Single Precision Compute Performance: 52 TFLOPs


In the case when the FP64 results would be correct, but the FP32 results would be wrong, because the OpenCL driver fails to overlap operations on the dual FP32 execution units, that would mean that the FP64:FP32 ratio is even worse, 1:64, like in RTX 4000.