this post was submitted on 16 Oct 2024

119 points (99.2% liked)

PC Gaming

8607 readers

1080 users here now

For PC gaming news and discussion. PCGamingWiki

Rules:

Be Respectful.
No Spam or Porn.
No Advertising.
No Memes.
No Tech Support.
No questions about buying/building computers.
No game suggestions, friend requests, surveys, or begging.
No Let's Plays, streams, highlight reels/montages, random videos or shorts.
No off-topic posts/comments, within reason.
Use the original source, no clickbait titles, no duplicates. (Submissions should be from the original source if possible, unless from paywalled or non-english sources. If the title is clickbait or lacks context you may lightly edit the title.)

founded 1 year ago

MODERATORS

EXiLExJD@lemmy.ca

UncleBadTouch@lemmy.ca

KairuByte@lemmy.dbzer0.com

119

Valve still waiting on a 'generational leap' for Steam Deck 2 - but it's coming (www.gamingonlinux.com)

submitted 1 month ago by alessandro@lemmy.ca to c/pcgaming@lemmy.ca

30 comments fedilink hide all child comments

top 30 comments

sorted by: hot top controversial new old

[–] Linktank@lemmy.today 58 points 1 month ago (1 children)

DON'T RUSH IT.

Fuck's sake.

The current deck is more than enough to handle most games today. There is no reason to rush the next one out. Let the technology simmer for a while, reduce a little. Turn into a fantastic lightweight little belt buckle that connects to a pair of AR glasses and tracks my hand movements so I can play without holding a controller or mouse/keyboard anywhere I want.

[–] Vilian@lemmy.ca 16 points 1 month ago (4 children)

Asking for a handheld the performance necessary to run a VR headset is too much

[–] Blue_Morpho@lemmy.world 17 points 1 month ago

Quest is doing it with less power than a current Steam Deck.

[–] Thatuserguy@lemmy.world 5 points 1 month ago

I ran Alyx with a WMR headset and a mobile 1060. It wasn't fantastic but it ran well enough that the experience wasn't diminished. A next gen Deck could easily handle it

[–] Linktank@lemmy.today 5 points 1 month ago

You're incorrect, and that's okay. We're talking about some future date where technology that doesn't exist today is available. We can ask for anything we want.

[–] taanegl@beehaw.org 4 points 1 month ago

Maybe, depending upon how it is implemented.

If they somehow use those AMD NPU's as accelerators to handle spatial recognition, then it might be possible to at least add some of the needed functionality behind AR/VR without pounding the APU.

Or, considering it might be ARM, it might be an in-house or even AMD designed SoC with all the necessary bells and whistles to implement at the very least AR.

I'd buy the heck out of an AMD ARM device.

[–] Donjuanme@lemmy.world 38 points 1 month ago

Even the different problems between the LCD and OLED models make me content for valve to take it slow.

Don't diminish the support with multiple sku's, work on fixing the small but persistent problems with the current operating system, let other companies keep the hardware manufacturers pushing forward, continue making sure the operating system works well on the more modern hardware, and release a single product when the time is right.

There should be no decimal after the deck 2, keep the product focused, don't divide your labor and multiply your potential bugs.

Also please have your operating system developers try using the deck interface for things besides gaming, trading, forum posting and even browsing the store is hampered by easily replicable bugs.

[–] callouscomic@lemm.ee 11 points 1 month ago

[–] TropicalDingdong@lemmy.world 5 points 1 month ago* (last edited 1 month ago) (5 children)

Its gonna be ARM based. Just no other way to get the power to performance. Maybe some of the AMD architectures. Also, expect soldered RAM.

[–] Dudewitbow@lemmy.zip 26 points 1 month ago* (last edited 1 month ago) (1 children)

people overexagerate the power efficiency of arm because of controlled environments. for gaming handheld workloads x86 is more than enough.

Snapdragon on windows has already shown(ignoring games that outright dont work) then when under a gaming load, the efficiency gains arent there.

