Talk:List of AMD graphics processing units

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computing  
WikiProject icon This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
 ???  This article has not yet received a rating on the project's quality scale.
 ???  This article has not yet received a rating on the project's importance scale.
 

Whither Vega?[edit]

I wonder at what point the new Vega GPU should be added? I'm not trolling, and I did not edit the article page. The thing has been released...

70.65.117.140 (talk) 04:51, 28 June 2017 (UTC)

Analog VGA output is missing on newer cards[edit]

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

"Radeon Rx" vs "Radeon RX" confusion[edit]

In the english Wikipedia we have used "Radeon Rx" (lower case x) to denote the variants of the Radeon series, i.e. R5, R7, R9. Which worked fine so far. However with the 400 Series AMD introduced a new variant "Radeon RX" (upper case X), which is confusing when reading through the articles and already produced some confused edits [1]. Also I noticed that the newer AMD Radeon 400 series article omitted the "Rx" in-between (contrary to the AMD Radeon Rx 300 series and former). Shall we backport this scheme to the earlier articles as well? Other suggestions to avoid the confusion? Wikiinger (talk) 10:41, 14 March 2017 (UTC)

I changed now most of the occurrences of "Rx" (wherever possible) to "R5/R7/R9" to minimize confusion. Wikiinger (talk) 10:53, 27 April 2017 (UTC)

Dropping API column[edit]

I have added a new section "API Overview" along with this table Template:AMD_graphics_API_support, which is shared with the Radeon article. The table needs refinment on the Direct3d feature levels, but otherwise I think we are good to go and drop the API columns from the individual tables. Which I will go ahead with once I have some spare time. Wikiinger (talk) 14:21, 24 April 2017 (UTC)

☑ Done. Wikiinger (talk) 10:23, 17 August 2017 (UTC)
Wikiinger With the recent edits of the individual product line templates the APIs have been removed. While I agree that it makes the table far more compact and readable, it can be helpful when comparing the feature set of multiple products within the same product line. (For example: which of the RX 400 series products support OpenCL 2.0?) A footnote might help clarify this without requiring expanding the table. (I see there is a API column on the Template:AMD graphics API support template, but this is not replicated on the individual product pages.) Dbsseven (talk) 14:51, 17 August 2017 (UTC)
First of regarding the rationale: one reason was indeed to make the table more compact and readable, but the other important reason is that the API support is not so much a HW-feature, but more driver dependent. For instance one some cards you have different API-support depending on whether you are using the windows driver or one of the linux drivers.
Regarding checking for the API: for the List of AMD graphics processing units there is Template:AMD_graphics_API_support, for the individual product pages the API support is stated in the infobox (at least for the newest gen). Furthermore since AMD often crams multiple generations in one product line, I fear one footnote might not be enough, which may makes things messy again...
With that being said, I don't see the need for such a footnote(s). However if you (or someone) want to go ahead, I would request that such a footnote is behind a template toggle such as |API=on/off (with default being off), so that the footnote doesn't show on List of AMD graphics processing units. Wikiinger (talk) 19:05, 17 August 2017 (UTC)
I don't have a definitive source, but my understanding is that it isn't just a SW feature, but requires hardware support too. And in any case, it is a differentiator between products within a product line as much as other specs.
In any case, more I am concerted about the inherent confusion of the article stating the maximum API support (usually in the infobox), while this is not true for all products in that generation's product stack. (See AMD Radeon 400 series vs the corresponding template Template:AMD Radeon Rx 400.) This is particularly relevant for the Radeon Pro lines of products which do not have individual articles, but a single page for all product generations. I will try to come up with a simple clear footnote for the tables. Dbsseven (talk) 21:09, 17 August 2017 (UTC)

Boost values (was:For consistancy)[edit]

AMDs offical site says RX480 is upto 5.8TFLOPs but the number here says 5100. I did alot of the earlier entries myself using boost clock for the performance calculations since boost clock became a thing. It might be an idea to either provide both sets of performance numbers or to update either one to just us base or boost. More of a consistancy thing probually dosn't matter to much. — Preceding unsigned comment added by 58.179.111.133 (talk) 12:47, 29 July 2016 (UTC)

