Talk:Epyc

Controversy over locking of CPUs to specific vendor platforms
Covered today by ServeTheHome. This feature, which is likely present in Ryzen CPUs as well opens up the possibility of abuse by hackers to permanently brick the CPU, should they manage to execute code on the PSP. — Preceding unsigned comment added by 81.129.200.169 (talk) 20:06, 9 September 2020 (UTC)

Zeppelin die?
What is a Zeppelin die? The term is use but not explained or wikilinked. 49.145.130.102 (talk) 16:34, 17 July 2017 (UTC)
 * I believe it's AMD's codename for the specific version of the silicon die used in this first generation of Ryzen, Ryzen Threadripper and Epyc products. I'm not sure though, I'm confused myself. Might be hard to source. &mdash;ajf (talk) 16:37, 17 July 2017 (UTC)
 * The Zeppelin die, as I understand it, is the 8-core silicon die that is the basis of the Zen microarchitecture. (This includes the memory controller, etc. The whole chip.) ajf is probably right, this may be hard to source clearly. The clearest definitions I have seen is pre-release rumors that otherwise I don't think meet the standard to cite. I don't know if AMD has every officially confirmed the Zeppelin name, though. However, I have seen Zeppelin used in more recent (and citable) sources. It may take some cobbling together of sources to get a proper and well cited definition. Dbsseven (talk) 16:51, 17 July 2017 (UTC)
 * Hey, looks like AnandTech's new review of ThreadRipper mentions Zeppelin: http://www.anandtech.com/show/11697/the-amd-ryzen-threadripper-1950x-and-1920x-review/3 &mdash;ajf (talk) 14:47, 10 August 2017 (UTC)
 * For now I just made it say "Zeppelin dies (the same die as found in a Ryzen processor)" uncited. &mdash;ajf (talk) 14:51, 23 August 2017 (UTC)

EPYC or Epyc?
Both are used in the article. Perhaps it should be decided which is correct. 49.145.129.243 (talk) 16:23, 10 August 2017 (UTC)
 * Followed convention and made all uses be Epyc, and mention EPYC stylisation in the lede. &mdash;ajf (talk) 17:32, 10 August 2017 (UTC)
 * , what convention was used? AMD uses EPYC. Within the secondary sources it appears mixed, but the majority appear to also use EPYC.   Therefore, I would suggest EPYC is more probably more correct. Dbsseven (talk) 19:59, 10 August 2017 (UTC)
 * …honestly, “Epyc” was what Wikipedia was already using more often, so I just went with that. You may be right that EPYC is better. &mdash;ajf (talk) 02:54, 11 August 2017 (UTC)
 * I would prefer "Epyc" and I think it's also correct according to MOS:TM. -- intgr [talk] 07:46, 11 August 2017 (UTC)
 * Normally I would agree, but it is worth noting the MOS:TM states to use Epyc "as long as this is a style already in widespread use". I am not sure that Epyc is in widespread use (relative to EPYC) and think this exact point is what we should discuss. Dbsseven (talk) 18:34, 11 August 2017 (UTC)