Another example that its not a magic bullet in terms of strictly hardware is the M1 in non OSX environments. If you look at the M1's efficiency while using Asahi Linux (a distro of linux specifically tailored to apple m series cpus), it does not remotely get the same kind of battery life as it does in OSX. Its why for example, the steam decks battery lofe reletive to size is better than windows handhelds.the bottleneck wasnt the hardware but more the OS

what valve really wants is if they could get a handheld with only AMD C cores (that is power efficient cores with less cache but like 70% of the size of a full core) such that the power budget would go to the iGPU more than the CPU, as a majority of games are gpu limited in performance rather than CPU. AMD just has never made a C core only consumer part (only servers have gotten them).

[–] TropicalDingdong@lemmy.world 4 points 1 month ago (1 children)

Wouldn't that be the point of focusing on the interoperability layers and recent investment in Arch?

it does not remotely get the same kind of battery life as it does in OSX

Yeah exactly. So you need to invest into finding the fixes to that. Which is what Valve appears to be doing? It might be a fishing expedition or just a virtue signal to the foss world, sure. But they did do the thing.

And yes on AMD. I did leave that window for myself to crawl out through. I think if the trip down ARM on Arch ends up being a fishing expedition, they flip over to a known quantity for a refresh.

[–] Dudewitbow@lemmy.zip 2 points 1 month ago

their investments is into a later for x64 to arm cpu translations, but still does not settle the problem that the gpus on arm based systems still have soo little development into games, which would then limit your options to amd, intel and nvidia based arm designs if you wanted an SOC with existing GPU support already in the environment. the moment you choose to have a tiled approach of mixing cpu and gpu from companies, you sort of instantly throw away the efficiency gains from switching to arm in the first place.

AMD and intel basically havent pushed out an atm based device yet, and Nvidia notoriously hates doing semi custom designs for clients.

personally i think youre far more likely to see the arm compatibility layer for basic pcvr games on a theoretical index 2 before a steam deck uses arm.

[–] nous@programming.dev 13 points 1 month ago (1 children)

I wouldn't sound so sure. There are a lot of blockers to getting a working ARM based steam deck. First Arch Linux (which steam os is based on) does not offer official ARM binaries. This would mean they would need a new base os or work on getting Arch Linux to support ARM. With their recent donations to Arch Linux were focused on unblocking some issues with supporting Arch on ARM (notibally stuff needed for better automated builds) would suggest they want to stick with Arch.

Next you need good emulation layers for x64 and x86 as that is what all games are written in. Which there are leaks that say they are working on this as well.

But that is two big blockers that could take years to solve. So all comes down to when they want to release the next deck. Within a couple of years and I don't think it will be arm based. After that the chances go up quite a bit.

[–] TropicalDingdong@lemmy.world 4 points 1 month ago (1 children)

With their recent donations to Arch Linux were focused on unblocking some issues with supporting Arch on ARM (notibally stuff needed for better automated builds) would suggest they want to stick with Arch.

Next you need good emulation layers for x64 and x86 as that is what all games are written in. Which there are leaks that say they are working on this as well.

Thats two legs of support for an ARM architecture.

But that is two big blockers that could take years to solve.

Sure. But what you are describing is "uncertainty". Uncertainty in isolation isn't a form of evidence. It could take years. It could not. Its not just Valve looking to solve this issue. MS has committed to ARM based interoperability; so has Apple. MS and Apple obviously want things to work seamlessly between ARM and x64, x86. The heat/ power to performance gains are just too much to leave on the table and both of those Software/ Hardware manufacturers saw this coming. If this was a project coming out of Valve & Arch doing the work; sure, I'd give it a time line of a couple to several years. But Valve while coming in with backing and there are other players looking to overcome and address the same problem. With teams like MS and Apple also working on it, I expect this to be figured out on a faster timeline. Months/ few years.

Within a couple of years and I don’t think it will be arm based.

Sure. If thats your bet thats your bet. My bet is solidly on ARM. Its what the evidence we have points at, even if there isn't a ton of certainty around it.

[–] nous@programming.dev 4 points 1 month ago

With teams like MS and Apple also working on it, I expect this to be figured out on a faster timeline. Months/ few years.

That assumes they will share a meaningful amount of work. I do not see what Apple have done to help much at all - completely closed ecosystem with their own custom chips that they are not going to want to share.