You are right and there is now a new table layout to cope with both values. The idea is to state the performance of boost clock in brackets and below the base clock performance.
Note: that I changed the headers of the tables accordingly, however I didn't calculate all the values - feel free to hop in here. :-) --Wikiinger (talk) 20:36, 22 February 2017 (UTC)

Rx 300 table width[edit]

This table has become far too big! It exceeds the page width at 100% on a 1920-pixel wide monitor. 125.254.43.66 (talk) 03:15, 24 June 2015 (UTC)

I suggest to delete the GFlops/W column. Visite fortuitement prolongée (talk) 19:38, 24 June 2015 (UTC)
I should add that it doesn't "unwrap" the cell contents until you zoom out to 70% on the same 1920-pixel wide monitor. Many of the other tables in the article are similar. There is far too much information in them for a single table. 125.254.43.66 (talk) 02:11, 25 June 2015 (UTC)
It should hopefully be better now. I think we can drop transistor counts and die size too if we wanted since they don't seem too interesting(?)--Kyousuke.k (talk) 05:51, 11 July 2015 (UTC)
  1. Thank you.
  2. The Fab process, Transistors count and Die size columns are more about the chip itself than the video card, but since the pages are named "List of ... graphics processing units" and since the tables are not too wide now, I suggest to keep them.
Visite fortuitement prolongée (talk) 19:24, 11 July 2015 (UTC)
It still is definitely too wide. ScotXW tried shrinking the font sizes, but it is bad form and is a violation of wikipedia policy. We should look into potentially moving some of the information out of the table, and into the header instead (not sure which parts though. Fab size, bus type, and API support might be good fits, and it may make sense to remove launch MSRPs entirely). Alternately, we could break it into two sets of tables per product line, one for the card specs, and one for the API information. This would allow us to fit in even more information (if needed), and if broken up in a sensible manner, could substantially improve readability. Something like this (still needs to be tweaked):
Model Launch Codename Architecture Fab (nm) Transistors (Billion) Die Size (mm2) API support (version) Release Price (USD)
Direct3D (FL) OpenGL OpenCL Vulkan
Radeon R5 430 (OEM) 30 June 2016 Oland Pro GCN 1st gen 28 1.04 90 12.0 (11_1) 4.5 2.1 1.0 OEM
Radeon R5 435 (OEM) 30 June 2016 Oland GCN 1st gen 28 1.04 90 12.0 (11_1) 4.5 2.1 1.0 OEM
Model Bus interface Clock rate Core config Fillrate Memory Processing Power
(GFLOPS)
TBP (W)
Core (MHz) Boost (MHz) Memory (MT/s) Pixel (GP/s)
(Boost)
Texture (GT/s)
(Boost)
Size (GiB) Bus width (bit) Bus type Bandwidth (GB/s) Single Precision
(Boost)
Double Precision Half Precision
(Boost)
Radeon R5 430 (OEM) PCIe 3.0 ×8 730 780 1800
4500
384:24:8 5.84
(6.24)
17.52
(18.72)
1
2
128 DDR3
GDDR5
28.8
72
560
(599)
37.4 560
(599)
50
Radeon R5 435 (OEM) PCIe 3.0 ×8 1030 N/A 2000 320:20:8 8.24 20.6 2 64 DDR3 16 659 41.2 659 50
50.101.168.70 (talk) 03:02, 2 November 2016 (UTC)
A couple days ago FF9600 re-implemented the font size shrinking that had been reverted, making it quite hard to read a lot of the charts. Does anyone have any comments on this proposal? 70.49.130.192 (talk) 19:41, 18 February 2017 (UTC)
Actually, it looks like Wikiinger's changes seem to have shrunk the table's width enough that displaying them at full size no longer causes roll-over at most resolutions, and shrinking the font sizes are now causing a gap on the right side on many monitors. The changes already in place might be sufficient. 70.49.130.192 (talk) 19:45, 18 February 2017 (UTC)
The 80% font size does NOT create a gap on the right side on any of my devices. Quite the contrary it makes them almost fit in. Among them is also a HD laptop screen which I think is fairly common... Anyways I changed the font-size to 90% which I think is a fair compromise.--Wikiinger (talk) 20:43, 22 February 2017 (UTC)
PS: It would be nice if we could find an elegant solution to get rid of the API column. However two tables is IMHO not the way to go. --Wikiinger (talk) 20:46, 22 February 2017 (UTC)
90% is better (it's above Wikipedia's minimum of 85%. "In no case should the resulting font size drop below 85% of the page font size"), but it still is shrinking the data (and making it harder to read) rather than trying to fix the root of the problem (the layout of the tables themselves), which is important as Wikipedia's guidelines say that font size changes should be an absolute last resort. 70.49.130.192 (talk) 02:01, 12 March 2017 (UTC)