I guess this is worth revisiting to avoid edit warring with. Recent edit notes have stated that the stylization of EPYC in the lead is a waste of time. I would disagree. And as I understand the discussion here, at no point was it suggested to remove the stylization entirely. Directly on this topic MOS:TM/STYLE states explicitly it is convention to note the stylized version of a trademark in the lead. Even Curly Turkey's note of MOS:TMCAPS uses as an example eBay, which includes a "stylized" in the lead. Dbsseven (talk) 22:55, 10 October 2017 (UTC)
 * "Epyc" is not an acronym for anything, and ALL-CAPS in names and titles is entirely trivial. eBay is an example where the stylization is trademarked and used by third parties.  "Epyc" fails both tests.  This both is misleading and clutters up the lead.  If there's any legitimacy at all to the ALL-CAPS, then the article name itself should be moved. Curly "JFC" Turkey 🍁 ¡gobble! 00:04, 11 October 2017 (UTC)
 * The recent edits I am discussing are in the lead and address the stylized version of the trademark. Acronyms are not an issue here. (Acronyms are capitalized throughout the article. Not the case with this edit.) To address your points: EPYC is used in third party sources, as discussed above.  And it is trademarked. Including the stylized keeps with the MOS (MOS:TM/STYLE) and adds clarity to how the product is presented/marketed. (As examples see Dell and nvidia, neither are acronyms.) As for the idea of moving the article, I believe that is directly topical to the discussion above. Dbsseven (talk) 00:40, 11 October 2017 (UTC)
 * "EPYC is used in third party sources"—not systematically, and not any more than you would expect third-party sources to randomly ALL-CAPS a trademarked name. The ALL-CAPS in the logo are utterly unremarkable and sticking it up first thing in the lead serves no reader in any way shape or form.  It's not even trivia.  It's noise. Curly "JFC" Turkey 🍁 ¡gobble! 03:11, 11 October 2017 (UTC)
 * MOS:TMRULES states "widespread use", not absolute/perfect use. And EPYC's use cannot be random if it is used consistently by multiple third-party sources. In fact, this cannot be the standard as some articles have multiple "stylized as" versions, i.e. nvidia and Asus.
 * I appreciate your effort to remove "noise" or "trivia", but these are personal opinions. I disagree and I am not even the editor who added this . Again, I believe the stylized clarifies the marketing/presentation of the article's subject. Therefore, as this appears to be an editorial disagreement about article structure WP:structure, I propose we follow the policy to achieve a WP:NPOV, which is to follow the MOS. If the issue is that the MOS should exclude this sort of material in general, that talk page would probably be more appropriate for the discussion. Dbsseven (talk) 12:22, 11 October 2017 (UTC)
 * perhaps and  would like to discuss as-well? Dbsseven (talk) 12:25, 11 October 2017 (UTC)
 * Dbsseven: "but these are personal opinions"—you've got to be joking. And why are you linking to MOS:TMRULES to support this noise?  If MOS:TMRULES applied, we'd need a page move.  Worse, have you actually read MOS:TMRULES—particularly what it says about Time, Asus, etc? Curly "JFC" Turkey 🍁 ¡gobble! 10:36, 12 October 2017 (UTC)
 * Not joking at all. And I have in-fact read the whole MOS:TMRULES, which states to use standard English in the article. (Which is done in this article.) However, the same page of the MOS also states it is convention to indicate the “stylized as” in the lead, as was done here before the edit. (And the examples in the same MOS:TMRULES referenced often do exactly this: Asus, The Players Championship, Kiss.) So should we follow the MOS, and the whole MOS, or not? Dbsseven (talk) 13:35, 12 October 2017 (UTC)
 * And how does cluttering the lead with this noise serve the reader in any way? Can the reader not recognize an ALL-CAPped name without Wikipedia holding their hand?  I hope we're not resorting to Wikilawyering to cram everything we can get into the lead. Curly "JFC" Turkey 🍁 ¡gobble! 21:01, 12 October 2017 (UTC)
 * I believe it clarifies that the product is not marketed as Epyc, but rather as EPYC. That products will be branded and advertised by the manufacturer in this particular way. (Just as AsusTek Computer Inc. markets is products under the name Asus, nvidia, etc.) I'm not saying this is a huge addition, which is why it only takes 18 characters to include. How is this clutter and noise, exactly? (And I don't believe it is wikilayering to discuss and find common consensus, including using the MOS, so articles are formatted and improve in a consistent manner.) Dbsseven (talk) 18:24, 13 October 2017 (UTC)

