Talk:List of AMD graphics processing units/Archive 3

Archive 1

Archive 2

Archive 3

Navbar for the tables

Wikiinger recently changed the navbar position (the view/talk/edit links) of some AMD related tables from upper left to lower right (bottom of table, right side of the page) and also uses the standard template instead of the customized one. He said he'd prefer a discussion here so copying from his talk page:

== Floating navbar ==

Disadvantage is that a table might not use the full width of a page, in which case the navbar isn't attached to the table. Template:AMD Epyc 3000 series is relatively slim so it can be used for testing.--Pizzahut2 (talk) 16:39, 23 January 2019 (UTC)

Also when trying to attach the navbar to the right border of the table, it will be out of sight if the right side of the table doesn't fit into the browser window.--Pizzahut2 (talk) 18:47, 23 January 2019 (UTC)

How about this, no navbar in the articles, but a link which is only visible when viewing the template?
* Template:AMD Epyc 3000 series/sandbox
--Pizzahut2 (talk) 19:54, 23 January 2019 (UTC)
: Kinda different issues...
# The visual edit never worked for me. However I like the idea to display the visual edit only on the template page.  However the V.T.E should be accessible (but subtle) on the article page since it is really handy.
# About the floating navbar. I guess there should be some CSS vodoo to align it with the right side of the table? Another possibility might be to create an empty white row and place the navbar in there?
: PS: I would prefer to have these discussion on the article page (best candidate is List_of_AMD_graphics_processing_units), since this way other editors can chime in. Wikiinger (talk) 20:33, 23 January 2019 (UTC)

Attaching the navbar to the right side of the table can be achieved by putting table and navbar inside another table consisting of a single table cell with style="position:relative". But as mentioned above the problem with this is that for broad tables, the navbar is out of sight then.--Pizzahut2 (talk) 12:17, 24 January 2019 (UTC)

Illustration of the issue (expires in 14 days).--Pizzahut2 (talk) 20:03, 27 January 2019 (UTC)

Proposed fix A: Don't use navbar for table. Leave an edit link for the VisualEditor inside, but using noinclude tags.Pizzahut2 (talk) 20:08, 27 January 2019 (UTC)

Proposed fix B: Set table width to 100% (like this). Wikiinger's navbar code remains unchanged, meaning the navbar is always visible, even if the table is too wide to fit into the browser window.--Pizzahut2 (talk) 19:32, 27 January 2019 (UTC)

fix B looks good to me! Wikiinger (talk) 20:24, 27 January 2019 (UTC)

Applied fix B, also added a link to use the VisualEditor.--Pizzahut2 (talk) 21:45, 14 February 2019 (UTC)

Page Format

Why is the page in a non-standard wikipedia format?

Dava4444 (talk) 06:18, 22 December 2017 (UTC)

fixed. If anyone wants to tidy it further.. that would be great.. I would suggest putting the IGPs together in a Section with APUs and leaving Desktop GPU as a discrete card section, as its quicker to sort through the information that way imho.

Dava4444 (talk) 20:21, 25 December 2017 (UTC)

Hey Dava4444, it's not clear what you mean by "non-standard wikipedia format", since there is no such thing. However I reverted your change regarding the table of contents (TOC), because otherwise we end up with a lot of white space next to that very long TOC. And that long TOC is very useful since it allows you directly to jump to your graphic series in question. I especially like that it is next to the field explanations. This way you can easily jump back and forth between the table and explanations for it, this wouldn't be possible otherwise. Hope this clears that design decision. :-) Wikiinger (talk) 18:58, 27 December 2017 (UTC)

Hey Wikiinger :)

The reason the table is on the left, as it is on every wikipedia page as it gives a uniform heading to the page catagories, I personally don't need those field explanations, and if the purpose is to inform then of course those additions are welcome, however the page is currently imho very disorienting and doesn't theme with the rest of wikipedia. have a look at the Nvidia page: []

it's clean easy to understand and I can get to the specific cards specs I am looking for in one click.

You stated 'there is no such thing'.