Issues with Wikiinger's Proposed Table Changes[edit]

Since Wikiinger opted to not follow wiki norms of have proposed changes that directly affect the established tables on this article (and by proxy the tables used in the individual Radeon article main pages) on this actual talk page, I've started the discussion in its proper location. Here are my list of issues with their proposition:

  1. It directly combines cells into things are not directly related, and therefore creates more confusion and clutter than necessary.
  2. The merging also creates confusion of have multiple parenthesized items in the header which also create additional confusion to others that are not as familiar with some of the terms, e.g. "Core (MHz) (Boost)".
  3. The merging of rows makes the reader to have to "zig-zag" when attempting to relevant data pertaining to a specific GPU. It also creates additional work to maintain the row spans and creates more potential to someone to go back & fix incorrect row spans.

  #FF9600  talk 20:03, 4 March 2017 (UTC)

First of all you should read and understand Template talk:GPU Chipset Table where I explained the changes I did in every detail. To your points:
  1. to generic, be more specific
  2. this is only a small price we have to take, furthermore from the values in the cell belows it is pretty obvious what is meant.
  3. By the merging of rows, the reader is actually able to more easily follow a GPU (row) since there are less columns to track through (often the GPU column is already out of the screen when at the API section).
All in all, I feel that your points are rather vague and actually not severe.
In contrast the old layout has font-size 80% (which is against the MOS), and doesn't even fit with this tiny font on a widescreen. Which makes it really hard to "relevant data pertaining to a specific GPU".--Wikiinger (talk) 22:46, 4 March 2017 (UTC)
  1. Your respond makes no sense.
  2. It may be obvious to you, but I can easily see someone becoming confused. This is a poor "user experience" choice.
  3. You're misunderstanding. Rows are the horizontal lines, while columns are the vertical lines. rowspan is a way to have the same data "span" across multiple rows. By using rowspans to have the same data span across the row is makes the data float vertically in the middle of the cell, making the reader have to go up & down when reading a single row.
The tables fit perfectly fine on my 1920 px wide widescreen. So I don't see your issue with fitting the data on the screen especially since 1920 px wide is pretty much standard. I really think you need to read over what I wrote and what you responded with because a lot of your responses don't make a lot of sense.  #FF9600  talk 02:22, 5 March 2017 (UTC)
  1. Which cells do you think combine info that are not strongly related to each other? Because there are non, IMO.
  2. The "new line (Boost)" info in the header is already used in the old layout for precision. By applying that very same scheme for the clockrate, the boost values align nicely in the row, which in turn increases user experience.
  3. (Yeah, I confused rows and columns in my last reply.) Well, I'm open to that. OTOH you have to see that by merging rows it is easy to see at a first glance which models share features (e.g. all OGL 4.5, Architecture, etc.). For example by merging the die size, it is easy to see which models share the same die and have different binning, which wouldn't be so easy to spot otherwise. So there is clearly a trade-off.
  4. Table Width - there is no point in denying that the table width with the old layout is an issue (see other discussions above). Even if it fits on your FHD display, then it does only so with 80% font-size. Furthermore you have to keep in mind that future GPU generation bring new features, which will likely further increase the table width. For example there is now a "Half" precision column and we don't know what else upcoming GPUs bring.