The source you provide is again primary; it might be an argument for a page move, not for trivial lead clutter. Are you promoting a page move? Curly "JFC" Turkey 🍁 ¡gobble! 20:58, 13 October 2017 (UTC) As an additional possibility (in addition to the previous "stylized as", or adding a graphic), the CPU infobox has an optional "brand1" line where we could list "EPYC" to make clear the product branding (the result being "Brand name(s) EPYC"). While away from the MOS for indicating stylization, this would get it out of the lead and make clear it is the branding of the product. I believe this could satisfy most current viewpoints. Thoughts? Dbsseven (talk) 20:13, 13 October 2017 (UTC)
 * (notified at the MOS page); speaking for the video game project, we routinely do not include the all-caps stylization if it is not an initialism, unless there are other stylization effects involved (eg Adrift (video game) is mentioned its stylization as "ADR1FT".) Too many products frequently use non-initialism all-caps of an otherwise normal word to make pointing that out unnecessary, particularly if we have imagery that shows the branding. --M ASEM (t) 15:04, 12 October 2017 (UTC)
 * Very good points . However I am not clear if there is a similar convention for hardware as their is for game software (as noted with the nvidia and Asus examples). Also, there is no imagery here to otherwise indicate the stylization. Dbsseven (talk) 15:32, 12 October 2017 (UTC)
 * Imagery-wise, you can opt to include the Eypc logo (it is a 100% valid use of non-free logo), or alternatively, based on Google images, a free image of a Epyc CPU case, that has the name emblazened on it, is possible. --M ASEM (t) 16:19, 12 October 2017 (UTC)
 * It's not "hardware vs software"—it's "what's the point of something so trivial"? How does it serve the reader? Curly "JFC" Turkey 🍁 ¡gobble! 21:03, 12 October 2017 (UTC)
 * noted there was a community consensus within the video game project on how to deal with stylization. This is a good example where the community came to a general consensus to use box-art rather than prose. However, I was simply noting there does not appear to be a similar consensus in the computer hardware field (again examples of nvidia and Asus). In the absence of additional information somewhere in the article, I believe it serves the reader (and is non-trivial) to know how the product is marketed/branded. But this is exactly what is being discussed here. Dbsseven (talk) 17:47, 13 October 2017 (UTC)
 * Yeah, use "Epyc" in the text; it is not an acronym, so we would not capitalize it to mimic the logo, per MOS:TM. It's not required to have something like "(stylized as EPYC)" in the lead, though such a note is common, if the trademark is uniformly stylized that way. For simple capitalization it's probably superfluous (e.g., we have no such note at Sony), but such notes are helpful for less routine stylizations, e.g. at Client (band).  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  20:48, 12 October 2017 (UTC)
 * I restored the “stylised as EPYC” bit and cited AMD's website. AMD use “EPYC” consistently, and some (but not all) third-party sources do, so it seems remiss not to mention that. OTOH if we were to include the logo, maybe that bit could be removed again. &mdash;ajf (talk) 12:57, 13 October 2017 (UTC)
 * ajf: Don't ever pull something like this again. You were told there was a discussion underway—your choices are to join it or stay away—and the "sourcing" is absurdly unacceptable.  Whatever the outcome of the discussion, it will not be acceptable to use such a source in such a way. Curly "JFC" Turkey 🍁 ¡gobble! 14:26, 13 October 2017 (UTC)
 * can we please keep this civil? Yelling at and criticizing other editors here and in edit summaries does not appear in keeping with civility, even if the discussion isn't complete here.
 * And how citing the copyright owner is "absurdly unacceptable" as a cite for the stylization? (Though I would have cited AMD's copyright page or Epyc branding guidelines to be more on point.) Dbsseven (talk) 17:08, 13 October 2017 (UTC)
 * The source ajf provided was primary and doesn't discuss capitalization. The editor does not comment on the source—the editor reports on what's in the source, and the source says nothing about the comment "often stylized blah blah blah".  Sources can never be used in this way.
 * I am simply arguing for the inclusion of a notation of the "EPYC" branding within the article. While stylized appeared to be general convention based on the MOS:TM/STYLE, this appears to merit discussion here. What did you think of the infobox alternative below? Dbsseven (talk) 21:19, 13 October 2017 (UTC)
 * I don't see what purpose that would serve to the reader. Why not just do what others have recommended—putting an image of the logo in the infobox? Curly "JFC" Turkey 🍁 ¡gobble! 04:18, 14 October 2017 (UTC)
 * An image is a viable possibility. But as multiple proposals have been put forth/supported by multiple users, I was simply suggest the infobox option that I think satisfies most/all objections. I generally prefer prose over adding media, as media is not always available (ie. on mobile or otherwise limited connectivity). (And I believe all proposals, except complete removal, serve the same purpose: to inform the user of the branding.)Dbsseven (talk) 12:53, 14 October 2017 (UTC)
 * I don't see the point, but at least it doesn't intrude on the reading experience. I won't say I support it (because I don't), but I won't oppose. Curly "JFC" Turkey 🍁 ¡gobble! 02:07, 15 October 2017 (UTC)
 * One should never be afraid to play around with caps, as long as there is a logical explanation for doing so, as per MOS:TMRULES. Punctuation, spacing, etc is a different matter, but caps may be dropped/gained as you please, pretty much. – Sb2001 talk page 13:22, 18 October 2017 (UTC)
 * To the contrary, it obviously results in screaming disputes like this one. We have a Manual of Style for good reasons, and it should be followed.  If you want to experiment with style, do it in your own sandbox, not in live article text.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  04:09, 21 November 2017 (UTC)
 * I agree with you about following the MoS, both to maintain civility and consistency in style across WP. But as was noted in this discussion, this can come across as "Wikilawyering". Dbsseven (talk) 17:08, 21 November 2017 (UTC)
 * The actual wikilawyering is when people bend over backwards to try to find "loopholes" and "exceptions" to permit an over-stylization to mimic a trademark. A central principle at WP:CONSENSUS, WP:POLICY, and various other pages is that WP's rules (the policies and guidelines) are to be interpreted in the spirit in which they are intended, not with an eye toward system-gaming any weaknesses found in their wording. The absolutely clear intent at WP:MOS generally and MOS:TM and MOS:CAPS in particular, is that WP does not apply a stylization, including capitalization, to the name of any subject unless the vast majority of independent, secondary, reliable sources do so consistently with regard to that particular subject.  That's clearly not the case with Epyc, who are capitalizing their logo in exactly the same manner as Sony's "SONY" logo. It simply is not an acronym, and nothing is going to change that fact.  We all know that people get unreasonably hot around the collar about style matters (because, at the psychological level, everyone fluent in a language has an innate sense of "mastery" of it, and this leads to feelings that anyone who writes differently is "wrong" in a WP:TRUTH and WP:GREATWRONGS sense), so toying around with style in "live" articles in a willy-nilly manner is demonstrably disruptive.  We spend more time at RM testily rehashing the same style matters – that are in fact  by the rules we have – than we do about virtually anything else, and this really needs to stop.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  18:40, 21 November 2017 (UTC)
 * You are right about consensus about language being difficult, but we did find something like that here without edit warring. Noteworthy, given the lively discussion. (Thought at no point did I consider it a "screaming", personally.) But I believe you've missed the issue with regards to the MOS. The question was no longer if a capitalized version should be used throughout (already settled in August), but centered around if "stylized as" should be used at all. (My fault for not creating a new section in October.) This goes to the clarity and relative weighting of the MOS. Even your example of Sony is confusing to me, it does not exactly jive with the Asus example on MOS:TM with regards to the stylized issue. If there is a consensus about if a "stylized as" should be used consistently, or some other standard, a note accordingly there would be helpful. I am not active on the MOS page, hence why I do not know the "clear intent" and asked for input. I have no desire/intent to wikilawyer, and am happy to reach any consensus/resolution. (as done here) But I suppose that consensus should fit the greater consensus on styles for the topic, and for WP in general (through the MOS). Dbsseven (talk) 20:09, 21 November 2017 (UTC)
 * When people start commenting with things like "Don't ever pull something like this again", that's what I call screaming in this context. There is no consensus that a "stylized as" is . It seems reasonable to include one, especially in absence of a logo, so people are certain they're on the right page (we can't assume that every reader is already certain whether the "EPYC" they encountered is an acronym or not or what it refers to).  If we do illustrate the logo with its EPYC style, then a "stylized as" note is rather superfluous, and is likely why it was removed from the Sony article.  I'm glad to see recognition that we no longer entertaining the idea of moving this to EPYC or writing "EPYC" throughout the article text. PS: Please keep replies attached to the posts they're replies to; and all this bulletizing is unnecessary (this isn't a vote, and bulletizing replies to the non-bulleted makes reply markup unnecessarily complicated).  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  21:20, 21 November 2017 (UTC)
 * MOSTMSTYLE clearly states that "it is conventional" (emphasis added) to include a stylization note in the lead, and explicitly includes "capitalization changes" within its purview. Looking through the discussion, I see no good reason to not include the note. If there is an objection to the guideline, it should be taken up at the MOS talk page. James (talk/contribs) 18:44, 21 November 2017 (UTC)
 * I'd almost bet money that "capitalization changes" refers to situations such "iPod", and not to trivial ALLCAPSing. But again, this all sounds like wikilawyering, rather than focusing on what best serves the reader.  The reader wants the text to get to the point, and does not want to traverse line noise such as predictable ALLCAPS variations of a trade name.  Can someone give a cogent argument for interfering with the reading experience without resorting to "but if we stand on our heads, the MoS looks like it says ..." ...? Curly "JFC" Turkey 🍁 ¡gobble! 21:44, 21 November 2017 (UTC)
 * I'd take that bet. It absolutely refers to what you call "trivial ALLCAPSing". Situations such as iPod are explicitly dealt with in a separate section of MOS:TM. What best serves the reader is a subjective ideal: I believe the reader is well-served by identifying variations on the topic's name. Nobody is standing on their heads, the guideline is perfectly clear – if you object to it, feel free to attempt to establish a global consensus for changing it. James (talk/contribs) 23:21, 21 November 2017 (UTC)
 * James: in other words, you prefer to stick to lawyering ("capitalization changes" == ALCAPS is quite the acrobatics). Why not at least go through the motions of providing that "cogent argument for interfering with the reading experience" I asked for?  Because you don't actually have one?  You simply love yourself them ALLCAPS? Curly "JFC" Turkey 🍁 ¡gobble! 00:06, 22 November 2017 (UTC)
 * That would probably be a better discussion on the MOS talk pages. But as I understand it, the reason for a MOS is that no single editor knows "what best serves the reader". This is why consensus building occurs for style, not just content. If a particular case/field is exceptional, then a local consensus can be found. (, if you'd like the MOS simplified to "Consult Curly Turkey, they know what the reader wants", I wish you the best of luck.) Dbsseven (talk) 23:49, 21 November 2017 (UTC)
 * Dbsseven: That's all you got out of this discussion? No wonder we're going around in circles. Curly "JFC" Turkey 🍁 ¡gobble! 00:06, 22 November 2017 (UTC)
 * Certainly not all, . Just summarizing. :) Dbsseven (talk) 00:15, 22 November 2017 (UTC)
 * It would be nice if editors could approach articles with the readers in mind, rather than interfere with editors who do. Curly "JFC" Turkey 🍁 ¡gobble! 00:18, 22 November 2017 (UTC)
 * I assume all editors do. Dbsseven (talk) 00:22, 22 November 2017 (UTC)
 * "they know what the reader wants" is hardly a shining example of AGF, and I don't see arguments being made that ALLCAPS benefits the reader—rather that it can be "gotten away with" if we read the MoS in a particular way. There's no end to the amount of sourcedd information that could be crammed haphazardly into an article that the MoS doesn't (and shouldn't) disallow, and we have mountains of nigh-unreadable messes throughout Wikipedia as a result.  Some of us are trying to remedy that.
 * (If only I had the understanding to do that at Glycated_hemoglobin—I got a medical exam back yesterday and wanted to know what "Haemoglobin A1c" was. Wikipedia was the wrong place to try to find out ... I'm sure it all makes sense to the people who wrote it.) Curly "JFC" Turkey 🍁 ¡gobble! 00:58, 22 November 2017 (UTC)
 * How was quoting you ("The reader wants...") within "they know what the reader wants" not AGF? I wished you good luck even. Dbsseven (talk) 01:03, 22 November 2017 (UTC)
 * In seriousness, I do know some biochemistry and might be able to answer your A1c question(s) (Olive branch).Dbsseven (talk) 01:08, 22 November 2017 (UTC)
 * Thanks! My question is: what is it, and why should I care (apparently my numbers were fine, I just had no idea what the numbers were referring to). Curly "JFC" Turkey 🍁 ¡gobble! 01:50, 22 November 2017 (UTC)
 * (Over)Simplified, A1c is checking for diabetes by measuring you average blood sugar over the last few months. This is better in many respects than your current blood sugar. If you just drank a Pepsi and had high blood sugar, that might be okay. But if you were fasting and had high blood sugar, not okay. Measuring A1c takes the timing out of the test. As for what it does: it measures the amount of the hemoglobin (the red, oxygen carrying protein in your blood) which has reacted with the sugar in your blood. This reaction happens naturally, but if you've got more sugar in your blood it happens more often. As your red blood cells have a fixed lifetime, ~3-months, this gives an average of your blood sugar over that time. (Plus in the medical world, I imagine they like things they can measure from blood. It's a lot easier than a biopsy.) Dbsseven (talk) 02:18, 22 November 2017 (UTC)
 * Well, that was nice & clear! One more question: they only took one blood sample.  How could they know my blood sugar level for the previous three months? Curly "JFC" Turkey 🍁 ¡gobble! 02:43, 22 November 2017 (UTC)
 * Because the blood cells only "survive" 3 months. The hemoglobin was modified sometime after it was made, so measuring your A1c from that sample gives an average over that time window. (But this is only an average, they don't know what is was 3 months ago or what it is today, from this test.) A poor analogy: Say you want to know where a tiger generally lives, it's range. You can check on that tiger every day... Or you can note where all the paw-prints are, and conclude it has lived in somewhere within the range defined by those the paw-prints since the last time it rained. (Sorry, not the best analogy but having trouble coming up with something better.) Dbsseven (talk) 03:07, 22 November 2017 (UTC)
 * Okay, I think you've answered my question well enough. thanks again! Curly "JFC" Turkey 🍁 ¡gobble! 04:59, 22 November 2017 (UTC)

Vulnerable to Meltdown & Spectre‽‽
Million-dollar question: Are they vulnerable to Meltdown and/or Spectre? –61.2.48.24 (talk) 09:19, 18 September 2018 (UTC)
 * Nope for Meltdown and very limited to Spectre (besides Spectre V1 which affects all modern processors to date). --Denniss (talk) 11:31, 18 September 2018 (UTC)

new released Epycs (Rome) with higher base clock
https://www.planet3dnow.de/cms/54858-fuenf-neue-amd-epyc-prozessormodelle-mit-teilweise-deutlich-hoeherem-basistakt-gelistet/ -- 92.117.191.78 (talk) 13:08, 11 February 2020 (UTC)

Misleading backronym
As far as I can tell, this diff on the 23rd shortly after some guy on Quora backronym'd it. A few news sources including NASDAQ on the 26th and Yahoo on the 27th (and only in sources appearing after the 23rd) then appear to have used the uncited edit as a source and should not be used to readd the acronym to the article (as this would create a false citation loop).Techhead7890 (talk) 09:54, 18 March 2021 (UTC)

In need of updating
The Milan section really needs updating from future tense to present tense, but I can't be arsed to rewrite it all. (I wish people would care more for the stuff they originally write here) --jae (talk) 06:08, 25 March 2022 (UTC)
 * Hey, I went and updated some of the Milan stuff and added Milan-X, let me know if I missed anything --Justanotherintrovert (talk) 22:24, 27 April 2022 (UTC)

Standardizing tables
All the models tables are in super inconsistent organization. Milan is sorted in descending order of core count, Naples is sorted in ascending order of price, and I'm not quite sure what Rome is doing. Snowy Owl also follows descending order of core count, and I think all the tables should be updated to reflect that, but wanted to get feedback here first, any other suggestions? Justanotherintrovert (talk) 22:28, 27 April 2022 (UTC)


 * Not only that, but also, Epyc 7001 series has release dates and prices combined into one column, 7002 series has them separately, and 7003 series omits the release date column. AP 499D25 (talk) 14:15, 24 November 2022 (UTC)
 * It makes the most sense for processors to be organized by their names in ascending alphabetical/numerical order. CristoCalis (talk) 15:33, 24 November 2022 (UTC)

What about the OEM-specific releases
Is there a reason this article omits all of the vendor-specific OEM releases? Specifically the parts for MS Azure, Google, and Amazon.They are starting to come up on the secondary market. It was very confusing not finding them here. The 7B12 OPN-100-000000020, 7V12 OPN-100-000000056, 7D12 OPN-100-000000044, 7R12 OPN-100-000000027, 7R32 OPN-100-000000091, 7K62 OPN-100-000000109, 7V13 OPN-100-000000320, and more, EPYC 7713, 7543, 7J13, 7T83. Evil genius fin (talk) 23:24, 2 March 2023 (UTC)


 * After a year without any reaction, it is time to propose a table listing all vendor-specific OEM processors. Data-centers sell their old hardware including these OEM processors. I have also been confused not finding them on Wikipedia :-/ Oliver H (talk) 11:49, 25 March 2024 (UTC)

Embedded 7001/7002/9004 series?
There is no mentions about embedded 7001, 7002 or 9004 series? ,

Should we treat this as new entries, like Embedded 3000 series is?

Or we just add note to existing 7001/7002/9004 sections (and tables), for example "also available as embedded X model" or something. Specs are more or less the same, what would be the point of identical tables. Rando717 (talk) 21:30, 1 April 2023 (UTC)


 * I would add them in a separate section on the Epyc article. Although, if the Epyc Embedded processors are radically different from the normal server ones enough that there would be significance in creating a separate article about them, then creating an article is the logical option. — AP 499D25  (talk)  12:52, 11 May 2023 (UTC)
 * Forgot to reply... I recently changed first gen table design and added "embedded option" column with links pointing to embedded counterparts. Any thoughts about it? Rando717 (talk) 19:20, 18 October 2023 (UTC)

Epyc 8004 Siena as part of the standard or embedded section?
Should the lineup for the Epyc 8004 Siena SKUs be in its current location in the 4th gen table alongside Genoa and Bergamo CPUs or should it be moved under the embedded section alongside Snowy owl? There's already an embedded specific CPU lineup for Genoa, but the parts are basically 1:1 from a spec perspective Justanotherintrovert (talk) 12:03, 18 October 2023 (UTC)


 * Epyc 8004 series SKUs are Zen4c based CPUs using SP6 LGA socket, unlike embedded BGA package. I don't think they belong inside embedded section next to Snowy owl series. Zen4 and Zen4c cores are identical (arhitectually), so in my opinion they should remain within 4th-gen section. But I don't think they should be inside same table with Genoa and Bergamo models, because of different sockets (SP5/SP6) and naming convention (8004/9004).
 * A while ago, I started working on unified design for all Epyc and embedded tables (including Ryzen), but didn't released anything until recently on first gen tables. [example]
 * I lost time (and will) to search for references about OEM models. If you want, you are welcome to take 8004 section and make "AMD Epyc 8004 series" template from it. Rando717 (talk) 19:01, 18 October 2023 (UTC)

New Milan EPYCs
I'm absolutely terrible at table formatting so maybe someone else can tackle it, but some new 3rd gen EPYCs were recently launched in September and aren't on the table. Stormscape 09:27, 15 November 2023 (UTC)

Epyc 4004 series
To those who regularly update this article: today AMD introduced the Epyc 4004 series, which are apparently processors that utilise the AM5 platform and go up to 16 cores, with some 3D V-Cache variants available as well: announcement.

I'm guessing they'll go under the "Epyc 4th gen 9004 series" table but tbh I think we should split up the template into separate templates for the Epyc 4004, 8004, 9004 and 9704 processors. — AP 499D25  (talk)  02:13, 22 May 2024 (UTC)