However there is a standard wikipedia page format in so much as, the web developer/s of wikipedia designed the categories to be on the left hand side; This is universal across all of wikipedia.. whether by design, or merely end result.. it makes browsing wikipedia for readers a comfortable and familiar experience; to not have to engage higher motor skills and a analytical state so they can stay in a meditative state while absorbing information.

Dava4444 (talk) 10:54, 28 December 2017 (UTC)

Hi Dava4444 (and Wikiinger) I very much understand your argument of consistency is very valuable for clarity, and also believe the top section of this article can be improved. And the current appearance is unusual compared to how most articles are presented. However, I would caution against stating these things are "universal across all of wikipedia". While left is the default, there is no consensus that it must be this way. In fact, looking over WP:TOC it explicitly states "The TOC can, in some instances, be floated either right or left... when it is beneficial to the layout of the article". A proposal to remove right TOCs failed due to "no consensus". (If the discussion is to be about universality of WP layout, it should be carried out on the WP:MOSLAYOUT talk pages.)

To clean up this article, I propose the following:

• The field explanations can be replaced by links/notes in the column headers for each generation.
• Video codec acceleration can either be moved, as a note within each generation or added to the {{AMD GPU features}} table.
• It might also be worth having a discussion of splitting this article into separate desktop/mobile/workstation articles. Splitting would shorten the TOC, and might help the aesthetic issues with a left TOC.

Thoughts?Dbsseven (talk) 20:21, 28 December 2017 (UTC)

Thanks for the suggestions Dbsseven, sounds sensible. I agree.

Dava4444 (talk) 13:19, 30 December 2017 (UTC)

This has been over a month with no reply from Wikiinger. I am noting his lack of protest and going to *try* to implement Dbsseven suggestions.

Dava4444 (talk) 21:10, 12 February 2018 (UTC)

Dava4444, do you even look at the articles after your edits? VCE/UVD are already mentioned in {{AMD GPU features}}. And please don't change font sizes, see MOS:FONTSIZE. Ty Wikiinger (talk) 22:19, 16 February 2018 (UTC)

Wikiinger, you've well marked your territory with your scent.. you are putting editors off improving this article, if a mod challenges you and you need consensus.. I doubt you will have enough people still around to get that.goodbye Dava4444 (talk) 06:05, 26 June 2018 (UTC)

Wikiinger This page is a total mess, you've turned it into your plaything. You started off OK, and I appreciated *some* of the tables but now it's some backwards mirror chimera of an abomination. It gives me a headache to try to read this now. Total joke of an article now.. Dava4444 (talk) 07:34, 15 April 2019 (UTC)

"including those by ATI Technologies before 2006"

When did the merger or takeover of ATi and AMD take place? I know for a fact that the HD6000 series was still sold under the ATi brand name, and that was well into 2012. -- Alexey Topol (talk) 19:09, 14 June 2020 (UTC)

Analog VGA output is missing on newer cards

Newer cards like R9 290(X) don't have analog VGA output (not even through DVI to D-SUB adapter). I think it should be mentioned in the table or at least by a note.— Preceding unsigned comment added by 95.131.128.23 (talk) 19:30, 1 February 2017

While tables like this: https://www.x.org/wiki/RadeonFeature/ show if the GPU has a DAC, its not perfect, as board vendors can have onboard DP to VGA converters. Kevinf28 (talk) 23:46, 10 January 2019 (UTC)

Another observation: The last cards to feature dual analogue VGA output on some cards, mostly via a set of 1 x D-Sub VGA + 1 x DVI-I connectors, but also via a set of 2 x DVI-I connectors, were of the HD5000 series. Later cards from the HD6000 series onwards only featured a maximum of a single analogue VGA output, either by way of 1 x D-Sub VGA connector or 1 x DVI-I connector. I don't know which series was the last to offer even that single VGA output. I think this information should be in the article. VGA connectors are still relevant today, not only for older legacy hardware but also for newer devices. -- Alexey Topol (talk) 19:15, 14 June 2020 (UTC)

HDCP

Hi, i am not talking or working often on the wiki, but i noticed the missing info on HDCP on some cards.

