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.

you are viewing a single comment's thread
view the rest of the comments
[–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 32 points 1 month ago (13 children)

    I wouldnt be surprised if the Steam Frame 2 ran on x86.

    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.

  • source
  • parent
  • hideshow 13 child comments
  • [–] 1 point 1 month ago (4 children)

    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.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 2 points 1 month ago (3 children)

    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

  • source
  • parent
  • hideshow 3 child comments
  • [–] 1 point 1 month ago (2 children)

    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:

    • run all user software with a debugger attached, single-stepping it and intervening when the CPUID instruction appears. This would be really slow as you'd have to context switch to run some debugger code after every instruction.
    • run all user software on an emulated machine, in which case it doesn't matter what your real architecture is (although having a compatible memory model helps avoid loads of locks).
    • run all user software on a virtual machine, which requires virtualisation extensions, which came later than AMD64.
  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 1 month ago (1 child)

    I'm old enough to remember Transmeta processors. I know what they did.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 1 point 1 month ago

    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.

  • source
  • parent
  • [–] 1 point 1 month ago* (6 children)

    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.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 1 point 1 month ago (5 children)

    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.

  • source
  • parent
  • hideshow 5 child comments
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 1 point 1 month ago (3 children)

    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.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 0 points 1 month ago* (last edited 1 month ago) (2 children)

    You claimed that the Intels are more EFFICIENT than ARM processors, so the devices need to be lighter and faster

    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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 month ago (1 child)

    That’s not correct. For one, I did not say they were more efficient.

    "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!

  • source
  • parent
  • hideshow 1 child comment
  • [–] 0 points 1 month ago

    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.

  • source
  • parent
  • load more comments (1 reply)
  • load more comments (1 reply)
  • [–] 35 points 1 month ago (46 children)
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 41 points 1 month ago (5 children)

    Yes, I can. Manufacturers literally CAN NOT closed-source fork the kernel, because of its licensing. They HAVE to release the exact kernel sources used for the device.

    You can also run fully open Linux on your Pi5. There will be some firmware blobs, but then again so will any x86 board.

    Oh, and smartphones run ANDROID. Not just Linux, but a completely separate layer on top of it that is much different from the traditional desktop environments. Android isn't Linux, it runs on top of the Linux kernel. Sure manufacturers don't release their Android source, because they don't have to, but equating Android with Linux is idiotic.

    You seem to have a very... loose grasp as to what is considered open source and what "Linux" is.

    Here's a quick bootcamp: any fork of the Linux kernel is still Linux. Does the RasPi5 require a custom kernel? Yes. Does that make it any less open? No. Does that make it any less Linux? Also no.

    The kernel sources for Raspberry Pi boards are readily available. No request for access needed. You can clone the repo any time. That is open source.

    Samsung, Google, Motorola, Xiaomi, OnePlus, Nothing, etc. all either provide open repos for kernel sources, or provide them upon request (as per the GPLv2 license of the kernel). That's still open source. And just because each phone manufacturer - as well as each SoC manufacturer - had to make changes that aren't in mainline, doesn't make that any less open or any less Linux.

    In fact Google has been pioneering a way to get better kernel baseline support via GKIs, and manufacturer support for a lot of boards and SoCs have been introduced in the mainline kernel.

    But the thing is that ARM is progressing fast, with quite a few SoC/core manufacturers on the market (Qualcomm, Apple, Samsung, HiSilicon/Huawei, MediaTek, Amlogic, Allwinner, Broadcom, Rockchip, NXP, UNISOC, and so on), whereas X86 has two manufacturers who do end to end development in-house, and at a slower pace (usually one class of CPUs announced a year). The thing is, mainline WILL pay behind because ARM just progresses so fast that reviewing all the changes to add a new SoC to the supported list cannot happen overnight. That's why forks exist.

    But, I repeat, that fork makes it no less Linux nor any less open source.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 22 points 1 month ago (4 children)

    Manufacturers literally CAN NOT closed-source fork the kernel, because of its licensing. They HAVE to release the exact kernel sources used for the device.

    Legally aren't allowed to, may not care anyway. Chinese legal system doesn't enforce this.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 7 points 1 month ago (3 children)

    The big ones obey, because they have international presence. From what I've heard, the small ones will provide it on request, since chances are they have no financial reason not to anyway.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 7 points 1 month ago

    Yep.

    A decade or so ago it used to be that GPL source requests/demands were an uphill battle. You had to beg, threaten legal action, for months to get somewhere.

    Nowadays most manufacturers recognise that open sourcing actually helps them because people will create custom ROMs, or do the kernel upbring for newer versions the ODM refused to, so now with 0 work you have a new BSP and can push updates faster.

  • source
  • parent
  • load more comments (1 reply)
  • [–] 14 points 1 month ago (24 children)

    Can you run Linux on your cellphone, can you run Linux on the Raspberry Pi 5?

    Wtf? The vast majority of phones do run Linux, and most of the rest (iPhones) run UNIX. And since when is raspberry pi 5 not Linux?

  • source
  • parent
  • hideshow 24 child comments
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 8 points 1 month ago (12 children)

    I can absolutely build the Linux kernel for arm from source for the raspberry pi. Whether it is using the open source raspberry pi fork or mainline. I can put any of at least a dozen fully open distros on it. Etc.

    Maybe there's some devices/manufacturers doing this and that's what you're thinking of, but your core argument here is 100% wrong.

  • source
  • parent
  • hideshow 12 child comments
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 9 points 1 month ago* (last edited 1 month ago) (2 children)

    Also, Android is linux, lol. Just because some phone models don’t allow you the freedom to build-from-source doesn’t change any of that.

  • source
  • parent
  • hideshow 2 child comments
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 2 points 1 month ago

    Ahahahahahah! No, no no no. None of that is true. Nor has it ever been true

    😂😂😂😂😂😂😂😂

    Have you ever tried stand-up comedy? I think you might be quite good at it— in the Trump-idiot garbage bin circuit

  • source
  • parent
  • load more comments (1 reply)
  • [–] 4 points 1 month ago (7 children)

    I would probably me more inclined to listen to anything you say if you also acknowledged your mistakes

  • source
  • parent
  • hideshow 7 child comments
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 4 points 1 month ago (5 children)

    Ok but it's weird that you aren't acknowledging the things you were fundamentally wrong about, and were making a really big deal about

    Not sure how you can draw conclusions like that with big misunderstandings

  • source
  • parent
  • hideshow 5 child comments
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 2 points 1 month ago* (3 children)

    Rasbian is not a fork of "Linux". It is a distro that contains lots and lots and lots of open software. Including Linux. Just like Ubuntu and Alpine and Debian and Rocky and Neon and hundreds of other distros do.

    That distro is fully open .

    It includes an open, non-closed version of the Linux kernel.

    You can, and people absolutely do, use Linux from the Linux foundation, on tons of ARM hardware, including Raspberry Pis and other ARM-based general purpose computers

    Can I run desktop Ubuntu on my Motorola phone? No. But I can't run it on a Kankun smart plug either, and that runs Linux. Ubuntu wasn't designed to run on this hardware (though they did work a LOT on specific phone and tablet support). I also can't run it on a Milk-V Duo, but it is Risc-V and runs "Linux".

    Do many phone manufacturers do other things to lock down phones? Yes, but that has nothing to do with being ARM-based. And I was responding specifically to the ARM claims.

  • source
  • parent
  • hideshow 3 child comments
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 2 points 1 month ago (1 child)

    By that measure there are very very few Linux systems running Linux. Most distros ship their own slightly customized fork.

    All of the [ARM] hardware manufacturers make it difficult to use with mainline Linux

    No, they do not all do that

    And it has nothing to do with ARM vs x86 or Risc-V which was your original core point

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (1 reply)
  • load more comments (1 reply)
  • load more comments (1 reply)
  • load more comments (1 reply)
  • [–] 6 points 1 month ago (3 children)

    Darwin is UNIX. And anyone who knows what they’re talking about wouldn’t confuse the two.

    lol

  • source
  • parent
  • hideshow 3 child comments
  • [–] 0 points 1 month ago (2 children)

    the person I replied to mentioned Unix for some reason

  • source
  • parent
  • hideshow 2 child comments
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 8 points 1 month ago (4 children)

    They run android, it's not the same.

    Lots of distros “aren’t the same”, but android runs the Linux kernel at its core.

    Whether you like it or not, it’s Linux

  • source
  • parent
  • hideshow 4 child comments
  • load more comments (1 reply)
  • load more comments (2 replies)
  • [–] 6 points 1 month ago (5 children)
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 6 points 1 month ago (1 child)

    Yes, you do have to ask that question, dummy.

    Just look at every single newer generation x86 CPU. Until direct support is added in the kernel (which usually happens early on because Intel and AMD use a singular architecture for each generation so support is easy), shit's so broken it won't even boot.

    You don't need to download a closed source binary blob from the vendor

    Except, you know, the CPU microcode package, the GPU drivers, the WiFi, Bluetooth, etc. firmware (via the linux-firmware package), and the list goes on.

    Buddy, we've already established that your knowledge of Linux et al is surface level at best, why are you still digging your own grave with verificably incorrect/incomplete statements that literally move the goalposts of this debate every time you reply?

  • source
  • parent
  • hideshow 1 child comment
  • the goalposts were that x86 is more open source friendly than ARM. Intel and AND work on mainline Linux because they actually submit their patches to mainline and make sure that they get accepted. Sure, there's firmware, but the code to use that firmware is open source and widely used. The worst you see is maybe SoC drivers for webcams.

    Compare that to ARM, where the majority of vendors dont provide source code for their kernels, and when they do boot with mainline Linux, half the shit is broken because of device trees or undocumented peripherals.

    I wouldn't want to buy an ARM computer.

  • source
  • parent
  • load more comments (1 reply)
  • [–] 6 points 1 month ago (3 children)

    Can you run Linux on your cellphone, can you run Linux on the Raspberry Pi 5?

    Yes and yes. In fact, I currently do both of those.

  • source
  • parent
  • hideshow 3 child comments
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 8 points 1 month ago* (last edited 1 month ago) (1 child)

    Nothing. Also, why do you keep changing the requirements? First it was "you can't run Linux", then it became "you can't run a mainline kernel".

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (1 reply)
  • load more comments (1 reply)
  • [–] 13 points 1 month ago (7 children)

    ARM is arguably more closed source than x86. Most ARM computers violate the Linux GPL license and run a closed-source fork of Linux.

    Honey, you can even run Asahi Linux (fully FOSS) on Apple Silicon. WTF are you taking about?

  • source
  • parent
  • hideshow 7 child comments
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 10 points 1 month ago* (last edited 1 month ago) (1 child)

    First of all, ARM is not owned by Apple, and if it weren’t so open, so open source friendly, Apple would not have been able to create Apple Silicon chips in the first place.

    Secondly, lol, Asahi Linux proved that, not only could apple’s apple silicon chips be reversed engineered, but that it was both a worthwhile enterprise and that Apple wouldn’t come after them. Because Apple officially stated that they just do not care. Apple intentionally designed the chips to be capable of booting and running alternate operating systems. They, themselves, created a very clear and open development pathway.

    Oh, not to mention that it is definitely Linux.

    So… That’s what the fuck I’m talking about. Again, what the fuck are you talking about?

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (1 reply)
  • [–] a comment that isn't shown here: deleted, from someone you've blocked, or on another page. view the thread from it
  • [–] 6 points 1 month ago* (2 children)

    Literally, none of these things is true.

    If you spent as much time on research, as you apparently do one making shit up, you would know that.

  • source
  • parent
  • hideshow 2 child comments
  • load more comments (1 reply)
  • load more comments (2 replies)