Jump to content

Talk:List of AMD graphics processing units

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Need to add also the GFX numbers

[edit]

Since AMD GPU architectures have numbers to represent their instruction sets used in various domains, it would be great to have them in the various tables of this page. See for example https://llvm.org/docs/AMDGPUUsage.html to have an idea. — Preceding unsigned comment added by Rkeryell (talkcontribs) 13:03, 3 October 2023 (UTC)[reply]

Missing Radeon™ Pro W5700

[edit]

The information for Radeon™ Pro W5700 is at https://www.amd.com/en/products/professional-graphics/radeon-pro-w5700 — Preceding unsigned comment added by Vhaisman (talkcontribs) 2021-09-22T18:44:18 (UTC)

Position and style of the template navbar

[edit]

For those sections that use templates, there is inconsistent type and positioning of the template navbar.

1. The most common is the navbar with mini=y (V·T·E) below the template table, aligned left, at relative position x=0px, y=-15px. I don't know what this looks like for others, but for me the -15px y puts it partially into the table. This is frankly ugly. Example: List of AMD graphics processing units#Radeon HD 5000 series

2. The next most common is the navbar-table ([VisualEditor] [view·talk·edit]) above the template table, aligned left. Example: List of AMD graphics processing units#Radeon HD 7000 series

3. And then there are one or two that use the mini navbar below the template table, but aligned right. Same problem of it being partially in the table.

I'm guessing the -15px y used for #1 and #3 is for compactness, putting it at 0px followed by a linebreak is noticeably more spaced out. But using a negative offset feels like something that will not reliably work for every viewer. If I had to pick a style it would be above the table, navbar with mini=y, brackets=y, and style=float:left, eg. {{navbar|AMD Radeon HD 5xxx|mini=y|brackets=y|style=float:left}}.

- Wikkiwonkk (talk) 08:47, 17 February 2023 (UTC)[reply]

