AMD CPUs please

This makes me remember all the buzz around Harry Potter’s Nimbus 2000 that was instantly done away with once the Slytherin team all got brand new Nimbus 2001’s.

2 Likes

The ryzen 6000 series seem perfect for laptops like the 13 inch Framework. The power efficiency is going to be very important, as the framework laptop, doesn’t have the best cooling or battery. Another great reason for a ryzen version.

3 Likes

Yeah! Alder Lake is looking very battery intensive!

Ryzen 6000 is Zen 3+, not Zen 4. But it does have USB4 with all the Thunderbolt 3 capabilities. It would be a fine choice for the next generation Framework motherboard.

As for the 5800H beating the CPUs in the current Framework, of course it does – that’s an 8C/16T processor rather than 4C/8T. Alder Lake vs Ryzen 6000 will be a closer competition in processor performance, though the RDNA2 iGPU in Ryzen 6000 will blow away Intel.

Alder Lake can use a lot of power if you let it; the desktop parts in particular are going to be power hogs, just like all recent high end Intel desktop parts. But it also performs well in the power envelope of the Framework.

Not to go beating a dead horse, but I feel that’ll only be the case if Framework has made farther progress on open-source firmware since Framework has a major Linux user-base and focus as well as a general overall company philosophy that is the exact opposite of locked-down black boxes - especially ones that are made and designed by what is effectively a “competitor” (to put it lightly) for many of Framework’s users.

To put my concerns another way, regardless of its improbability, would people be OK with the idea of a future Framework laptop that uses an Apple M1 CPU?

If it had freed firmware and didn’t have the ghastly SSD performance that apparently ARM MacBooks have, then yes. I’m not so hung up on soldered RAM and SSD’s. So long as schematics and parts are made available to third party repair shops, I should in this scenario be able to receive an affordable repair. But seeing as none of those factors would likely be true…then obviously no.

Which is what I’m getting at here since, if the Phoronix forums are to be believed, then a lot of Linux enthusiasts have a less-than-favorable opinion towards Microsoft to put it nicely (for the not-so-nice stuff, just go read this Phoronix forum thread yourself).

So up until January 3rd I thought I was all-in on a theoretical Ryzen 6000 Framework Laptop, but on January 4th it became obvious that I was really all-in on a Framework Laptop with open firmware more-so than one specifically powered by AMD.

In other words, the announcement of Ryzen 6000 made me realize more-so where my interests lie - with Framework more-so than AMD (and may have been part of my motivation to stop “lurking” and actually create a forum account).

2 Likes

Sad but true that Intel has the money to pay for the development work and AMD simply doesn’t feel compelled to respond in kind. I don’t know much about Pluton although I am not particularly happy about the Intel ME and adding another black box doesn’t thrill me. I will say that I’m pissed that AMD only deigned to grace their APU’s with RDNA2 because Intel is only now kicking them into high gear on iGPU’s. It’s the same garbage Intel did with 14nm++++ for all those years. The hypocrisy is staggering.

So as a hardware person, I feel the need to address that AMD’s focus on Vega for all previous Zen-based APUs makes sense for several reasons.

#1 there was only one generation of GPU architecture between Vega and RDNA2, that being RDNA1. And I recall RDNA1 being admitted by engineers themselves as almost being more like “incomplete RDNA2”.

#2 Tying into RDNA1 being “incomplete RDNA2”, this also makes sense why the consoles and even the Steam Deck all use RDNA2 graphics - because that’s the actual complete design of that given architecture. This means that, timing-wise, Ryzen 5000 APUs may have been the hypothetical earliest that it could have been implemented. Well, except that…

#3 AMD’s desktop product cadence follows something like 14-15 months (not including what seems to have been a bit of an “aborted arc” for Zen3D and Zen4 now rumored to be coming earlier than previously expected), but their mobile product cadence is shorter at only around 12-13 months, so it makes sense that they have to do an almost Intel-like tick-tock in terms of where to prioritize development, and previously the CPU architecture were of much more importance. But with Ryzen 6000 power consumption become the major focus (Zen3+ supposedly has no increase in IPC…but of course, better power management means higher clocks which means better CPU performance anyway), and the updated GPU is actually a big part of that since more performance-per-watt means, for the same task, you consume less power. And video decoding is something part of the GPU and video playback is obviously a very important aspect of battery life.