I know that the HD 4850x2 and HD 4870x2 cards had HDCP 1.2 because i used these cards and still use them for openCL and they have a label on the PCB saying that they are HDCP 1.2 enabled.

Hope this helps ^^" — Preceding unsigned comment added by TanakaO (talk • contribs) 06:19, 1 May 2019 (UTC)

Console Section - PS5 GPU Tech Specs

I just want to point out that who ever keeps putting "boost" vs "standard" is in the wrong. There is no "standard" or base clock for the PS5 GPU. That rubbish was based on the 9.2 TF rumor from over a year ago that never was true. Also the Triangle/s rate is wrong too. It's simple math, 4 Triangles per clock * Clock Speed. Clearly some fanboy keeps reverting changes and I'm not going to compete with that stupidity. — Preceding unsigned comment added by 47.197.50.130 (talk) 12:45, 16 November 2020 (UTC)

Need to add Radeon RX 6700XT

The spac and price for the RX 6700XT has been announced and the graphics will be available on 18 march, 2021. Please consider adding about this card to the template of RX 6000. https://www.amd.com/en/products/specifications/compare/graphics/10886,10516,10521,10526 007sak (talk) 18:22, 3 March 2021 (UTC)

Radeon 520/530 are mobile only, not discrete.

The Radeon 520 and 530 are mobile chips only and should be removed from discrete graphics list (RX 500 series).

Haven't edited a page on Wikipedia in while so I'll leave it to someone else (so I don't mess up).

NitroX infinity (talk) 08:38, 23 March 2022 (UTC)

Radeon 600 series (architecture, codenames, dGPUs)

I believe the Radeon 620 and 625 are GCN 3rd gen (TSMC 28nm) and not 4th gen (GF 14FF). Also it would be nice to add missing codenames.

Since 600 series is single table (desktop & laptop), maybe additional footnote (for 630 and RX 640) could be added.

At AMD radeon-630 radeon-rx-640 are listed as discrete and mobile. Based on videocardz there are 10 GPUs in total (3 discrete, 7 mobile), same names but different SP.

I'm still experimenting with templates, not confident enough to edit, so i gonna leave this here (maybe someone else can edit it).

Rando717 (talk) 23:19, 6 April 2022 (UTC)

IGP (3xx series) ...only 3 GPUs?

Looking online on sites like GPUZoo, TechPowerUp, UltimateRetro, VGAMuseum, ...etc

There appears to be more from IGP 3xx series (chipset integrated). Stuff i found so far have multiple names/codenames like:

IGP 320/320M (RS100/A3/U1/Cabo) - Oct 5th, 2002

IGP 330/330M (RS200/RS200L/Wilma) - May 1st, 2002

IGP 340/340M (RS200/RS200M/Wilma) - Oct 5th, 2002

IGP 345M (RS200/RS200M+/Wilma) - Oct 5th, 2002

IGP 350M (RS200 revB/RS200M revB/Wilma) - Oct 5th, 2002

IGP 380 (RS380) - this one could be 'Radeon X600 Pro' related, and not IGP 380?

...anyway can't see any 3xxM mentions on article (or 345M/350M), so I gonna leave this here (in case it helps someone).Rando717 (talk) 05:52, 17 April 2022 (UTC)

Page too big?

This page nearly crashed Chrome on my phone (Pixel 5a). Would it be worth the undertaking to mitigate that e.g. split into separate pages? 217.180.201.169 (talk) 00:01, 28 August 2022 (UTC)

Recent changes to table style/layout

Following recent changes to RX 5000, RX 6000, RX 7000 and Pro series tables. I wanna start discussion about table style, those templates are used here aswell (and so far all tables more or less followed same design).

So my questions about the new layout are:

1. Why is adding extra colored row (increasing table height) better?

2. Why is changing primary source from cite templates (with dates) to external links (prone to Link rot) better?

3. Why is splitting release date & price to 2 cols (increasing width) better?

4. Why is splitting arch & fab to 2 cols (increasing width) better?

5. Why is splitting memory type & bus width to 2 cols (increasing width) better?

6. Why is there extra refs column (increasing width)?

Those are main differences with new layout.

Pinging: @CristoCalis: to start discussion. Rando717 (talk) 01:19, 28 November 2022 (UTC)

1.) The branding row at the top reduces the width of the model column as there isn't a full name like 'Radeon RX 7900 XTX' or 'Radeon Pro WX 8200' in each row.

