t’s certainly been a journey for Valve. A week prior to the Steam Frame’s launch, we spoke with two engineers at Valve about the project: Joy Lyons, hardware engineer, and Jeremy Selan, software engineer. The memory crisis and the price were a big part of that conversation. From that chat, we can confirm that Valve had aimed for a lower price point than the one it’s launching the Frame for today.
Here’s Lyons on the memory crisis:
“We set out to design this hardware with one particular price in mind, but we’ve made choices to make sure that we’re making a product that is choiceful, that people can purchase, they can upgrade with different features later. But we wanted to make sure we had a base product with really great performance. Then that price target shifted due to the ongoing RAM crisis around the world.”
Lyons also said that forecasting for the cost of certain components used in the Steam Frame is an ongoing challenge.
Not exactly boding well of the Steam Deck 2.
Chance is higher that Steam DECK 2 will be ARM/Snapdragon. So far nobody seems to capitalize on the fact that x64 ran out of patent protection this year.
Maybe we’ll finally see some more competitors appear in that space and drive competition
Even if the base AMD64 instruction set is out of patent, there’s been a steady trickle of ISA extensions over the years, and enough software expects some of them to be present that it would really hamper the usefulness of a third-party implementation if it didn’t have them.
True but emulating specific extensions is less costly than emulating everything through FEX. Basically a slimmed down version of what Transmeta tried all those years ago. Especially Nvidia would be big enough to also come up with their own extensions.
Not saying that this will happen, just that there are feasible ways for competitors
If you’re going to emulate them, it has to be at the software level instead of part of the CPU (otherwise you’d effectively just have implemented the instruction, but stupidly, and still fall foul of any intellectual property issues), so you need to run custom code when an unimplemented instruction is decoded (that’s easy - you can just trap on an invalid opcode), but also need to tell software that might try to use them that you support those extensions (plenty of software checks the CPUID on startup and just errors out if required extensions aren’t reported). That’s harder to do. You could:
I’m old enough to remember Transmeta processors. I know what they did.
And it was functionally the second bullet point, with all instructions being emulated, so the emulation software was what the CPU really ran. You can do emulation of a CPU on a compatible CPU, but it doesn’t generally end up faster than doing it on an unrelated CPU. E.g. the code you’re emulating will use all the registers the CPU has, so you have to maintain a mapping from emulated registers to real registers (and because you need some registers for the emulator, some emulated registers necessarily must spill to memory), and the code you’re emulating could use any part of the address space, so you’ve got to map from the emulated address space to the real one. Every instruction potentially needs some alteration, so you can’t just run them as-is. There can be time savings, e.g. x86 has all aligned writes under 64-bits be atomic, so on unmodifed Arm, you need to insert extra locks, and if x87 instructions are used, they don’t quite conform to IEEE754, so would need doing via many integer instructions instead of a single float instruction on non-x86 platforms, but there can also be time savings from using a different architecture, e.g. Transmeta’s CPUs had way more registers than x86, so could give all emulated registers a real register and still have enough for the emulator itself to use.
The rumors seem to say it will be another AMD chip.
At the moment, there is no ARM SoC that is as efficient at idle as Intel’s Panther Lake, so I dont know why Valve would tie themselves down with Qualcomm and have bad Linux support and shitty BIOS.
It’s hard to look at the new Intel Panther Lake processors and see that the advantages of ARM outweigh the disadvantages. Look at the new Intel handhelds, they just operate on a whole new level of efficiency.
I have yet to be aware of any Intel Arc G3 handheld that manages to come down to the 540g in weight of a Switch 2 console. The Acer Atlas 7 has a smaller screen and yet weighs a bit under 700g, so 150g more while it has a smaller screen.
No but they’re also far more powerful than a Switch.
You claimed that the Intels are more EFFICIENT than ARM processors, so the devices need to be lighter and faster but so far I’m not aware of any x86 handheld that manages that.
I’d totally be in favor of that happening. Device Tree is a clusterfuck and as long as the cast majority of consumer ARM devices don’t support the SystemReady specification, x86 is more flexible but that’s not the point you were arguing.
Processor start-ups need to make their own x64 processors now that the patents are no longer valid.
That’s not correct. For one, I did not say they were more efficient. For another they can be similarly efficient and also larger and heavier, because they’re more powerful.
“Look at the new Intel handhelds, they just operate on a whole new level of efficiency.”
So the “whole new level of efficiency” isn’t better efficiency, it’s worse efficiency and the need for bigger batteries. Got it!
You are misunderstanding me because you’re not paying attention to your own words . “A new level of efficiency” is not the same as “more efficient than ARM processors”. It really just seems like you’re just more interested in “being right” and being a dick in general than any sort of good faith discussion so I’m gonna cut my losses and block you. Goodbye.