Talk:RDNA (microarchitecture)
This is the talk page for discussing improvements to the RDNA (microarchitecture) article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find video game sources: "RDNA" microarchitecture – news · newspapers · books · scholar · JSTOR · free images · free news sources · TWL · NYT · WP reference · VG/RS · VG/RL · WPVG/Talk |
This article is rated B-class on Wikipedia's content assessment scale. It is of interest to multiple WikiProjects. | ||||||||||||||||||||||||||||||||||||||
|
Wiki Education Foundation-supported course assignment
[edit]This article was the subject of a Wiki Education Foundation-supported course assignment, between 25 January 2021 and 3 May 2021. Further details are available on the course page. Student editor(s): DaveGod77.
Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 02:55, 18 January 2022 (UTC)
AMD CDNA: data center compute GPUs
[edit]You can find links about AMD's CDNA GPUs at Talk:Advanced Micro Devices#AMD CDNA: data center compute GPUs. --Soluvo (talk) 14:01, 12 May 2020 (UTC)
Clarification needed for RDNA 2 ISA ownership?
[edit]Regarding the June 2020 edit requesting clarification for the statement that AMD owns the ISA: I don’t think that there needs to be any language added because the ISA is a fundamental part of RDNA, which is owned by AMD. I understand that there are lower level technologies used by the instruction set that are not owned by AMD, but at that point we’re clearly already past the instruction set.
Am I missing something? Edits like this are why we have comments for edits. I need clarification on what/why you need clarification, because (from my current perspective) the statement in question is actually so obviously true that it could be removed. ChiXiStigma (talk) 09:30, 28 November 2020 (UTC)
188.3 Mtr/mm² for Navi 31 looks fishy
[edit]Great job with the table folks (like it!), but the density for Navi 31 looks fishy, the source you used must be mistaken. I didn't have time to read in detail yet, but it looks like the 58B transistor count refers to *entire* MCM, so correct density is 58000/533 = 108.8 Mtr/mm² 188.66.34.37 (talk) 16:45, 9 November 2022 (UTC)
- P.S. AMD's slide deck contains an interesting detail: 7900's work group processor is 331 Mtr. in 2.5 mm² = 132.4 Mtr./mm², which is fully in line with other 5nm designs; RX 6900 XT is 215/4.33 = 49.65 Mtr./mm². Besides, the table cites 37.5 mm² for MCD, but why? AMD's deck clearly says 37 mm². Unless the source you used can explain where the 37.5 mm² and the 188 Mtr/mm² numbers come from, I think it's better not to use it for reference. For now, I'm going to bring the numbers in accordance with AMD's slide deck. — Preceding unsigned comment added by 188.66.34.37 (talk) 17:15, 9 November 2022 (UTC)
- P.P.S. Decided to add AMD's official numbers and leave TPU's in place, but obviously both can't be correct at the same time, so if anyone can ping TechPowerUp guys to come here, *please* do so by all means. Wikipedia has strict policy with regard to reliability of sources used, and I'm afraid TPU's numbers can be considered unreliable the way they are presented on their site – with no info as to how the numbers were obtained whatsoever. I personally have no problem believing die sizes quoted by TPU, as I can imagine they could rely on insider knowledge, but I think for their data to be considered acceptable for a Wikipedia article, they should provide proper explanation at least on this talk page.188.66.34.37 (talk) 18:29, 9 November 2022 (UTC)
- Techpowerup sometimes reports incorrect data, I used it as reference mainly to prevent WP:ORIGINAL.
- From official press release [AMD press-releases] If you look at Chiplet Design, AMD claims die size of 306mm2 (GCD) and 37.5mm2 (MCD).
- I think we should stick with one, avoid using two values.
- Too early for accurate data anyway, still no RDNA3 ISA and cards are not out yet.Or we leave it as "unknown" for time beign? Rando717 (talk) 18:56, 9 November 2022 (UTC)
- Thanks for the link! I haven't seen the PR, as my search didn't return it for some reason in top results, and I didn't bother checking the site for it. So apparently they used rounded numbers for the slide deck. And, sure, it means we leave the TPU/press release data for the table – I'll do it right away and will add the PR in refs. — Preceding unsigned comment added by 188.66.34.37 (talk) 19:20, 9 November 2022 (UTC)
- P.P.S. Decided to add AMD's official numbers and leave TPU's in place, but obviously both can't be correct at the same time, so if anyone can ping TechPowerUp guys to come here, *please* do so by all means. Wikipedia has strict policy with regard to reliability of sources used, and I'm afraid TPU's numbers can be considered unreliable the way they are presented on their site – with no info as to how the numbers were obtained whatsoever. I personally have no problem believing die sizes quoted by TPU, as I can imagine they could rely on insider knowledge, but I think for their data to be considered acceptable for a Wikipedia article, they should provide proper explanation at least on this talk page.188.66.34.37 (talk) 18:29, 9 November 2022 (UTC)
152.3 Mtr./mm² for Navi 31 claimed by Tom's Hardware looks fishy as well
[edit]I raised this issue at the talk page of the editor who replaced AMD's density with Tom's Hardware numbers, but I think it's better to have this discussion here:
Hi, I have spotted your [edit] and wanted to ask you a few questions. Did you notice that density numbers from the article you referenced contradict not only numbers AMD reported in print about Navi 31, but also what is known about the density of TSMC's N5 and N6 processes in general? And in case you did notice that, why do you believe these numbers are the correct ones (or at least more correct than what AMD said in print) – since you did not just add a contradicting source, but deleted density numbers from AMD's official document along with the reference? 188.66.35.198 (talk) 20:48, 16 November 2022 (UTC)
- About "numbers AMD reported in print about Navi 31", in that footprint AMD clearly said it is the density of the "work group processor (compute unit pair)" of RDNA3/2, not the chip(let) density.
- For MCM, the old density (109m/mm2) was unlikely to be correct as it is almost the theoretical peak density of N6, which is possible for a pure logic chip, but not for I/O&SRAM chip, the new density (55.4m/mm2) was from the new reference directly and align with other mass-produced N6 chips.
- For GCD, the new density (149.3m/mm2) was calculated with reported transistor count and 306mm2, this size was from AMD's RDNA3 launch news, it is more precise than the 300mm2 used by tom's hardware and AMD's slides, both 300 and 306 are from AMD so either could be the correct. Cloudream (talk) 12:34, 17 November 2022 (UTC)
I'm of impression that you're somewhat confused on several issues, so I'll clarify and explain a few things.
1. "in that footprint AMD clearly said it is the density of the "work group processor (compute unit pair)" of RDNA3/2, not the chip(let) density."
First off, you should pay more attention to fine print: AMD said clearly these numbers refer to Radeon RX 7900 XTX, in other words, Navi 31 – which is what I said. Follow-on Navi 3x's can well have optimized layout along with logic/physical design of CU's resulting in slightly different density for the units and entire chip (and I'm quite confident they will). Second, at nearly 80% of GCD area, transistor density of CU is highly representative of density for entire chip, with possible error of some 5-10 Mtr./mm² at worst (easy to show, let me know if it's not clear to you) – hence obvious contradiction of Tom's numbers with density AMD reported in print.
Transistor density range for 4/5nm designs is well-known: 134–139 Mtr./mm² for smartphone SoCs and 100–125 Mtr./mm² for GPUs (excluding Navi 31); GPUs have lower density due to more dark silicon, higher use of HP libs and lower use of HD libs. Tom's Hardware states that GCD density is 152.3 Mtr./mm² – significantly higher than in smartphone SoCs, which is extremely unlikely to be true. If you're not very familiar with transistor density landscape, take a look at Transistor count article, there's quite a number of 4/5nm designs.
But what really rings alarm bell about numbers in Tom's Hardware article, involves a bit of math and analysis. In short, if given Tom's numbers we calculate transistor density for non-CU portions of GCD, we'll get a number of 211.0 Mtr./mm². And if you check Transistor count and 5 nm process articles, you'll see that it exceeds both N5 density (138.2 Mtr./mm²) and the densest 5nm designs (A15 @ 139.3 Mtr./mm²) by a factor of 1.5, which is *huge* contradiction with well-known numbers. Besides, Nvidia is at 98–125 Mtr./mm² at 4nm, and it's a very useful reference which should be taken into account as well.
Seriously, look at the numbers and do the math if you missed it, it's fairly simple. If you can't arrive at 211 Mtr./mm² on your own, let me know and I'll explain it in detail.
2. "For MCM, the old density (109m/mm2) was unlikely to be correct "
This number is not a subject of debate at all, as it is obtained directly from die sizes and transistor count provided by AMD: 58B / (306 + 6×37.5) = 109.2 Mtr./mm²
Apparently, you confuse MCM (multi-chip module) with MCD (memory cache die).
3. "For MCM, the old density (109m/mm2) was unlikely to be correct as it is almost the theoretical peak density of N6, which is possible for a pure logic chip, but not for I/O&SRAM chip, "
Aside from MCM/MCD confusion, you're completely wrong thinking that the highest density is possible for a "pure logic chip", and not for SRAM. In fact, the opposite is true. I mentioned above N5 process and chip-level densities (random logic), but cell-level SRAM density for N5 is 240 or 286 Mtr./mm² for HP and HD cells respectively (0.025 and 0.021 um²). Note this is cell-level only, you won't see such density for complete cache.
What it means is that for MCD it's reasonable to expect a tangibly higher density than for random logic (entire GPUs). Now take a close look at Transistor count again. See anything weird? 6nm MCD density of 54.7 Mtr./mm² as Tom's article claims is not just marginally greater than Navi 2x (~50 Mtr./mm²) , but significantly lower than 7nm GA100 released back in 2020 with 65.6 Mtr./mm² – completely opposite of what is reasonable to expect. And this is significant contradiction No. 3.
By the way, using data from AMD's slide deck we can derive MCD density, it equals 77.7 Mtr./mm², higher than the densest 6/7nm GPU designs, which is perfectly natural to expect from a cache die. I wouldn't be surprized to see even higher density for MCD, after all 7nm smartphone SoCs have density up to 123 Mtr./mm² – Snapdragon 865.
Considering all above said, if you still believe you did the right thing by referencing numbers from Tom's Hardware article and deleting AMD's density data, I'm still highly interested why you consider Tom's numbers correct, or at least more correct than AMD's. 188.66.33.43 (talk) 21:08, 18 November 2022 (UTC)
---
OK, I take it you're not going to defend Tom's Hardware numbers anymore, which look way off upon a close look (I would say approximate transistor counts of GCD and MCD are ca. 40B and 3B with densities of ca. 130 and 80 Mtr./mm² respectively – these numbers at least make sense and, to the best of my knowledge, don't contradict anything, unlike Tom's). I also want to make one more observation here: AMD provides density of 215/4.33 = 49.65 Mtr./mm² for Navi 21 CU's, whereas density of the entire chip is 26.8 / 520 = 51.54 Mtr./mm², which means there is excellent correspondence between the densities of CU and whole chip, and therefore it's completely safe to refer to CU density.
As a piece of general advice, contribution of high-quality content to Wikipedia sometimes requires extra work, namely performing sanity checks when adding something or replacing what looks wrong with what looks right (which in this case would be as simple as checking out Transistor count before editing). Researching a subject is better, and being an expert or consulting one (or referring to professional literature) is the best. This incident is yet another demonstration that there's quite a bit of erroneous information coming from well-established sources, and while I think your edit formally meets Wikipedia standards and good practices, it clearly shows that if we want to do a good job at providing a trustible source of information free of errata, vendor and other bias, we need to do more than simply repost things with a reference.
The funny and sad thing about Wikipedia is that careful following of good editing practices can well result in articles propagating whatever mistakes, or even intentional misinformation, sources considered reliable can contain, whereas the simple thing that can protect content from erroneous sources, namely original research, is strictly prohibited. 188.66.33.50 (talk) 16:51, 22 November 2022 (UTC)
Separated RDNA3 article
[edit]@JmsDoug Looking at your recent changes here and also on RDNA 3 redirect, can you explain why do we need a separate article for 3th gen?
In my opinion this type of edit should be proposed at talk page first. To me it doesn't make sense, especially when looking back at previous architectures. GCN have all 5 gens inside single article, same with TeraScale. But now RDNA generations are separatting, why?
You can be bold, but don't go edit warring when your changes are reverted, (since you didn't propose it in the first place).
What it would be like if we had five GCN articles and we redirect readers instead of "all in one"? Rando717 (talk) 18:48, 8 April 2023 (UTC)
- RDNA 3 should have its own page so that there can be in-depth detail on the architecture itself rather than having one paragraph under a subheader inside an article for the original RDNA 1 microarchitecture. RDNA 3 is significant enogh that it can have its own article rather than being a footnote on another article. I want there to actually be an in-depth article about the RDNA 3 microarchitecture that goes into how the architecture is built rather than a collection of bullet points on another architecture's page. Even though there is a "3" in RDNA 3, it is significant enough to be considered its own architecture and should be treated similarly to Nvidia GPU architectures like Ampere and Lovelace that have their own pages. The same goes for RDNA 2. Putting RDNA 3 details on the page for the Radeon RX 7000 series would not be appropriate since that page is about a specific line of products and not the overall architecture. JmsDoug (talk) 19:20, 8 April 2023 (UTC)
- I don't see much things significant about RDNA 2 and RDNA 3 themselves such that they deserve a separate article from having info on the RDNA page. After all, they are iterations of RDNA 1 when you look at them from an architectural point of view.
- Furthermore, the features of the architecture actually depend on what application they are being used in. For example, RDNA 2 in RX 6000 series graphics cards have ray tracing and AV1 decode support, but in the integrated graphics of some Ryzen processors, they don't have those features, at all. Another example, RDNA 3 in RX 7000 series has chiplet architecture on some GPUs, has a dual encode/decode media engine, got those AI accelerators, all that jazz. But then when you move on to some other implementations of RDNA 3, like integrated graphics in Ryzen Phoenix processors, the only changes there really are from the RDNA 2 iteration, are just higher clock speeds and faster CUs. Feel free to correct me if I'm wrong anywhere here, but I'm certain that the integrated graphics in Ryzen CPUs with Radeon graphics do NOT have ray tracing support, at all.
- So it's a little misleading at best to have those architecture articles mostly cover these features in their details sections, as opposed to having them on the page about the highest-end implementation of them (i.e. gaming graphics cards), and having the architectural entry or article just cover fundamental, actual architectural changes only. We already have separate pages on gaming GPUs, i.e. RX 5000, RX 6000, RX 7000, etc, that cover these gaming GPU specific features in detail. Yes, I know there are separate articles for Nvidia GPU microarchitectures, however I had a look at them (the recent ones), and fundamentally, they really only serve as a "portal" for all the various implementations of the architecture, the details section of them are basically a repeat of what's already in the accompanying GeForce GPU articles. They seem to cover little to no actual new things or changes about the architecture (FP32, size of this unit, how many bits wide is that, etc) at all. Not to mention it's potentially misleading – datacenter GPUs for example probably aren't gonna have fancy display, media, and ray tracing engines, they are solely compute-focused GPUs after all. Do we really need to go and create articles that say the same points over again? Highly redundant and rather useless at least, in my opinion.
- — AP 499D25 (talk) 09:58, 11 April 2023 (UTC)
- B-Class Computing articles
- Low-importance Computing articles
- All Computing articles
- B-Class video game articles
- Low-importance video game articles
- WikiProject Video games articles
- B-Class Technology articles
- WikiProject Technology articles
- B-Class computer graphics articles
- Low-importance computer graphics articles
- WikiProject Computer graphics articles
- B-Class electronic articles
- Low-importance electronic articles
- WikiProject Electronics articles