2.) The primary source should always be linking to the product specifications on AMD's website as that it is the most direct and reliable source. Having a simple external row in the model column reduces width since there is not the [1] reference at the end of the product name which takes up unnecessary space. Simple external links have been used for Intel tables like their Arc GPUs or Core processors and they work fine. There seems to be no problems there. It is less likely that official product specifications from AMD and Intel are removed from their websites, and even in the event that there is aa link rot, the link can simply be replaced with an archived version.

3.) The release date and price have been split as they are two separate details. Sometimes the release date can be shared between multiple GPUs like the RX 7900 XT and XTX so the release date can be rowspanned rather than having the same data repeated in the table in multiple cells. Additionally, the price column having the (USD) label also reduces width as a price does not have to contain '$999 USD' and '$899 USD'.

4.) Like with release date & price, architecture and fab is two different data points that can vary across GPUs. For example, the Radeon Pro WX x200 series has the same GloFo 14LP fab that can be rowspanned while they have different architectures of GCN 4 and GCN 5. It is not necessary to have 'GloFo 14LP' repeated in multiple rows when it can just be placed in the table once and rowspanned.

5.) Same with release date & price and arch & fab. Memory type is shared between multiple GPUs so it can be rowspanned rather than having it repeated in each row unnecessarily above the respective bus width. If two GPUs share the same bus width but use a different memory type, then the bus width can be rowspanned across the two GPUs while the memory type is not rowspanned.

6.) The refs colummn is to reduce clutter in the models column which can sometimes contain up to 4 references on the same product. It makes the most sense for the one link in the product to be for AMD's website rather than being clumped together with other secondary sources like TechPowerUp or VideoCardz.

I understand your concerns about making the table too wide but the problem is that sometimes in the pursuit of making the table narrower also comprises the information in the table. It is not efficient to to have repeat information in the table being clumped in with other data. The table is easier to read when information is clearly defined and laid out. CristoCalis (talk) 14:14, 28 November 2022 (UTC)

1.) Is branding row for product segment or just Radeon? There are some odd names like Vega FE as part of initial Radeon PRO series (Honestly entire Vega arch. product naming is bad, but it is what it is).

What about multiple product lines inside same table/series like 300 series (R5 300, R7 300, R9 300, R9 Fury...ignore Pro Duo inside that table).

Side note: Did you try looking at tables (with colored rows) with dark mode enabled (wiki feature)? It's something else...

2.) Even primary sources tends to change sometimes, one example I can think of is Radeon 610. Look at features on live link (GCN 1, 28 nm) and than look at archived link (GCN 4, 14 nm). Can't check at glance for any changes (if there is no retrieved date), you have to open each link.

AMD product pages "shrink" (no the best word to describe it) over time, until spec tab is the last info remaining (especially on CPUs, unless using full spec product links). I don't think AMD tables should be compared with Intel or Nvidia.One difference is that AMD articles are using templates where Intel and Nvidia are (mostly) using separate tables within each article(or lists page). IMO Intel have more "permanent" links for product specs (try and find Pro Duo (Fiji) specs page...there is driver page, but no specs only for Polaris. I wasted good portion of time looking for archived ref...I gave up).

3/4/5.) I gonna sum those 3 it up, similar topic...I understand, but isn't better option to maybe move single/repeating info outside?

If all products are made on 14nm or use GDDR6, how about note above/outside table?

But than again if "branding" rows are used (more than one) it sortof prevents that. One (unrelated to this topic) example would be Ryzen 3000 series with 6 branding rows and 2 identical columns (fab/memory).

6.) Tbh I don't think products should have more than 3 refs. One primary (if available), one with more spec and to confirm primary source (usually it is TechPowerUp or NotebookCheck for mobile),

