Inside the Steam Deck's APU
boilingsteam.com
boilingsteam.com
Since recently buying an AMD based laptop I've come to realize how much better Intel's software support, both in Linux AND in windows is. And that patterns moves all across AMD product lines.
For example, they pressured all vendors to drop S3, dropped it from Phoenix and went all in with Microsoft's s2idle without any clear way to support it. As a result you have multiple vendors with half working idle implementations, overheating and other bugs.
Intel has also vastly surpassed AMD is their ML stack, even though their GPU's are less powerful.
I may have to buy a new laptop in the near future. Linux is my default OS. I've been happy with my existing Ryzen 7 3000 series laptop for 5 years or so. I want to know if Intel is doing better these days.
Windows had BSOD daily (reddit suggested to replace wifi card - it helped). Sometimes audio output became muffled.
After few months body coating started to peel off in some places.
I wish I bought something else!
I'm running nixos and plasma wayland without any issues. Even the fractional scaling works out of the box.
for i in $(cat /proc/acpi/wakeup|grep enabled|awk '{print $1}'|xargs); do case $i in SLPB|XHCI);; *) echo $i|tee /proc/acpi/wakeup ; esac; done
[1] https://gitlab.freedesktop.org/drm/amd/-/issues/?sort=create...Are there still Intel parts with working S3? Linux seems to think that my 11th gen intel laptop supports it, but it doesn't work (hangs on going to sleep). I haven't figured how to coax Windows into using that instead of s2idle. This particular model doesn't offer a BIOS toggle for that, as I hear it was the case on some thinkpads.
I'm also not convinced the s2idle situation is that much better on the Intel side. I sometimes use Windows on my work laptop and let it hang around suspended when I'm done for the day. Yesterday evening (Sunday), after two days of doing nothing, it figured it would be as good a time as any to turn into a jet engine. I also sometimes find it is pretty warm coming out of my backpack after a 45-60 minute commute with a long portion of walking, even when it's close to freezing outside (we've had a few weeks of 0-2º days where I live). This doesn't seem like an isolated thing: see all the people complaining about other manufacturers' laptops not going to sleep properly while being carried around closed in bags.
---
edit: found a way to enable S3 on windows. It goes to sleep but doesn't wake up. It actually seems to mess up the PC so much that after a forced reboot the fan goes crazy for a few minutes before showing the UEFI logo.
It's astonishingly inexplicably broken and the industry completely ignores it.
I have 0 idea why.
But there's no denying that my quality of life took a hit by this "improvement": I now have to go out of my way to choose hibernation or standby, depending on how long I expect to need it to sleep, instead of just closing the lid.
Under Windows, there's also the fact that you have to go out of your way to enable hibernation.
The only issue is that s2idle drains the battery like crazy compared to S3. But I guess "it's not a bug / works as intended".
Properly working s2idle should use as little power as S3, but it seems to be much more common with s2idle that some piece of hardware is left enabled while it should have been disabled to save power.
Does anyone actually have that? I'd really love to hear with which hardware/software!
AMD has this https://gitlab.freedesktop.org/drm/amd/-/blob/master/scripts...
On Linux, the fan never turns on and the pc never gets warm while asleep. Windows sometimes does something that requires the fan to spin like crazy, and the PC is usually somewhat warm to the touch.
NVIDIA GPUs definitely make things more difficult, at least in the suspend-then-hibernate case. Here's where I reported a hacky workaround:
https://forums.developer.nvidia.com/t/systemds-suspend-then-...
See also:
https://github.com/systemd/systemd/issues/27559
NVIDIA kinda sorta just doesn't give a shit, unfortunately.
It's probably trivially solvable, but I haven't cared enough to fix it when I can just kill/restart the service.
It's caught me out a few times where I haven't noticed and frankly seems like a safety hazard as it'll get very hot.
(If anyone has tips to prevent this that would be great, running fedora)
Putting the laptop to S3 sleep puts the M.2 SSD into some kind of sleep mode, when the system wakes back up, it fails to wake the M.2 SSD back up. The sleeping M.2 SSD mode is persistent across reboots, so upon reboot the laptop fails to boot because it can't find it's main storage. The only way I've found to fix this is to pull the SSD and put it in another working machine.
S0ix is also completely broken under linux with it draining the battery 30% in around 4 hours.
Does it work better under Windows? On both my machines, one zen3 and one intel 11th gen (but otherwise almost identical hp laptops) I don't see any difference in battery drain between the two.
even the touchscreen / stylus works great and that is not my words but a family member that gifted my laptop (due to irrelevant to tech, life reasons)
And then Valve "underspent" (although perhaps more of an MVP) by taking an existing good-enough chip, perhaps able to get very good yield out of fab (at a time when fabs were costing a fortune), and found yet another corner to cut on a device that is overall pretty low build quality, to hit an aggressive price point. I love my Steam Deck, and I loved the low price, but the build quality is "good enough" at best.
Valve have reversed course with the new generation, having a custom chip now that they've proved out the demand, and I expect the device will improve across the board as they take advantage of higher volumes, and perhaps an ability to price a little higher too.
I wouldn't be surprised if Magic Leap also reverse course (or already have done? are they still around?) by moving to much cheaper off the shelf or pre-existing hardware.
I don't think it indicates any use of inferior materials or build quality per se, just that they designed around existing components to avoid the high initial cost of a bespoke SoC.
We are really swiming in astoninishing objects, even the simplest glass or a ball pen is a marvel.
So much it's now a baseline.
At the same time having a very high reparability. I feel like these two metrics are complementary and I am happy that they went for reparability instead.
If you exclude the awful glued battery with the audio cable taped on it.
The main things that break - buttons, need to be factory replaced and calibrated because the track pads are on the same boards.
As Nintendo did with the Switch, which has been an overwhelming success. The Steam Deck is the Switch for Valve, both technologically and as a business/marketing point of view.
Genuinely curious, what do you consider low build quality on them?
I'm also absolutely fine with these trade-offs for the price point, and in fact if pushed, I'd probably rather have a £400 device like this compared to a £500+ device with the same spec made of aluminium with slightly better inputs.
Consider the first Magic Leap headset. They thought it would do over 100,000 units. It only did 6,000. https://www.engadget.com/2019-12-06-magic-leap-6000-headsets...
I don’t know how the Leap 2 is doing. But in the above example, let’s say AMD wanted a minimum order of 100,000. If you were Magic Leap, you’re running to find a buyer - any buyer. You’re also going to cut the price for your batch as far as necessary to cover for possible increased production costs in the future. Even if you recover just half of your costs, it’s better than being forced to buy chips nobody wants that will quickly go stale.
My guess is that Magic Leap, a company infamous for spending profligately, paid for the NRE on this design, and then didn't buy very many of them or pay for exclusivity on it (or let any exclusivity go). AMD is notorious for shopping around designs they've already got ready to ship (probably related to sibling comment's observations about the console graphics market), and Valve runs lean despite not having to, and so this story adds up quite nicely. There may or may not have been some inventory lying around, but the NRE is usually the real story on these things. (It's also possible that the custom Magic Leap sections of this chip have terrible yield -- actually that wouldn't surprise me at all -- and so these were great candidates for die harvest. Which of course is also the sort of thing AMD loves to sell.)
So, no proof, but it wouldn't be any kind of surprise if this were part of the problem.
Also Valve do some steamdeck optimizations for every game via their shared shader cache. Which enables it to run a lot smoother than competing portable x86 systems.
Isn’t the only purpose of this skipping shader (re)compiling?
As far as I understood it, they did it because compiling shaders both takes long on a handheld device and time is at a premium for handheld players. They don’t want to wait eight minutes for a shader compile.
1. Load times if you’re compiling them on stage load
2. Dynamically on asset load during gameplay.
The latter is one of the most major causes of stuttering in PC games, and Valves solution can greatly make a game feel smoother as a result.
With that in mind, proton _is_ the killer app.
Do you have any source for this? I don't recall seeing this kind of info so far.
https://www.roadtovr.com/valve-working-on-vr-steam-deckard-o...
[0] https://electronics360.globalspec.com/article/20179/techinsi...
Besides, even if you could enable these DSP cores you'd be hard pressed to do anything useful with them, I don't believe there's any public documentation or tooling whatsoever for Cadence DSPs.
Going in and fixing that blown trace inside of an IC is beyond the capabilities of almost everyone because decapping a chip renders it inoperable.
edit: here's someone talking about running decapped chips. https://electronics.stackexchange.com/a/400899
Decapping with extreme prejudice.
Not if somebody's put a metal layer on top of it. You can only meaningfully fiddle with the top surface of a decapped chip.
The SMU reads the eFuses to determine what to lock down. So you can interrupt this process via JTAG and re-enable all the locked down cores. There is a window of a couple of milliseconds after de-asserting reset to halt the SMU.
I have no idea if this still works on newer chips with the AMD Secure Processor. There was some mention of a JTAG password in the leaked AMD documentation on the Web.
I'm not into that stuff anymore, I'm playing around with FPGAs now. No more locked down security processors to get in your way.
Most chip fuses are "antifuses": you pass high current through them, and instead of evaporating a fusewire like in normal fuses, it causes physical changes that reduce resistance.
Only the clean head-on die-shots (he also does these) need a metallurgical microscope - those are hard to find and very expensive, they're also highly proprietary optical systems, so accessories and objectives are rare and expensive, too.
I remember having a look at the documentation about all those quirks (was a text file in mesa at the time)... and I did postpone my alternative to ACO spir-v to AMD GPU ISA translater... ahem (whishing the hardware to go thru some fixing first...).
It’s kind of interesting how they have this hold on gaming outside of conventional PCs, but can’t seem to compete with nvidia on just that one market.
https://semiaccurate.com/2011/08/05/what-is-project-denver-b...
Would of been interesting to have had another large x86 player
This could help them make inroads to people who might not have considered a home console before due to their relatively large size. Wouldn’t be surprised if the Switch did well with this market and now MS wants a slice of that pie.
I am not expert, but I cannot remember ever hearing that before. Why would arm have better absolute performance than x86?
As a spectator, reading tech press about architectures gave me the impression that even in performance per watt, the advantage arm has over x86 is fairly small, just that arm chip makers have always focused on optimizing for low power performance for phones.
Better general design, or easier to include more cache. All the normal reasons one architecture might perform better than another. I mean, you heard about Apple switching all their processors to ARM, right?
> As a spectator, reading tech press about architectures gave me the impression that even in performance per watt, the advantage arm has over x86 is fairly small, just that arm chip makers have always focused on optimizing for low power performance for phones.
Intel would certainly like you to believe that. But for all their talk of good low-power x86s being possible, no-one's ever actually managed to make one.
Apple's decision to switch to ARM had many reasons, licensing being just as important as performance, perhaps more so.
The low power variants of Zen are very efficient. You're still looking at Intel, but they've been leapfrogged by AMD on most fronts over the past half decade (still not market share, but Intel still has their fabrication advantage).
Intel tried and ran into most of those same problems. Their Atom-based SoCs were pretty competitive with ARM chips of the day, it was the reliance on an external modem, friction with x86 on Android and a brutally competitive landscape that resulted in their failure.
Regardless of architectural advantages from one vendor or another, the point remains that the arguable preeminent expert in CPU architecture believes that ISA makes little difference and given their employment history it's hard to make the argument of bias.
The way I remember it the performance and battery life never quite lived up to what they said it would.
> Regardless of architectural advantages from one vendor or another, the point remains that the arguable preeminent expert in CPU architecture believes that ISA makes little difference and given their employment history it's hard to make the argument of bias.
Current employer is a much heavier influence than prior employers, and someone who's moved around and designed for multiple ISAs and presumably likes doing so has a vested interest in claiming that any ISA can be used for any use case.
There's a long history of people claiming architecture X can be used effectively for purpose Y and then failing to actually deliver that. So I'm sticking to "I'll believe it when I'll see it".
Maybe apple could have stayed with x86 from AMD with some sort of co-design, but apple likely preferred to design their own chip so they would control the whole process and keep more of the profits. Designing their own chip also seems like it allowed apple to leverage their investments in TSMC for making their phone chips to also include their laptop chips. I wonder whether they already had a long term plan to dump Intel, or whether the plan started as a reaction to the serious problems that began developing at Intel years ago.
There's also Xtensa cores (audio coprocessor) and ARM cores included (PSP, Pluton, and I think there's extra ARM coprocessor for handling some sensor stuff optionally)
AMD uses ARM for its PSP as well which is more than just a TPM.
But afaik it also matters what type of license AMD has.
AMD would be need an ARM architecture license (like Apple has). This license allows you to do whatever you want with the chip (such as adding a x86 style memory model).
The downside to the architecture license is you have clean room design the chip entirely.
The fTPM does indeed run on the PSP, so on the ARM cores, among many other things like DRAM training.
Which instructions?
Note that this is actually very cheap in hardware. All ARM CPUs already support memory accesses that behave similarly to x86. It's just that they're special instructions meant for atomics. Most load and store instructions in Aarch64 don't have such variants, because it'd use a lot of instruction encoding space. The TSO bit in Apple's CPUs is really more of an encoding trick, to allow having a large number of "atomic" memory instructions without needing to actually add lots of new instructions.
If you want to be more lenient, the $129 Apple TV has A15 which is ~same design, but with less cores.
Sticking with AMD for GPUs makes sense no matter the CPU architecture. AMD is competitive on x86, and at the moment Samsung is working out the kinks to integrate Radeon GPUs with their ARM CPUs... so once Samsung has proven the concept works (and, of course, paid for the effort), maybe large consoles will make the switch.
It shouldn't be much of a problem for game studios in the end, most games run on one of the household-name engines anyway and they have supported ARM for many years for mobile games.
For PCs, discrete GPUs are getting bought separately so that doesn't apply. AMD does alright there but they were historically the underdog and highly budget-constrained, so without some kind of separate advantage they were struggling.
Now they're making a lot of money from Ryzen/Epyc and GPUs, and reinvesting most of it, so it's plausible they'll be more competitive going forward as the fruits of those investments come to bear.
[1] https://kotaku.com/report-xboxs-last-second-intel-switcheroo...
So it's not something Valve wanted to deal with. They commented on benefits of working with upstream GPU drivers, so it clearly matters.
(Does Valve keep the Steam Deck on a rolling/current Linux kernel? I'm honestly surprised if they do, because that seems like a lot of work and compatibility risk for minimal benefit)
Reasoning for the switch: https://en.wikipedia.org/wiki/SteamOS#Development
> The decision to move from Debian to Arch Linux was based on the different update schedule for these distributions. Debian, geared for server configurations, has its core software update in one large release, with intermediate patches for known bugs and security fixes, while Arch uses a rolling update approach for all parts. Valve found that using Arch's rolling updates as a base would be better suited for the Steam Deck, allowing them to address issues and fixes much faster than Debian would allow. SteamOS itself is not rolling release.
Being a client or even a partner doesn't guarantee good cooperation with Nvidia (Evga has a lot to comment on that). As long as Nvidia is not a good citizen in working with upstream Linux kernel, it's just not worth investing effort in using them for someone like Valve.
Stuff like HDR support or anything the like are major examples why it all matters.
Form factor (console or not) has no bearing on importance of this issue.
I doubt they care to work with valve to release steam deck as much as high end compute market
Going open source also means their contributions can propagate through the whole Linux ecosystem. They want other vendors to use what they're making, because if they do they'll undoubtedly ship Steam.
If AMD gets their act together and get the AI tooling for their GPUs to be as accessible as Nvidia's they have a good chance to become the winners there as you can get more VRAM bang for, again, less buck.
In a market where they have similar performance and everything minus ray tracing for somewhere between 50% and 70% of the competitor's prices it will be pretty easy to choose AMD GPUs.
They already have the best CPUs for gaming and really are positioning themselves to have the best GPUs overall as well.
My point is that Nvidia has the absolute highest end, but it's ridiculous to suggest that anyone with a budget less than the GDP of Botswana should consider the 4090 as an option at all. For actually reasonable offers, AMD delivers the most performance per dollar most of the time.
They might even be right. One of the potential advantages of the APU approach is if they GPU can be absorbed into the CPU with shared memory, a lot of the memory management of CUDA would be obsoleted and it becomes not that interesting any more. AMD are competent, they just have sucky crash-prone GPU drivers.
I have an AMD GPU on my desktop PC and I also have a Steam Deck which uses an AMD APU. Never had a driver crash on me on either system.
The issue is when using ROCm. Or more accurately when preparing to crash the system by attempting to use ROCm. Although in fairness as the other commenter notes it is probably a VRAM issue so I've been starting to suspect maybe the real culprit might be X [0]. But it presumably doesn't happen with CUDA and it is a major blocker to using their platform for casual things like multiplying matricies.
But if CPU and GPU share a memory space or it happens automatically behind the scenes, then the problem neatly disappears. I'd imagine that was what AMD was aiming for and why they tolerated the low quality of the experience to start with in ROCm.
[0] I really don't know, there is a lot going on and I'm not sure what tools I'm supposed to be using to debug that sort of locked system. Might be the drivers, might be X responding really badly to some sort of OOM. I lean towards it being a driver bug.
Ah yes. I'm pretty much only using it for games. It does seem that AMD's AI game is really lacking, from reading stuff on the Internet.
Generally the performance is at least as good on Linux so I stay there. Never had a driver issue.
The hardware of consoles has been general purpose for decades.
*except for the xbox one & one s, which had its own weird setup with unified DDR3 and a programmer controlled ESRAM cache.
Intel is in a far worse position - because they cannot do midrange graphics in an acceptable power/thermal range.
They're certainly good enough to be the integrated graphics solution for office work, school computers, media centres, casual gaming (the same as AMD's low end), and other day to day tasks.
That's most of the market, but I think it's a stretch to say that they're good enough for consoles.
Of course considering it’s Intel the power usage is way too high. Also AFAIK compatibility with pre DX11 games is poor and its not even clear Intel is eve making any money on it..
Linux probably helps here, with its greatly reduced background activity compared to Windows.
They may have seen AMD selling their own first-party cards and anticipated AMD eventually following Nvidia’s footsteps. As for Intel, at that point they were probably seen as too much of a gamble to invest in (and probably still are, to a lesser extent).
This compares with PSUs which apparently have a massive margin.
EVGA might come back to the GPU manufacturing space with AMD eventually but Sapphire and Powercolor already fill the niche that EVGA filled for Nvidia cards (high build quality, enthusiast focused, top of the line customer support, warranty, and repairs). So it probably was just not worth picking that fight when the margins aren't really there and AMD is already often seen as "the budget option".
If AMD manages to pull a zen style recovery in the GPU segment, I would expect a decent chance of EVGA joining them as a board partner.
Sure, "unreasonable".
The first is MS' trouble with the original Xbox (https://www.gamesindustry.biz/ati-to-provide-chips-for-futur... - not a great example (20+ year old articles are hard to find) but mentions the issues MS had with Nvidia)
Then there's Apple's drama, which involved warranty claims for laptop parts that led to them being AMD only until the Arm move (https://blog.greggant.com/posts/2021/10/13/apple-vs-nvidia-w...)
Sony only went with Nvidia for the PS3, but that may be more about AMD's APU offerings than Nvidia's shortcomings.
Whether these are signs of a trend or just public anecdotes is in the eye of the beholder or kept away in boardrooms.
It’s second-hand info so take it with a grain of salt, but I read somewhere that there was a lot of friction between Apple and Nvidia because Apple likes to tweak and tailor drivers per model of Mac and generally not be wholly dependent on third parties for driver changes, but that requires driver source access which Nvidia didn’t like (even though they agreed to it for quite some time — drivers for a range of Nvidia cards shipped with OS X for many years and those were all Apple-tweaked).
As for PC gaming, word of mouth plus a huge chunk of money for advertising deals. AMD, or back then rather ATI, drivers were always known for being more rough around the edges and unstable, but the cards were cheaper. Basically you get what you pay for. On the CPU side, it's just the same but without the driver stuff... until AMD turned the tide with Zen and managed to kick Intel's arse so hard they haven't recovered until today.
The console market is a different beast, here the the show isn't run by kids who have had NVIDIA sponsorships in games since they were first playing Unreal Tournament 2004 but by professional beancounters who only look at the price. For them, the answer is clear:
- generally, the studios prefer something that has some sort of market adoption because good luck finding someone skilled enough to work on PowerPC or weird-ass custom GPU architecture. So the console makers want something that their studios can get started on quickly without wasting too much time porting their exclusive titles.
- on the CPU side there's only two major architectures left that fulfill this requirement, ARM and x86, and the only one pulling actual console-worthy high performance out of ARM is Apple who doesn't license their stuff to anyone. That means x86, and in there there's again just two players in town, and Intel can't compete on price, performance or efficiency => off to AMD they go.
- on the GPU side it's the same, it's either AMD and NVIDIA, and NVIDIA won't go and use their fab time to churn out low-margin GPUs for consoles when they can use that fab time to make high-margin gamer GPUs and especially all the ludicrous-margin stuff for first coin miners and now AI hyper(scaler)s => off to AMD they go.
The exception of course is the Nintendo Switch. For Nintendo, it was obvious that it must be an ARM CPU core - x86 and performance under battery constraints Just Is Not A Thing and all the other mobile CPU archs have long since died out. Where I have zero idea is why they went for NVIDIA Tegra that was originally aimed at automotive and settop boxes instead of Qualcomm, Samsung or Mediatek but I guess that the former two demanded inacceptable terms (Qualcomm), didn't want to sell low-margin SoCs when they could run their own high-performance SoCs for their Galaxy lineup (Samsung) or were too sketchy (Mediatek), so they went for Nvidia who could actually use a large deal to showcase "we can also do mobile" for a world that was dominated by the three before-mentioned giants.
Let's not revise history. Zen was better than Bulldozer, but it still took until Zen2+ or Zen 3 (I don't recall exactly) until they reached parity with Intel Core i.
Before that, the vocal crowd was buying AMD because they are the underdog (and still are, to a point) and were cheaper (no longer the case).
Zen 1 launched offering double the core count of any of Intel's competing products at the same price. Intel was ahead on single core performance for a long time but in any well multi threaded benchmark or app Intel was getting absolutely demolished, with AMD offering twice the performance Intel was at any pricepoint. Intel failed to compete in multithreaded apps for 4 product generations, giving AMD enough time to close the single threaded performance gap too.
Now they are both pretty close performance wise, but AMD is well ahead from a power efficiency standing compared to Intel's competing CPUs.
Sure, and they got away with it because multi-thread workloads aren't relevant for the vast majority of the population. They still aren't today.
Most consumer computing workloads, including gaming by far, are dependent on single-thread performance. The vast majority of people do not spend their computing hours encoding video, compiling source code, or simulating proteins. They play games, surf Facebook, watch Youtube, read Mysterious Twitter X, and chat or call friends and family on LINE/Discord/Skype/et al.
In case you are detached from reality, I ask you to realize most peoples' computing needs today can be satisfactorily satisfied with an Intel N100. That's a two generations old 4 core, 4 thread CPU among the lowest tiers of consumer CPUs availabe.
Hell, I personally can satisfy all my daily computing needs with an Intel i7-2700K Sandy Bridge CPU without feeling hindered. I surmise most people will be satisfied with far less.
Another way to put it is: For all the core counts AMD Ryzen (and now Intel) brought, most people can't actually make full use of them even today. That's another reason why AMD Ryzen took so long to become a practical competitor to Intel Core i instead of a meme spread by the vocal minority.
I think a big part of this comes down to two things:
1. If you’re Nintendo, the Tegra X1 was the fastest mobile graphics chip available. Mali and Adreno weren’t anywhere close at the time. The alternative would’ve required shipping a Switch less powerful than the already-derided Wii U, which just was not an option.
2. Nintendo uses their own, in-house operating system that fits into under 400MB and runs on a microkernel. Naturally, you want good GPU drivers. NVIDIA’s philosophy is to basically make a binary blob with a shim for each OS. Not great, but it demonstrably shows the drivers can be ported with fairly little effort - Windows, Mac, Linux, Android, whatever. Qualcomm and MediaTek’s strategy is to make a bastard fork of the Linux kernel and, maybe, upstream some stuff later, with a particular interest in Android compatibility. I think it goes without saying, that the implementation which isn’t tied to a specific kernel, is a more desirable starting point.
Which coincidentally, the most important thing to Sony and Microsoft with regards to consoles ("make tons and sell tons" products) is cost of materials. Even getting that cost 1 cent cheaper still means a $1 difference over 100 units, $10 over 1,000 units, $100 over 10,000 units, and onwards. Remember, we're talking many millions of basically identical units sold.
AMD couldn't compete in performance nor efficiency, but they could absolutely compete in price, while both Intel and Nvidia couldn't due either to their business strategy or the logistics for Sony/Microsoft of procuring more materials from different suppliers.
So long as AMD can continue to undercut Intel, Nvidia, and any other contenders they will continue to dominate consoles.
1 cent cheaper would net Sony a total of 500K USD for all PS5 units sold till date. So about a hundred PS5 units at retail as pure profit. A company of the size of Sony for a product of the scale of PS5 would absolutely forego that profit if the alternative offered any tangible benefits at all.
That's the thing though: A new generation console only needs to be better than it's predecessor. It doesn't have to have groundbreaking technologies or innovations, let alone be a pioneer paving the way forward for other computing hardware products.
So cost of materials remains the chief concern.