Wikiinger (talk) 10:38, 7 March 2017 (UTC)
  1. None of the of them IMO.
  2. Yes "Precision level (Boost)" is already used, but you'll notice in that case it doesn't have two sets of parenthesis in the header while only presenting one set of parenthesis data in the cells below.
  3. Yes there is a trade-off between rowspanning & not rowspanning the data. I still believe not rowspanning the data makes it easier to read the data set for a specific chip then when the data is rowspanned. In addition, rowspanning the data creates a higher level of error when adding or updating the data.
  4. Yes there is an issue with the table width, there is no denying that. By personal opinion is the data is easier to read separated like it is currently. One thing I would be open to dropping is the API sections from the table, since the entire table is purely physical hardware specs, while the API section is more software related. (Yes the physical capabilities of the hardware does play into or limit the APIs that chip supports, but still). The inclusion of the API levels also adds to an additional area of ongoing maintenance to the tables, since API support can "upgrade" over time to a chip.
  #FF9600  talk 16:34, 7 March 2017 (UTC)
  1. So you are fine with the merging of similar data (eg model-&codenam, archi&fab, etc)?
  2. Look at the Fillrates "Pixel /n (GP/s) /n (Boost)" it is already there... Maybe omitting the parentheses alltogether or use italy font
  3. Rowspanned data should be easier to update, since you only have to change it once (e.g. all the GCN 1.1 -> GCN 2nd gen). There is hardly any adding to these tables. I really like the rowspanning on the Arch/Fab and the Trans/Die column, since it adds information here, we can drop it for the others.
  4. Agreed on the API. However just dropping API columns isn't sufficient for an acceptable table width (see pt 1 & 2).
Wikiinger (talk) 22:24, 8 March 2017 (UTC)
I think rowspanned data is actually harder to update. Changing wholesale (ie your example of GCN 1.1-> GCN 2nd) is a rare issue, rather the insertion of a new product which breaks the rowspan is a pain to fix. I would agree that rowspans can make it harder to read across the table also. Dbsseven (talk) 02:28, 14 March 2017 (UTC)

Alternative Layout for Boost values[edit]

Here is a suggestion for an alternative Layout. I removed the "(Boost)" text from the header and put it in a sentence as footnote. This makes the header much clearer, otoh people need to read the footnote first to understand the two values. Thoughts? (Also I exchanged the brackets with italic font (debatable).) Wikiinger (talk) 10:33, 22 March 2017 (UTC)

Model
(Codename)
Launch Architecture
(Fab)
Transistors
Die Size
Core config[a] Clock rate[b] Fillrate[b][c][d] Memory Processing Power[b][e]
(GFLOPS)
TBP (W) Bus interface API support (version) Release Price (USD)
Core (MHz) Memory (MT/s) Texture (GT/s) Pixel (GP/s) Size (GiB) Bus width (bit) Bus type Bandwidth (GB/s) Single Double Half Direct3D (FL) OpenGL
OpenCL
Vulkan
Radeon
RX 480
(Ellesmere XT)
29 June 2016 GCN 4th gen
(14 nm)
5700×106
232 mm2
2304:144:32 1120
1266
7000
8000
161.3
182.3
35.8
40.5
4
8
256 GDDR5 224
256
5161
5834
323 5161
5834
150 PCIe 3.0 ×16 12.0 (12_0) 4.5
2.0
1.0 $199 (4 GB)
$239 (8 GB)
  1. ^ Unified Shaders : Texture Mapping Units : Render Output Units
  2. ^ a b c Boost values (if available) are stated below the base value in italic.
  3. ^ Texture fillrate is calculated as the number of Texture mapping unit multiplied by the base (or boost) core clock speed.
  4. ^ Pixel fillrate is calculated as the number of Render output units multiplied by the base (or boost) core clock speed.
  5. ^ Precision performance is calculated from the base (or boost) core clock speed based on a FMA operation.