last one as review/launch date/price info (Tom's Hardware, AnandTech or similar). Also old announcement cites for products that already launched should be removed. I don't think ref(s) col is needed if there are 2-3 refs, you can place refs behind codename (if model name is taking more space).But that is just my opinion. Rando717 (talk) 20:59, 28 November 2022 (UTC)

1.) The branding row has been used for Ryzen CPUs to show product segmentation but Radeon does not generally have segmentation like Ryzen 3, 5, 7, 9 so only one branding row at the top would be required. For a specific case like the RX 300 series, branding rows could conceivibly be used to clearly separate the R5, R7 and R9 families within the table.

3/4/5.) On moving data out of the table, I don't think that would work because of the use of templates. It also does not seem to be worth it to have a long list of bullet points in the table just for teh sake of having two less rows in the table. Some of those bullet point lists can also be very tedious to read such as when they say someting like "All products feature __, except __, __, __, and __". The use of bullet points could also look weird depending on where else the template is used except for the dedicated page for a certain set of GPUs.

6.) I still don't think that refs should be placed in the middle of the table because it can get in the way of data and makes the table less readable. Having a small refs column for one or two secondary sources makes the table way more readable since all of the references are placed together, out of the way of the information itself. References are intended for verification so they should not become a feature of the table when they are placed in the middle of cells with other data. For example, if you look at the filmography tabkle of some actors/actresses like Genevieve O'Reilly or Maya Hawke, there is a small references column that makes the table look neater and does not get in the way of the information itself. CristoCalis (talk) 15:05, 29 November 2022 (UTC)

I reverted all Radeon Pro, RX 5000 and RX 6000 series table style changes.

Since CristoCalis / Halvleder was blocked and there was no proposal or consensus about it.

This talk page is linked inside most templates (inside template doc) to discuss table layout and style. Rando717 (talk) 09:28, 16 December 2022 (UTC)

@Rando717

I have reverted changes to the table layouts by the latest sockpuppet accounts and IPs yet again. (Note to anyone who wants to make big changes to table layout: please discuss here first before making them, next time.)

One thing I'm not sure on, is the putting of MB (megabyte) and GB (gigabyte) units in each table cell, rather than just in header only. Currently RX 6000 series has units inside each cell, while RX 7000 and RX 5000 series have them in header column only.

It would be appreciated if you could leave your thoughts on this matter.

Additionally, but this one is optional to discuss, let me know what you think of row hover highlights.

AP 499D25 (talk) 03:55, 15 February 2023 (UTC)

@AP 499D25 Sorry for late reply, I totally forgot you pinged me here.

In my humble opinion:

1.) MB/GB should remain inside header to save some width, plus there is free space(row) for it inside header.

2.) I would also move W (watts) outside cells. That extra W expands TDP col. on mobile tables with ranged values. Unless default sorting is enabled than it doesn't matter, TDP header/col is gonna expand anyway.

3.) About row hover, I liked it at first but it doesn't really work with merged cells(rows).

The time it takes to figure out what row is highlighted...you can already do it "manually".

I am partially guilty of it for GeForce 20/30/40 articles. Someone added it on 30 series, so I added row highlight on 20 series, than it got copied to 40 series and RX 7000 ...and now we are here.

I don't like it. It works with normal tables (no vertically merged cells/col). For example on Transistor count table, you can easily navigate row highlights and quickly see info of each gpu chip. Without need to decypher merged rows or breaks inside highlighted row due to other merged rows. Rando717 (talk) 07:20, 21 March 2023 (UTC)

Thanks for the response.