MS have done a really bad job as well at getting ARM to kick off and have not been putting a huge effort into it that I have seen. And especially since valve is doing this in part to get away from MS systems why would MS help valve with this goal?

So yeah, if they did put in and share the effort it would take less time. But I don't see them doing that. Plus, it takes years to develop a product like this. And all evidence ATM suggests they have barely if at all started on the next version. Which does suggest that the next deck is likely more than a year away, likely two. Which does increase the chances that it could be arm based.

[–] BlackLaZoR@fedia.io 7 points 1 month ago (2 children)

Its gonna be ARM based

Doubtful. Emulation of x86 code is just too slow. I'd rather expect hybrid SoC, with both ARM cores and x86. System and dedicated games can run natively on ARM, while legacy software may utilize x86

[–] TropicalDingdong@lemmy.world 6 points 1 month ago (1 children)

This seems like it would put the price far out of reach.

[–] BlackLaZoR@fedia.io 4 points 1 month ago (1 children)

I don't know - you'd need at least 4 arm cores, and 4 x86. Current deck uses just 4 x86, so squeezing in more would require waiting for some fabrication improvement to keep power draw and cost sane

[–] TropicalDingdong@lemmy.world 2 points 1 month ago (1 children)

That just seems like at least double the cost.

[–] BlackLaZoR@fedia.io 3 points 1 month ago

Not necessarily. Steam Deck SoC is CPU+GPU out of which latter is probably the bigger part. Also, on the chip there are all the memory, USB, Pcie, audio and other controllers.

Adding 4 arm cores definetly wouldn't double the chip size

[–] hperrin@lemmy.world 4 points 1 month ago (1 children)

That sounds like a nightmare to code for.

[–] Vilian@lemmy.ca 2 points 1 month ago (1 children)

That the kernel developers to decide, the deve wouldn't need to change angthingz but i doubt the idea too, how can sincronize the arm and x86? How to you handle libraries of the different architectures

[–] hperrin@lemmy.world 3 points 1 month ago* (last edited 1 month ago) (1 children)

The libraries would probably be easy. We’ve already got x86 and amd64 libraries on the same machine, but the kernel I imagine would be awful. Would two kernels have to run on the same machine? What about memory access? What about the scheduler? Would it really be more efficient than emulation? For every x86 instruction, there is either an equivalent instruction or an equivalent set of instructions for ARM.

[–] BlackLaZoR@fedia.io 2 points 1 month ago (1 children)

I imagine would be awful. Would two kernels have to run on the same machine?

Correct me if I'm wrong, but afaik, applications talk through APIs. It shouldn't matter if app runs x86 and kernel is ARM

[–] hperrin@lemmy.world 2 points 1 month ago

But the code that loads other code (launches an app, switches to it, etc) needs to be running on the same CPU, afaik.

[–] Die4Ever@programming.dev 6 points 1 month ago* (last edited 1 month ago) (1 children)

I think Intel's Lunar Lake has shown otherwise, it's quite good.

And ARM performance per watt isn't going to be as good when you're doing x86/x64 emulation

[–] TropicalDingdong@lemmy.world 1 points 1 month ago (1 children)

Obviously anecdotal, but if the next Steam deck was Intel based, I wouldn't buy it.

[–] Die4Ever@programming.dev 3 points 1 month ago* (last edited 1 month ago)

I'm just citing Intel's Lunar Lake as an example. If Intel can do it then so can AMD, and eventually both companies will surpass that

[–] MentalEdge@sopuli.xyz 4 points 1 month ago* (last edited 1 month ago)

ARM isn't exactly efficient when used for performance-demanding things. It excels a low power efficiency, but as soon as you throw a persistent heavy process at it, it'll gulp down a battery all the same.

And x86 has been catching up on both sides. Standby times are only getting better.

[–] AnimalsDream 3 points 1 month ago

If the hardware can ever be shrunk enough to make even a semi-pocketable x86 handheld, I would be happy if Valve were ever to release a "Steam Deck Mini" or something.

Or maybe their new efforts with ARM support point toward a future of a much more portable Steam-on-Linux-on-ARM device.