#4. You’ll notice that all RDNA2 products are at least DDR5 which leads me to believe that, at the architectural level, it does not even support DDR4. And if they added support for that, then it’d end up of course requiring more time to design and we already established that their mobile products have a shorter cadence. And of course, one key point of DDR5 is that it uses less voltage and therefore power than DDR4 and, as mentioned, power consumption was a big focus of Ryzen 6000. Tying into this is the rumored 12nm+ 4core Zen3+RDNA2 APU that is looking to launch later this year, my guess as a new Athlon for along-side Ryzen 7000 on AM5, and AM5 of course uses DDR5.

#5 Supposedly Van Gogh was actually supposed to come out around the same time as the consoles (late 2020/early 2021) which ties into what I said in #3 whereby that design as well as the consoles put development focus on the GPU aspect rather than the CPU, hence why they all have Zen2 cores despite Zen3 mobile launching just a couple of months later. In other words, AMD only had the time and/or man-power to design either Zen2+RDNA2 (i.e. old CPU + new iGPU) or Zen3+Vega (i.e. new CPU + old iGPU). But if the new iGPU wasn’t even designed to work with DDR4 memory, then it was possibly a bit premature for that design to show up anyway…

2 Likes

@NM64 even if RDNA2 wasn’t possible because of DDR4 incompatibility, as you yourself noted, there was RDNA before that and regardless of how “incomplete” it was, it did offer significant performance-per-watt improvements over Vega. Those benefits would have mattered to laptop users immensely, regardless of performance gains.

Perhaps I’m just wearing my tin-foil hat too tightly but all this seems awfully convenient timing as Intel pumps money into their nascent graphics division

But there isn’t even an integrated iGPU version of RDNA1. You can’t just slap desktop RDNA1 onto a CPU and call it a day as it basically shares the same memory controller as the CPU, and the memory controller was brand-spanking new on Zen2 while Zen3 uses the exact same memory controller as Zen2.

I’m guessing you’re also not aware that AMD uses leap-frogging teams, and supposedly a lot of man-power kept being diverted from Raja’s Vega team over to the console RDNA2 team. And surely you’ve noticed who the head of Intel’s graphics is, and it’s no secret that he brought a decent amount of people with him (if you payed attention to the hype and marketing before Vega’s desktop launch, you may have noticed the odd similarities in overall tone to Intel’s own graphics marketing in the last year or two, and it’s no accident that Chris Hook was/is the head of marketing for both).

Heck there was even a, at the time, unbelievable rumor posted by Kyle Bennett on HardOCP that AMD’s graphics department wanted to become it’s own entity again (e.g. back to ATI) and then merge with Intel. This was literally (not figuratively) months before there was any hint at all that Intel wanted to really get into the graphics game. I can’t find the original article even on archives, but this forum thread has snippets:

The tl;dr from that forum post being the following - remember that this is from mid-2016!

Former ATI loyalists inside AMD are trying to spin off from AMD in order to become supplier of gpu technology for Intel

So basically with the benefit of hindsight, it looks like the Vega team under Raja were more of “ATI loyalists” as that forum post puts it, and essentially defected to Intel.

It’s also worth noting that the head of the graphics division after Raja left and AMD moved full focus onto RDNA, David Wang, has graphics history going back to the N64 and GameCube with SGI and ArtX more-so than ATI directly (ATI bought out before the launch of the GameCube ArtX, and then AMD bought out ATI before the launch of the Wii).

1 Like

intel licensed the APU technology from AMD years ago but never did anything with it.

Whomever wants this should be reaching out to help frame.work & Project X collaborate. I’m sure they’d both be willing to help each other and it would be a boon for us. Project X is working towards corebooting modern AMD CPUs.

Also note, all modern AMD CPUs in ThinkPads support ECC, but the motherboards do not. It would be easy for the first AMD model from frame.work to have a motherboard that supports ECC. Linus Torvalds would definitely give it a big shout out (as he has been trying to spread info about this)!

Of course I’m aware, I’m also aware that the foundations for each generation are laid years before launch. The same year Vega launched on desktop, there were APUs launched with Vega integrated graphics, so you can’t tell me that AMD couldn’t have done the same thing with RDNA.

It no longer matters at this point, I’m just pointing out that the constant “rah rah AMD! Savior from big bad Intel!” Is completely undeserved. They are no better. Launching APU’s with better graphics is only because Intel is catching up in the iGPU department. If it was possibly to cram gas-guzzling Vega (designed on a larger node) into an APU, it would have been possible to do the same for RDNA (designed on the same node as the CPU).

Yeah, I bet Koduri has something to do with that, I know he headed the graphics division at AMD. I didn’t know how many people he took with him but it doesn’t surprise me.

Again, none of this matters now, it just pisses me off but I could get over that if there was Coreboot support for these CPUs, but support for AMD CPU’s is sparse to say the least

2 Likes