☑ Done. Wikiinger (talk) 10:23, 17 August 2017 (UTC)

Reformating for VEGA series & on[edit]

The VEGA seires supports 8 bit "Quarter" precession at 4x rate & 16 bit "half" precession at 2x rate. It would be better if we could get 2 more coloms for those figures. Bus Interface & release price not praticuarly useful pieces of information.

I'd suggest putting bus interface above the table seeing it changes at most once per a generation. I'd suggest deleting the price information all togeather it's not revelant for very long & having it as a retrospective serves little value. — Preceding unsigned comment added by 218.215.130.97 (talk) 08:20, 26 March 2017 (UTC)

  • Until VEGA is released everything is hearsay, we will not reformat anything till then.
  • Half precision (16-bit) is already in the table. Never heard of "quarter" precision.
  • Release Price is a very useful information to rank the different cards (also cross-vendor), even more so in retrospective. No way we are gonna drop this.
  • API columns are about to be dropped (since it is not so much HW spec). However we need yet find a way how to advert it.
Wikiinger (talk) 13:58, 26 March 2017 (UTC)

there is something TERRIBLE WRONG in the calculation of "Processing Power"[edit]

FirePro R5000 (Febr. 2013) - 1267.2 GFLOPS - <150 Watt

Radeon Pro WX 7100 (Nov. 2016) - 4.15 GFLOPS - 130 Watt


How can a high end card create only about a 300th about 3 years later?!? -- 87.167.88.53 (talk) 09:52, 19 April 2017 (UTC)

Memory clock column[edit]

Currently the core and memory clock rate share the same subsection, however the memory clock often actually differ by memory size. So I think it is more sensible to move the memory clock in the memory subsection, where it is also used to determine memory bandwidth:

Model
(Codename)
Launch Architecture
(Fab)
Transistors
Die Size
Core Fillrate[a][b] Processing Power[c]
(GFLOPS)
Memory TBP (W) Bus interface Release Price (USD)
Config[d] Clock (MHz) Texture (GT/s) Pixel (GP/s) Single Double Bus type &
width (bit)
Size (MiB) Clock (MT/s) Band-
width (GB/s)
Radeon
RX 480
(Ellesmere XT)
29 June 2016 GCN 4th gen
(14 nm)
5700×106
232 mm2
2304:144:32 1120
1266
161.3
182.3
35.8
40.5
5161
5834
323
365
GDDR5
256
4
8
7000
8000
224
256
150 PCIe 3.0 ×16 $199 (4 GB)
$239 (8 GB)

Thoughts? Wikiinger (talk) 10:09, 19 April 2017 (UTC)

PS: Actually while am it, I would also move the Processing Power section to the left. This way all the boost values align up nicely. Wikiinger (talk) 10:35, 19 April 2017 (UTC)

☑ Done. Wikiinger (talk) 10:19, 17 August 2017 (UTC)

Table Width[edit]

The tables are too wide. I suggest dropping the Clock Rates, Fill Rates, Processing Power and Bandwidth (memory) columns. At least for later generations of cards (HD 2000 and above). Manufacturers release variations with different gpu and memory frequencies so the values in those columns only apply to the cards that use stock values. The only things shown in the tables should be fixed specifications, not specs that can differ. NitroX infinity (talk) 23:09, 11 November 2016 (UTC)

Obviously the specs refer to the AMD reference cards / design. Furthermore if we would drop all this information there would be very little of interest in these tables... However I agree that the tables are way to wide, hence I proposed and implemented an new layout, which narrowed the tables a lot. However we might still need to cut some columns (API?, see also Template_talk:GPU_Chipset_Table)... --Wikiinger (talk) 20:27, 22 February 2017 (UTC)


Cite error: There are <ref group=lower-alpha> tags or {{efn}} templates on this page, but the references will not show without a {{reflist|group=lower-alpha}} template or {{notelist}} template (see the help page).