this post was submitted on 10 Nov 2023
265 points (98.2% liked)
Gaming
19983 readers
62 users here now
Sub for any gaming related content!
Rules:
- 1: No spam or advertising. This basically means no linking to your own content on blogs, YouTube, Twitch, etc.
- 2: No bigotry or gatekeeping. This should be obvious, but neither of those things will be tolerated. This goes for linked content too; if the site has some heavy "anti-woke" energy, you probably shouldn't be posting it here.
- 3: No untagged game spoilers. If the game was recently released or not released at all yet, use the Spoiler tag (the little ⚠️ button) in the body text, and avoid typing spoilers in the title. It should also be avoided to openly talk about major story spoilers, even in old games.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Imagine Valve going the Apple route: "Fuck it, we will design our own hardware to suit our needs" and making hardware tailored to linux.
Edit: what about qualcomm's new ARM: Snapdragon X Elite?
I think ARM is their end goal, it's really the only option for a handheld console, as today ARM is the only way you'll get enough performance/power rate to make it both good on battery with good enough performance.
Win-win for everyone if they invest in an open source x86 to ARM project, similar like they did with Wine.
The Switch is more than proof enough that pretty much any modern game engine can compile to an ARM target with zero issues (though Nvidia's low level APIs help, not sure about Qualcomm).
But there's zero chance older PC games would ever be updated, and by older I don't mean ancient, some AAA studios stop issuing updates in about one year after release.
So it all comes down to being able to emulate X86 on ARM... The best example we have is Apple, and games run but with a massive performance hit. Microsoft's implementation is borderline unusable. I'm not sure what to expect from Valve.
Checkout Box86/64 and Fex-Emu. They both do x86 translation/emulation on ARM Linux and the results are wayy better than any reasonable expectations I had going in.
A lot of that comes down to Unreal and Unity. They have targets built in for everything. Even a web browser if you want.
I wouldn't say you get that much of a performance hit with Apple games when emulating X86. Rosetta works pretty great for games that are already on macOS but as X86 games. The problem is emulating for Windows games that are also on X86.
It really depends on the game. If the game was truly native, usually the Rosetta performance is good. A lot of games though are JIT, and running a JIT inside a JIT is terrible for performance. The good news is that a game already being JIT is probably easier to patch to be native, for example people have had success replacing the mono runtime used by terraria with a native one and seeing good performance improvements, or running Minecraft on a native JVM. The bad news is it doesn’t necessarily mean the developers will actually update the thing, and mods like this are unlikely to appeal to the vast majority of people.
Every year they are more likely to go RISC-V.
AMD is getting there by optimizing the shit out of memory access and cache. RISC designs by nature have far simpler memory models. AMD has to throw tons of resources into making the x86 pig stay in the air, and they're already flirting with a move towards ARM.
Most of the people who know how to keep that pig flying already work at AMD or Intel. They certainly don't work at VIA Technologies (the third x86 company that nobody talks about, for a good reason). In contrast, any given Fortune 500 could probably hire an ARM team to make a custom chip for their needs provided they had a good enough reason.
What I'm getting at is there are factors that affect the broader market. Having more people and companies able to work on processors means greater possibility of variation, and therefore has an evolutionary advantage.
There are three x86 companies, and there's not likely to be any others. VIA is barely worth talking about. AMD is currently killing it, but it wasn't always that way. Over a decade ago, a combination of bad decisions at AMD, good decisions at Intel, and underhanded tactics at Intel made AMD nearly collapse. Intel looked smug on its throne, and sat on the same fundamental architecture and manufacturing node for a long time.
This was a bad situation for the entire computer industry. We were very close to Intel being all that mattered, and that would have meant severe stagnation. ARM (and RISC-V) being more viable helps keep that from happening again.
Much of what people do on computers these days is through a web browser. An even bigger market is servers, which often run Linux and can port things into ARM with less hassle.
People put far too much weight on games.
Not sure what point you trying to make. Translation is just one of ways to emulate.
This... Is not exactly how it works.
The way windows ABI works is syscalls always should go through dynamic libraries first, while on linux syscalls do syscall instruction/*. How windows syscalls work allows project like WINE just implement those libraries that will do linux syscalls. No instructions translated.
But with other architectures story is different. You either make instruction decoder for processor, make interpreter or make binary translator. First is itanium-way, second is naive way and third is how everyone does. Third is basically compiling one machine code to another. It has overhead of, well, compiling one machine code to another. And it works badly with other JIT compilers.
*there is vDSO, which is dynamic library, that implements syscalls like getting time. It is totally optional.
One thing you can do is translate 3d APIs. This sometimes makes 3d consoles easier to emulate than 2d consoles. PS1 emulation was basically solved when SNES emulation was playable but still had noticeable bugs.
They already did it.
They didn't. They asked AMD to do it.
You don't really "tailor" hardware to Linux. You release a driver without a dumb binary blob requirement, or at least document your hardware enough for a kernel hacker to pick it up.
What you mean "you don't tailor it to linux". Sure you can. You can optimize hardware to take over certain tasks. There are entire chips out there made explicitly for certain workloads like encryption, neural networks, RAID, encoding, decoding, mining crypto, what have you. Do you really think there's absolutely nothing in the linux kernel that couldn't be optimized away into hardware?
Won't ever happen, Apple is a hardware and device company that also makes software to go with it; Valve is a software company that also makes hardware to go with it.
And to go arm would mean throwing out the majority of their current store. Plus arm gaming performance is trash, apples chips struggle to run games 10 years old at 1080p 60fps.
Apple made its own chips with the Woz and then became a software company with that dude who got cancer. Only with the M1 did they design their own hardware again. Or am I getting this wrong?
What's to stop Valve from owning the vertical?
That really depends on the game studio support or how good the translation is. Wine games sometimes have better performance than when running on Windows (how they do that magic is beyond me), but adding another layer to translate from x86 to ARM isn't insane. Even Apple wants to do it and they hate compatibility.
Apple is trash - that we can agree on, but does the chipset really hinder an APU from getting a better GPU? Nvidia is going to enter the ARM space and if they have an inbuilt GPU to make it an APU, then it might blow the Apple chips out of the water in terms of gaming.
Anyway, all I'm saying is I'd welcome "Made for Linux" hardware.
Aren't the AMD in Deck 1 using x86 architecture? It would be impossible to change to ARM now. That would mean starting at square 1 and redesigning everything. And games compatibility would be thrown out the window.
Computer is like AC. It becomes useless the second you open Windows.
Developers already did half of work for porting on ARM: they ported on Linux.
The whole point of the Steam Deck for me is playing my older games. Unless they get x86 translation working without a performance hit them I'd rather they stay on x86.
Does a performance hit matter for older games (I'm assuming they're already 60+ if not a multiple)
It’s going to depend. If it’s a really old game it’s unlikely to matter. Anything heavy on CPU and particularly single core performance may struggle through a translation layer. A good translation layer on a good chip will probably lead to roughly similar performance in many cases, and most games seem to be GPU limited, so it’s possible it will just work out most of the time. It could always be the case that a critical section of the code somewhere ends up not translating well, leading to poor performance. It would not be terribly surprising for an important loop to end up two or four times slower than it should be, which could cause hiccups.
If the Deck can gain critical mass, they'll be able force the issue. They're already doing it with targeting Linux. The Switch is ARM, and the Switch2 leaks suggest it'll be a better ARM chip, so devs are already targeting it.
Unreal/Unity already go to ARM pretty easily, so it's not a huge deal.
I don't see the Deck as a critical mass device, and if Valve choses to make it one I will probably no longer be interested. The Deck is great because you can tinker to your heart's content in an open system. That just isn't going to fly if Valve decides they want to be the next Xbox or Switch.
Everyone is losing their shirt over ARM because Apple is producing some insanely expensive chips on it that have high performance. I'm not saying ARM doesn't have some advantages, but I think that's a long way out from going into something like the Deck where compatibility is everything. The switch being ARM has nothing at all to do with this conversation.