Here are my thoughts.
Having the 'mini' navbar is more beneficial to the average reader, as it is a minimal visual distraction and very out of the way. But, due to its small size it will probably attract less editors, especially newcomers, some people may not even notice it's there at all, and get confused when all they see is just double curly brackets saying Radeon x000 series between them.
The navbar-table is more "editor-focused" / "wiki-beneficial" / however you want to put it, as it is clear to read, easy to spot due to the big non-abbreviated text and it even has a VisualEditor shortcut button so you can edit the template using VE in just a single click, thereby more likely to attract editors' attention (this makes it more in support of "Wikipedia is a wiki" model). The disadvantage being it's a bit of a visual clutter to the eye, especially if you're reading through a list article with over 30 tables.
From what I've seen, the mini navbar is most commonly used on very small items like small tables, portals, stats boxes, while the navbar-table is more often found on very large tables/templates. Though I myself have hardly seen a use of navbar-table outside of these odd certain AMD GPU tables that have them.
Now, for the position of mini navbar: Having it on the bottom left corner seems the best to me, as it's not a distracting spot to put it at (as opposed to top), and tables and content are aligned to the left of the screen by default always as we know it. I've seen on some tables the navbar is placed all the way on the bottom right in an odd location, I found this only works if the table is set to fill up the entire screen width (I believe it's class="wikitable center").
In conclusion, I'm not sure what to say here. For me, I'm in moderate preference of the mini navbar. But like I said above, it's harder to notice and thereby less editor friendly. For the position of mini navbar though, I'm in strong support of having it in the bottom left corner, per the reasoning above.
In regards to the navbar being slightly in table, I think this happens if the table can't fit in the viewer's screen without items being broken up inside. For me, the majority of the tables with mini navbar appear fine on my 1440p 16:9 display with 125% UI scale (effectively 2048x1152 desktop resolution). AP 499D25 (talk) 12:03, 21 March 2023 (UTC)[reply]
Only once I noticed broken navbar (bottom left) while editing template, I think it was on 600 or 500 series article. For some reason navbar clipped down (like 2 rows) inside efn notelist. But 99% of time I have no issues with navbar on 1920x1080 with Firefox or on mobile Firefox. As for alignment, position and style:
1.) Left or right? It should be on the left side, makes sense if table is not centered (across entire page).
2.) Above or below? I prefer below table. I am ok with above position if it fixes clipping issues, but it might look off or crowded.
3.) Style? I prefer mini, but I would like if brackets are enabled, to highlight it a bit. Default full style might be user friendly but imo it takes too much space.
4.) There are few navbar templates/shortcuts (navbar, navbar-table, view, vte, v), but all of them achive same thing more or less.
I would suggest changing old tables to Template:Navbar. Rando717 (talk) 15:24, 27 March 2023 (UTC)[reply]
Reply to you and @AP 499D25:
No matter what I do - adjust window size, zoom, CSS scaling - the partly in-table V-T-E does not change. This might be triggered by a combination of browser (Firefox ESR for me), screen resolution (3840x2160), and pixel density (163 ppi).
I did a lot of experimenting and it seems that VisualEditor + templates = potential foot-gun, so I'm hesitant about putting that option right up front. For those that insist on using it, it is only one click away once on the edit page.
Unfortunately, navbar, because it is in a div, sits well above the top of the table. See List of AMD graphics processing units#Radeon HD 5000 series for a particularly noticeable example of it looking very isolated (the preceding unordered list is followed by a <p><br></p>). How does navbar-table get around this? It is just a wrapper around navbar that in addition to adding a VisualEditor link sets the style position:relative and bottom:-11px. So adjusting the position of the navbar isn't the kludge I thought it was. Well it still is a kludge, but when used above the table it seems to be a widely used and reliable kludge. In the example of the HD 5000 it does not change the amount of vertical space between the list and the table though, it just moves the navbar down in that vertical space. The vertical space problem - the <p><br></p> - is tied to the list. I have not done any navbar vertical positioning changes while that problem is still there (a solution could be to have plain lines of text that start with a ' • ' ({{bull}}) instead of a list)
I am now leaning heavily to having view·talk·edit above the table on the left with the -11px positioning. To highlight it a bit we can either go with just brackets [view·talk·edit] or something that indicates what the links act on, eg. "AMD Radeon HD 7xxx: view·talk·edit" as I have set on List of AMD graphics processing units#Radeon HD 7000 series.
Something else I have done for the HD 5000 and HD 7000 templates is, in addition to the comment in the source about where to discuss changes, added a Consensus box (wrapped in noincludes) to the top which points editors to this talk page and a documentation box (also with the same consensus box) at the bottom (HD 5000 already had it). And I added the same consensus box to their respective talk pages because why not. - Wikkiwonkk (talk) 14:34, 30 March 2023 (UTC)[reply]
@Wikkiwonkk:
Out of curiosity, how does the Radeon 600 series (article / list) table & navbar look at your end?
This table and navbar position is more of a example, without float:left. I noticed the gap between table and notelist is way smaller when using float:left, but it also pushes first note slightly to the right (about 1px).
Removing float everything stays in place, but it creates extra gap above and below navbar. So in this example I moved table and navbar down, also added relative position to both. Although there is now small gap at the top above the table, at least on my end. In my conclusion issues (if any) are maybe due to using float, but I am not 100% sure. Rando717 (talk) 17:38, 30 March 2023 (UTC)[reply]
Yes I see the difference. Just in terms of correctness, floats should not be used to tweak things. I initially thought using float:left with navbars above the table fixed some problems, but later when testing scaling I discovered that if there was enough horizontal space in my browser window the navbar suddenly moved to the left of the table, or more precisely the table moved up and to the right of the navbar.
Repositioning the table seems like a worse solution than repositioning the navbar - better to reposition the small thing than the big main content of the template/article. Clearly this is a well-known irritant because navbar-table has that -11px built in.
Part of me thinks "if navbar-table has it built in, then it is okay to do the same adjustment manually to navbar", but another part of me thinks "stop focusing so much on minor format adjustments, focus on content". I am reminded of students spending half an hour trying to decide which font to use before they have even written a single line of their essay.
So I say we should get the big questions answered and implemented first:
  1. navbar above or below the table,
  2. V-T-E or view-talk-edit,
  3. "highlight" it with brackets, template title (eg. as with HD 7000), or other.