1. Personally I prefer having the MB and GB units in each SKU's cells, like how it is at Template:AMD Radeon RX 6000, as it makes it quicker and easier to figure out that this is the Infinity Cache size, this is the VRAM, etc. With the units in the header only, I have to jump my eyes up and down between the header and the item cells a lot, I don't know if this number is PCI-E lanes, I don't know if it's cache, or actually the memory size. Units for things like bandwidth and clock speed can be put away in the header cell no problem, as the numbers presented are often unambiguous - for example 1053.8 is never going to be the amount of VRAM or even TDP, it's almost certainly gotta be bandwidth or clock speed. And those two things are quite far apart each other, too. Because the Infinity Cache and Memory info are so close together, it can get quite confusing for me whether this number is the cache amount or the memory amount without the units in each cell.
2. Hmm, I'm not sure if I quite like this. If I'm not mistaken, numbers with an endash between them will be broken up if the table can't fully fit in the screen width without part of it going out of view.
3. "it doesn't really work with merged cells(rows)" that's what I noticed with this feature too. It seems most people are fine with it as it's staying on the tables it's been added on. Don't feel guilty, some of the tables had row hover highlights removed before only for it to be added back a few months later. Which means that there is a consensus in favour of it here. @Wikkiwonkk what do you think? Any thoughts on this third point here?

What I actually intend to do for now, is I'm going to leave the tables as they are (even the inconsistency between RX 6k and 7k series templates I'm going to leave alone) and see what happens in a few months. Whether edits are made in favour of one or the other will decide the consensus here. If nothing, I might boldly make the changes I want to make. After all, moving the units into header cells are going to save what, only 10 pixels of width? AP 499D25 (talk) 11:33, 21 March 2023 (UTC)

My thoughts are right in line with @Rando717's - I initially thought the row highlighting was good, I even added it to some tables myself, but the more I see it the less I like it and now regret adding it where I did. It just does not work with rowspans, and I am not referring to the obvious technical limitation where certain columns do not get highlighted. Even if it highlighted every column correctly it would be visually "messy". It frequently would not be a uniform horizontal bar of colour but something more like a column chart with positive and negative y values: some highlighting would extend up from the row, some down from the row, some would straddle the row, and as the mouse pointer moved from row to row, the position, size, and even direction of any tall highlights could fluctuate wildly. It ends up being more of a distraction than an aid. The only way I see highlighting being a benefit is if there are no rowspans. Does the benefit of highlighting outweigh the cost of not using rowspans? That is subjective, but I will point out that there are a lot of values that could be rowspanned but have not been. In the HD 7000 series table for example, the memory bus type & width, particularly in the lower half of the table, and all those 10 and 15 watt idle TDPs.

Since I am here, I will chip in my thoughts on units: they should be in the header row. The only exception being mm² for die size and that is only because it shares the column with transistor count. If they were separate columns I would put the mm² in the header (please note that I am not even remotely suggesting that they should be separate columns). - Wikkiwonkk (talk) 14:11, 27 March 2023 (UTC)

Thanks for your response. Regarding row hover highlights, I didn't know what to think of it, if it was good or not, and so wanted to hear some feedback about it, as I wasn't sure what to do about some tables having it and others not. Seeing that the feedback here is against it, looks like I will be removing it from the tables then.

On the topic of 'rowspanned'/merged tables, it's quite interesting in general to see the "evolution" of CPU and GPU model tables as you look at them through the generations. Oh, how the R300 tables don't even have broken up text in the header cells to reduce width. Some of the tables not having merged cells being among one of the many little inconsistencies seen here. Take a look at old AMD Athlon II and Intel Core 2 list articles, not a single CPU models table in those has merged cells. Those tables could take advantage of row hover highlights certainly... Or they could take good advantage of merged cells (or perhaps common features out of the table into a bulletpoint list above it, like with the current layout of the Ryzen CPU tables). But hey, looking at the talk pages and edit history of both articles, looks like no one has complained about the current table layouts of both articles. I guess RHH would be the more minimal of the two changes that could be made over there.

Now, on the topic of memory units: isn't it quite confusing when you look at 32 without a MB next to it (only in header cell), thinking to yourself "wait a minute, is that 32GB of VRAM that GPU model has right there?" This is the big reason why I don't like the units being tucked away into the header cells, it is quite easy for me to mix up cache amount and the VRAM amount. By having the units next to them it makes the distinction between the two very clear in my opinion, as we are obviously light years ahead of graphics cards having only megabytes of VRAM, but probably still light years away from GPUs having 1 GB, 4 GB, 64 GB of cache. But these are just my thoughts and if units being in header has the majority of support, then so be it.

AP 499D25 (talk) 05:03, 28 March 2023 (UTC)