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.

  • woelkchen@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    2 hours ago

    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

    • AnyOldName3@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      36 minutes ago

      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.