- Wikkiwonkk (talk) 15:06, 3 April 2023 (UTC)[reply]
Here's my final thoughts:
The navbar should be located below the table, should be "view-talk-edit", and highlighted with brackets, if that's possible. This seems to be the most balanced approach in my opinion (for both editors and readers) – not too in-the-way, yet easy to spot and click on.
I'm against having a title next to the navbar (e.g. "AMD Radeon HD 7xxx"), as it just appears as visual clutter / jargon in the average reader's view in my book, and I believe it might confuse newbie editors who don't know what templates are or how they work.
Response to Rando717: the navbar on the Radeon 600 series template looks fine to me, displays correctly, apart from taking up a few lines (pixels) of extra vertical space.
Also having the consensus notice at the top of HD 5000 and HD 7000 series templates is a great idea. Noinclude tags so it doesn't appear when transcluded on the actual articles. Yet, it is clearly visible right there at the top. I've noted pretty much all of the other templates (Ryzen and APU processor templates as well) have the centralised talk page consensus notice down inside the template documentation, where it is less obvious and visible, and honestly, I want to know what percentage of people actually notice and read the template documentation? I happen to forget / ignore it 90% of the time. Though I do get the hang of discussing at the list article talk pages to centralise the discussion and garner more attention from other editors.
Hmm, I wonder if the positioning system of navbar-table is different to that of navbar, would be interesting to know.
Indeed, VisualEditor isn't perfect with editing tables, and sometimes introduces little issues (such as handling line breaks using actual regular line breaks, instead of the more suitable <br /> tag which you cannot insert from VE). That, together with the VisualEditor notice in the template documentation, I'm going to agree on not displaying it upfront.
Regards, AP 499D25 (talk) 04:43, 5 April 2023 (UTC)[reply]
"Hmm, I wonder if the positioning system of navbar-table is different to that of navbar, would be interesting to know."
navbar-table is just a wrapper around navbar that adds the Visualeditor link, puts brackets around it, and gives it a relative position of y = -11px. That's why it hugs the table so nicely, when placed above the table. When placed below the table that -11px has it down overlapping the notelist. If we end up wanting to fine-tune the position of the navbar, at least we can rest assured that we're not the first ones to use that particular kludge.
It seems that we are converging on a consensus of [view-talk-edit] (which is {{navbar|Template Name|brackets=y|plain=y}}) below the table. I have made the HD 5000 through HD 7000 (+IGP) templates consistent in that style so there is a chunk we can scroll through and get a feel for how the whole page might look.
- Wikkiwonkk (talk) 14:17, 9 April 2023 (UTC)[reply]
Even with noinclude there appears to be more spacing with extra consensus template, for example on article: HD 5000 series. It's less noticeable if template links are "inline" (behind something), for example on list: HD 7000 series. That can't be applied if there is only template inside a section. Rando717 (talk) 19:08, 9 April 2023 (UTC)[reply]
I think it's because of the line breaks between the VEdit notice, the hidden note at top, and beginning of table. I'm sure if we get rid of the line breaks so those things are all on one line, the problem will be gone. Though it would be less neat and potentially confusing when one looks at / edits the template code. But that's my thought.
When the Ryzen 7k desktop CPUs template was protected because of sockpuppetry, I noticed the protection icon that had been added, wrapped in noincludes, was put right before the beginning of the table, without any line breaks. That's where I got this idea from. AP 499D25 (talk) 12:49, 10 April 2023 (UTC)[reply]
@Rando717 & @AP 499D25 Good spot. The linebreak between the HTML comment and the noinclude was introducing some vertical space in pages that transcluded the template. Which makes sense because the linebreak is outside the noinclude. I removed the comment since the consensus template has the same text in it, and made the noinclude-consensus-/noinclude all on the first line of the template. The HD 5000 series article looks better now. - Wikkiwonkk (talk) 23:12, 11 April 2023 (UTC)[reply]
I think I'm going to start rolling out this "[view-talk-edit]" navbox more and more across all the other AMD GPU templates, as well as Intel Arc templates, because lately I've just come across an editor (who isn't new to editing, mind you, although not "very experienced" either) who either wasn't able to figure out how the templates work and how to edit them, or wasn't easily able to find an edit button for it anywhere, and so replaced the templates on the article with directly placed tables when trying to make changes to them. Maybe this more visible and highlighted style of navbox will make more new/inexperienced editors be able to figure out how to edit these templates, and reduce instances like these from happening again hopefully. — AP 499D25 (talk) 12:24, 11 May 2023 (UTC)[reply]

Better Mesa Support for older chipsets.

[edit]

Recently, Mesa added a series of patches to improve support for TerraScale GPUs (again). They now support OpenGL 4.5 and OpenGL ES 3.1. Referance: https://mesamatrix.net/ as of posting ----24.208.189.58 (talk) 21:34, 3 April 2023 (UTC)[reply]

Graphic output ports column

[edit]

I would like to remove Graphic output ports column from all Radeon Pro products, to reduce table width.

Any opinions or objections? Rando717 (talk) 19:23, 14 April 2023 (UTC)[reply]

  • Slight oppose, because it's been a general tradition for ATI/AMD workstation GPU tables to have a "display outputs" column at the end. Look at the FirePro lists in the list of workstation GPUs, a good majority of them also have display outputs info. I suppose it makes a lot of sense because workstation users will tend to have a lot of displays connected, so it's quite important info to know how many ports there are, what are the type of the ports, and how many displays are supported. Workstation GPUs are all reference or near-reference spec too, AIB manufacturers don't deviate from the reference specs much, so AIB cards will all pretty much have the same display outputs as the reference card. Gaming GPUs on the other hand, will typically only have 1 or 2 displays connected, maybe 3, and AIB manufacturers will tend to configure the available display outputs differently from the reference spec, such as AIB cards having DVI while ref ones don't, another good example is how Built By AMD RX 6000 series graphics cards have USB-C but almost none of the aftermarket cards do, instead having a third DP in their place, so it is barely useful to state the display outputs supported on consumer (gaming) GPU tables. — AP 499D25 (talk) 12:44, 11 May 2023 (UTC)[reply]

What does "1.3 possible" means for Vulkan support?

[edit]

GCN 5th gen cards is listed with 1.3 support https://en.wikipedia.org/wiki/Radeon_RX_Vega_series

GCN 4th gen cards (which in this very article are just listed with 1.2 support) are listed here with 1.3 support! https://en.wikipedia.org/wiki/Radeon_400_series Tuxayo (talk) 21:55, 18 June 2023 (UTC)[reply]

Marketing names for R100, R200, R300, R400

[edit]

ATI wasn't very consistent with the naming convention relating to the chipset in these early years. The intention seemed to be to relate it to the DirectX version supported rather than the chipset. So, the R100 was in the Radeon 7000 but the Radeon 7500, for example, had R200. Similarly, the 8500 had R200 but so did the Radeon 9000.

The R300 appears first in the Radeon 9700, and then also in the 9600, 9800, 9550 etc. There were R300 PCI-e variants in the X300, X550, X600 etc. There was also the Radeon X1050 which appeared in AGP, PCIe versions, and the PCIe version used R300 and R400.

The R400 is in the x500 X700, x800, x850, x750 etc

x1000s are all R500 except for the x1050 and then it generally settles into a naming system with the retail names aligning with the architecture generations.

So, yeah, confusing as hell. Not sure if it can be made easily clear in the table how messy this is. 202.92.108.163 (talk) 03:25, 1 July 2024 (UTC)[reply]

Should we include Matrix numbers from RX 7000 series onwards?

[edit]

Maybe it's time to include the TOPs and TFlops numbers from matrix operations that the RX 7000 Series and onwards have due to WMMA, as AMD is further improving them and adding new datatypes as FP8 for RDNA4.

Not making the template too big, only selecting a few of them

What's your thoughts on the matter? 201.235.238.56 (talk) 23:04, 6 March 2025 (UTC)[reply]

I'm curious about this as well. These column currently seem confusing, as the RX 7000 series show the same TFLOPS for Half- and Single-Precision operations. For example, the spec page for the 7900 XT lists FP16 ops for Vector and Matrix at 103 TFLOPS, yet the this list says 51.6 TFLOPS. Shawngmc (talk) 04:33, 20 September 2025 (UTC)[reply]

Steam Machine

[edit]

Somebody added to RDNA 3 desktop. At little prematurely. It could be just RX 7600M. Elk Salmon (talk) 10:16, 13 November 2025 (UTC)[reply]

I have a question about a edit

[edit]

I was Wondering in this paragraph "TBP (Typical board power) – Typical power drawn by the total board, including power for the GPU chip and peripheral equipment, such as Voltage regulator module, memory, fans, etc., measured in Watt."

(isn't Watt at the end is that plural?) if I'm wrong please feel free to tell me I have not edited this yet Very high frequency (talk) 12:55, 5 December 2025 (UTC)[reply]