476
Valve still waiting on a 'generational leap' for Steam Deck 2 - but it's coming
(www.gamingonlinux.com)
this post was submitted on 15 Oct 2024
476 points (98.4% liked)
Steam Deck
14797 readers
61 users here now
A place to discuss and support all things Steam Deck.
Replacement for r/steamdeck_linux.
As Lemmy doesn't have flairs yet, you can use these prefixes to indicate what type of post you have made, eg:
[Flair] My post title
The following is a list of suggested flairs:
[Discussion] - General discussion.
[Help] - A request for help or support.
[News] - News about the deck.
[PSA] - Sharing important information.
[Game] - News / info about a game on the deck.
[Update] - An update to a previous post.
[Meta] - Discussion about this community.
Some more Steam Deck specific flairs:
[Boot Screen] - Custom boot screens/videos.
[Selling] - If you are selling your deck.
These are not enforced, but they are encouraged.
Rules:
- Follow the rules of Sopuli
- Posts must be related to the Steam Deck in an obvious way.
- No piracy, there are other communities for that.
- Discussion of emulators are allowed, but no discussion on how to illegally acquire ROMs.
- This is a place of civil discussion, no trolling.
- Have fun.
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You may not have been but I am. Valve is already working on ARM support.
It also didn't have the new Lunar Lake chips.
I think you need to take a step back and ask if ARM makes sense if you're translating x86 instructions 100% of the time. Unless you're hoping people will develop new games for ARM and you won't use your SD to play existing titles much, but that seems like a 180° shift to me.
I dunno, I think you may be underestimating ARM here. I've heard that the overhead from translating the machine code is a lot lower than you might think, because so much X86 code is optimized down to a RISC-like subset of the instruction set already. And if that overhead isn't too daunting in the common cases, the more robust power management on the ARM side of the chip market might be able to make up the difference in a handheld environment for most users. Obviously it's a huge amount of work to nail the software, and it would be on top of the work they were already doing on Linux, so I'm not saying it'll definitely be in the next iteration, but I could definitely imagine it happening eventually.
Just to add as we are discussing mainly ARM vs x86 now... that is just a small part of the whole device. Just look at the SD OLED vs LCD. They managed to have OLED screen that is significantly better than the LCD one while using less power on AVG which is a huge deal to battery life and it either allows you to compensate with more power to SOC to achieve better performance at the same battery life or take the saving and go with higher battery life... and that's just screen.
Then they optimized the PCB layout, PCB components, etc.... to get both better cooling and efficiency.
I think that what is currently holding them back is both the SOC available and the actual efficiency of given parts combined. Getting improvement in both areas at once will lead to a significant change but one or the other alone will not tip the scales towards significant upgrade.
I honestly don't know. No one does. Valve is working on it. We have no idea of the current state of their progress. Likely rudimentary. I was commenting purely on the efficiency.
Yes it did not have Lunar Lake to which I said "Regrading their newest chips, I have no clue as of right now." because we really don't have any significant testing done at low power for these chips for gaming to compare with SD.
You also said "not sure what you mean by Intel." I was telling you what I meant.
Significant? No but we have what I would consider sufficient testing done to say that there is a significant improvement in efficiency, on PAR with Apple and Qualcomm.