I think it’s well in valves wheelhouse after proton to do something similar and revolutionise x86 to ARM translation. But at the moment better chips still need to arrive for that too be good enough for a product to built around. Which is why it’s the first thing i think of when they say they need technology to advance more before they make a new steam deck.
x86 to ARM translation is a fairly different problem than what proton solves, so I don’t think it’s clearly in their wheelhouse. Proton / wine is mostly just an implementation of windows libraries on Linux, but doing efficient x86 emulation on arm is a compiler problem. I would guess that Valve could do it or at least hire people to do it, but it’s a bit of a different skill set. Doing x86 efficiently on ARM (particularly with concurrency) also likely involves some extensions to ARM like Apple does with their chips. I haven’t heard if the snapdragon elite chips have anything for x86 compatibility baked in at all. Frankly, I’m treating the snapdragon elite with a fair degree of scepticism until you can actually buy the thing, but I hope it’s good!
I don’t think they’re waiting for ARM specifically. If that ends up working out, sure, but if they can get x86 with the right power to performance ratio I doubt they would complain.
Architecture emulation for current gen games is exceptionally unlikely right now. At a fundamental level, wine/proton doesn’t change the instructions the code describes, rather it translates the input and output. It’s a reimplementation of the same instructions in Windows. For architecture crossing you’d either have to create virtual hardware, which adds tremendous overhead, or recompile the binary. Recompilation is theoretically possible, but for x86_64 to ARM64, for games no less, it’s beyond the realm of mortals. It’s like how some jokes can’t be translated between languages; the structure and vocabulary is just too different.
Microsoft and Apple have some form of x86 to Arm translation at the moment. Also I know it’s not something that’s really done now. I’m not arguing it can be done right this second cause valve are talking about that there’s something they want to do but can’t yet and need technology to get a bit better before they move on with their plan. I’m saying this feels like the most logical thing that they’re waiting for.
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.
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.
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.
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.
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.
Emulation is from one architecture to another, translation layers like wine just translate windows instructions to linux, see also: every WIP ps4 “emulator” is just a translation layer, and doesn’t have the over head that it would if it was your traditional emulator
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.
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.
Bruh just check, whenever Apple makes massive performance gains it’s on a new TSMC node.
I’m not gonna bullshit you and say AMD and Intel do nothing, sure they got some amazing tricks. But in the end it’s mostly TSMC making everyone’s chips faster and more power efficient.
New Nvidia GPU’s magically got power efficient. Why? Check the node of the 3000 series and the 4000. AMD is currently way less power efficient in GPU. Why? They’re not on the latest node like Nvidia.
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.
While partially true, the biggest problem is software compatibility. Most software is compiled and optimized for X86 and it won’t run on ARM unless recompiled.
How are we going to get everyone to jump ship? Apple had their magic emulation sauce but windows doesn’t seem to have that and especially not for Risc5
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.
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?
And to go arm would mean throwing out the majority of their current store.
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.
Plus arm gaming performance is trash, apples chips struggle to run games 10 years old at 1080p 60fps.
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.
Back then, we really couldn’t engage with a display manufacturer to do exactly what we were after because they didn’t really understand the product category, or who would be buying the screen, or why it would matter. Now that picture has changed and we’re able to get custom work done.
Why would literally any of those questions be of concern to the screen manufacturer? And I don’t understand, did Valve begin work on this in 1918? How could anyone not understand the product category?
Display manufacturers may understand what Valve might want in a screen, but they might not understand how many units of a screen of such a specification they would be able to sell — is it going to be a custom job for just a few thousand of valve’s experimental console (which may have different degrees of success), or is it going to be something that they can sell to more people and a wider audience.
Konami really on their way to actively ruin more Silent Hill projects? Konami’s meddling in the development of the SH games after 2 is what turned Team Silent away from Konami, why do they think making another in-house studio that they control is going to be any different?
The only way I will ever begin to even attempt to trust Konami again is if they license the SH IP out to Kojima so he can Del Toro and the gang can finish Silent Hills.
Wow, shocked! If asa releases on Xbox it will be horrid. I quit after 30 hours of dealing with crashes and performance issues. That’s just single player, official servers crash every 1-2 hours and roll back, deleting tames and wiping your inventory.
Yet some still defend wildcard as if they don’t have nearly a decade of experience working on this game. It’s obvious upper management is the issue , but I’m not supporting this crap again.
So does this mean the game is finally ready for me to buy? Just waiting on a Steam sale and I’ll finally get to play this. Bugs or not, I’m not paying $70 for a base video game.
Yep, as someone who beat it several times, I agree with this. Its a great game, but is unpolished at launch like any bethesda game, 5 years from now it will have memorable gamer cultural references and a consistent modding/playerbase.
With the love of using the game engine to create entirely new games that bethesda fans have, I’m basically expecting a Star Wars/Star Trek total overhaul mod within the next decade.
Reletively speaking starfield is already a lot less buggy then other Bethesda game studio titles. Its just matter of fixing parts of the game some users didnt like.
I’d say probably not. Unless the graphics were the only thing holding you back, this update does not appear to have done anything to improve the gameplay loop, menu system, or story content.
Compared to previous Bethesda games, it actually ran rather well at launch even when missing the features added by this update. But I’d say there’s quite a lot more that needs to be done to call it a good game, with graphics/performance being the lowest priority on the list.
I doubt a patch nor mod support will motivate me to play this game. This is the most empty Bethesda game they've released when they could've had something special if they had any ambition.
eurogamer.net
Najstarsze