The more I think about it, the more I think it makes sense for FW to focus on Ryzen 7000 instead of Ryzen 6000 for an initial AMD release. I think if they started to focus on Ryzen 6000 now, by the time they can ship units, Ryzen 7000 will have been released and will steal some thunder. If they focus on Ryzen 7000 instead, they can start shipping in probably Q2 2023. This gives FW plenty of time to work on design, firmware (including coreboot support), getting supplier arrangements in place, etc.

2 Likes

This is actually one big part of my interest in AMD CPUs over Intel is that you can actually get ECC on consumer products quite easily - I myself have two older PC with ECC and, sure enough, they’re just running bog-standard desktop AMD CPUs. My primary desktop and HTPC do not because, well, they’re Intel consumer products, so no ECC…

Interestingly, there’s information around that states that even non-Pro APUs actually have the hardware to work with ECC but it’s just that I think it’s AMD’s AGESA that is is set up that non-Pro APUs don’t have ECC exposed while Pro APUs and non-APUs do (when combined with a motherboard that supports ECC of course)

Except that Vega on desktop launched notoriously late - it was supposed to launch about a year earlier than it really did which is also why “big Polaris” never saw the light of day as it was canceled in favor of what looked to be Vega launching soon after the RX 480 & 470… but a couple of months turned into a year or so.

The tl;dr of all of this is that AMD’s graphics division was not exactly firing on all cylinders like their CPU division until RDNA2 with inconsistent and oddly-staggered incomplete product stacks.

1 Like

@NM64 I think there are logical inconsistencies with what your are saying but it is pretty clear to me that nothing I say will dissuade you from AMD’s defense

Nothing you say will dissuade me from my stance that AMD is a corporation with no real “loyalty” to anything but their shareholders and if AMD can milk a last gen product for every last penny, then that’s what AMD will do.

So let’s just agree to disagree but neither of us will convince the other

Unfortunately you didn’t see my most recent edit in time - ECC is a big reason for my interest in AMD over Intel which is also why it became clear that my true interest is in open firmware instead of the CPU vendor as that’s the real key to ECC support, not whether your CPU is Intel or AMD.

That being said, a possibly more important aspect for me is a strong preference for dead-silent systems for day-to-day use and especially when I’m doing audio work and only “crank up the performance” when I do something like a video render or batch audio conversion and, unless there’s a way to run a theoretical Alder Lake system on ONLY the E-cores, an AMD CPU currently is simply going to have a greater performance-per-watt at the power levels required to maintain silence - this wasn’t always true though as my own main desktop PC is Haswell-based as that was the ideal choice for a silent PC back in 2013/2014.

(OK I’m done editing now)

2 Likes

An equally disgusting demonstration of anti-consumerism by Intel, artificially gimping consumer IMC’s to not support ECC doesn’t do anything but demonstrate a lack of confidence in your own product

Although, I recently saw a comment asking if it were possible to disable the PSP and a quick google search revealed that at least briefly an option to do so was given to consumers on desktop

So there must be an AMD equivalent to the HAP bit in the Intel ME

If that’s true and AMD can be supported in Coreboot, then I’m more into AMD than Intel as it likely won’t gimp sleep states the way disabling the ME does on Intel

Unfortunately I don’t really have a reliably functional GPU to test this out or I would check to see if that is still the case with my X570 board

The irony is that both of my Intel systems run a CPU that does support ECC despite the newer CPU being a consumer model (the older one is just a used desktop Xeon), but where the heck can one find a motherboard that allows you to actually use that ECC?

Worse still is that it’s a rare post-Nehalem Intel CPU that supported both ECC and overclocking, and the CPU has a measly 3.2GHz base clock despite being able to run overclocked at 4.5GHz 1.24v absolutely rock-solid stable (i.e. with way more stability than any sane person would ever actually require*), and I’ve never heard of an Intel-socket motherboard that supported both ECC and the ability to over/underclock and/or over/undervolt (something I can do on my older AMD systems) - again why open firmware would be very important.

*for reference I find that OCCT’s “large dataset” test is basically the end-all for stability, at least when not using AVX (no idea about with AVX as my CPU doesn’t support it) - I’ve had systems pass the likes of prime95 overnight that could still crash, but I have never ever had an undervolt or an overclock fail if it was able to pass OCCT “large data set” after 24 hours (and even then, if you can pass it over night, you’re almost always good to go unless you’re just OCD about it like I am). I like using the old v4.5.1 of OCCT since it can be ran portable which is useful on test systems either running a live OS from USB or an otherwise bare-bone installation (also fun fact - OCCT v4.5.1 works in WINE 7.x!)