4 ms·
For reference , Fex is a translation framework for x86 to ARM much like Apple’s Rosetta2 and Microsoft’s Prism. Valve sponsor development as it’s also the way
by dagmx 8d ago
For reference , Fex is a translation framework for x86 to ARM much like Apple’s Rosetta2 and Microsoft’s Prism.
Valve sponsor development as it’s also the way the new Steam Frame supports x86 games. It’s also being used (as a fork) in Crossover Beta to replace the use of Rosetta2.
- MiroslavPokorny 8d agoWhy doesnt Stream require their binaries to be compiled to some bytecode and transpiled during the install ? THen they wouldnt require any emulator for any new compiles.
- matheusmoreira 8d agoExisting games will not be recompiled for the new bytecode target, and they want all of those games to work regardless.
- MiroslavPokorny 7d agoNo im simply suggesting that Steam take this approach and prepare for the future. One day todays latest x86 will be old and some new architecture will replace it.
- rwmj 8d agoI don't know, but assumed that Valve doesn't require studios to recompile their software or use any special tooling, it's basically just packaging of existing executables. This is also why they do Windows on Linux emulation.
- cassianoleal 8d ago> This is also why they do Windows on Linux emulation. They don't. They use WINE, which as the name says, Is Not an Emulator. :D (I'll let my pedantic self out now)
- mitxela 8d agodespite the funny backronym, Wine actually IS a WINdows Emulator. Someone apparently told them that it's only called an emulator if it's emulating a CPU architecture, but that's not true.
- cdmckay 8d agoI thought it was an implementation of the Win32 API as a compatibility layer. What is it emulating exactly?
- anthk 8d agoDoes Windows NT have a Windows 9x API emulator?
- pjmlp 8d agoWindows NT predates Windows 95 for two years. And yes it did had emulators for Windows 16, and DOS https://en.wikipedia.org/wiki/Virtual_DOS_machine https://en.wikipedia.org/wiki/Virtual_DOS_machine https://en.wikipedia.org/wiki/Windows_on_Windows https://en.wikipedia.org/wiki/Windows_on_Windows
- fredoralive 8d agoIf you squint a bit (well, a lot really), Win32S on 3.1 and Windows 95’s Win32 implementation are Windows NT emulators running on top of 16 bit Windows.
- mitxela 7d agoWindows NT doesn't emulated Windows, it is Windows. Wine is not Windows and emulates Windows.
- swiftcoder 8d ago> Why doesnt Stream require their binaries to be compiled to some bytecode and transpiled during the install ? They still have to support the entire back-catalog. It's not reasonable to expect thousands of existing games to port to ARM
- DanielHB 8d agoThis is what Android does with Dalvik/Android Runtime. Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time. With the compilation making use of the native instruction set supported for your device, so it can make use of newer arm instructions on newer devices while still supporting older devices. This is the major reason app installation is so slow in Android compared to iOS (which pre-compiles everything). But it also greatly improves app compatibility with older versions. There is no way Valve would be able to convince all the myriad of game engine developers to support a proprietary (or even open source) bytecode format even in the future. Best they could do is make it an opt-in. Android only pulled it off because Google provides the "engine" (Android SDK) for all apps made for the platform and it did from the start. And even so, most Androids games actually bypass this system entirely and just hand-compile to native binaries anyway. Because, again, the game engines don't want to support this bytecode format and google doesn't offer a C++ toolchain themselves that the engine developers could integrate with.
- cwillu 8d agoSeveral games in their library are actually just game updater/launcher binaries, which manage their associated game assets and binaries externally.
- SSLy 8d agobecause there's no gaming-oriented toolchain for it
- account42 8d agoBecause even with their effective monopoly they don't have the power to bully developers into doing whatever suits Valve. And it would be disastrous for the industry if they did.
- MiroslavPokorny 7d agoNot suggesting they FORCE developers, im simply suggesting that another option for distribution would be an advantage.
- ekianjo 8d agoa dominant position is not a monopoly
- account42 8d agoSure, it just quacks like one.
- raverbashing 8d agoThey do x86 bytecode is bytecode
- DonHopkins 8d agothat bites
- ErroneousBosh 8d agoI mean don't modern CPUs basically just run an x86_64 emulator on a RISC machine anyway? Like there's a layer between the microcode and the actual x86 instructions already.
- raverbashing 8d agoI think it's more like a (kinda) VLIW machine but yes, pretty much
- MiroslavPokorny 7d agoVLIW implies packets of different independent instructions that can be executed in parallel. I dont think this definition is ever true for the vast majority of x86 instructions.
- sph 8d agoYes, but the “architecture-independent” bytecode for these RISC machines that run underneath your various Intel and AMD CPU models is the x86_64 instruction set.
- adwn 8d agoNo, that's a myth. It's true that the instruction decoder in a CPU core translates from ISA opcodes to micro-ops for the backend, but those micro-ops are in many cases functionally very close to the ISA instruction and decidedly not RISC-like. For example, the ADD r/m64, imm32 instruction (read from memory, add constant, write to memory) is translated to a single micro-op on several Zen architectures [1], which is far from anything you could call "RISC". [1] https://uops.info/html-instr/ADD_M64_I32.html https://uops.info/html-instr/ADD_M64_I32.html
- ErroneousBosh 8d agoI hate that you're being downvoted for asking a perfectly reasonable question. Guys, if you don't like the premise of the question, reply and say why, don't downvote. I think it's a good question, and my guess for the answer is this - which is going to be the easier problem to solve? "Hi guys if you want to publish on Steam you have to use this specific tooling and language that'll compile to native code on first run" and everyone just has to do it or "Hi guys we want to be able to publish everything so it runs on Arch Linux that we run on our Steamdeck, even if only Windows binaries are available, so given that Gaben is a billionaire what we'll do is just pay guys to make Wine not suck" You choose.
- 4thguy 8d agoThat will open a can of worms. For one thing, Valve will be accused of trying to create a walled garden. Plus there's the whole problem of supporting the back-catalogue as others have said. --- Maybe the best that they could to is to offer to distribute recompiled versions of the emulated binaries, similar to how they distribute compiled shaders. But I don't know if that would work, especially legally.
- wat10000 8d agoThat dream of write-once-run-anywhere has been attempted for decades and is still a massive struggle. And Steam isn’t in a position to mandate that kind of massive change. They’re big, but they still have competition from other stores and from direct sales.
- MiroslavPokorny 7d agoMost of those write-once-run-anywhere platforms struggle on the UI simply because host o/s are the same but often quite different in L&F. On the CPU level, ignoring native WORA guis, java and dotnet are very successful WORA platforms.
- gwbas1c 8d agoA few reasons: Bytecode can't really abstract the differences in memory model between the two different processors without some kind of consequence. (IE, it would be slower.) I've personally done some high performance multithreaded programming in C# / .Net, but it only "works" because C# / .Net assumes the TSO memory model. (Described in TFA.) In contrast, games need to squeak every cycle of performance out of their chips, and optimizations can be very CPU specific. When games target bytecode, they either won't be able to take full advantage of the hardware, or otherwise will need a lot of platform-specific fallbacks (that negate the point of bytecode anyway.) (This is why I prefer console gaming or "simple" games that don't tax the hardware.)
- MiroslavPokorny 7d agoI appreciate there will parts of a game that have hand rolled assembly, but even those have problems when x86 move forward. In the near future SIMD instructions will double their widths and todays fast code using them will be old. C# solves this problem by providing rich libs, so Microsoft continues to evolve faster functions, without programmers having to the all do the same work again and again.
- well_ackshually 8d agoBecause nobody would publish through them anymore. Because Valve has zero legitimacy to mandate that anyone changes their software for any reason. Because this is such an apple-brained, anti developer, anti user move that noone else in the industry does it. Because Valve mandating that for their own gain would bring in such a gigantic gatekeeper lawsuit. Because you profiled your code, optimized, then you'd then rely on Valve's "transpiler" to not write back absolute dogshit code back to the users. Because if it doesn't work well, people are going to blame the video game developer and never Valve. The list is extremely long, and the only people it would benefit is Valve.
- MiroslavPokorny 7d agoWhat makes you think that i suggested that a neutral bytecode should be the ONLY option ?
- pkasting 8d agoDisclaimer: I work for Valve, but I had nothing to do with Fex or anything related. There are a lot of other replies here, but one additional consideration is which solution is generally beneficial outside the original problem domain. A Steam-specific bytecode is applicable to games on Steam, whereas x86 emulation on ARM is of general interest to many problem domains today. Working on the latter could be viewed altruistically (it benefits the larger community) or self-interestedly (other developers are more likely to do work for us), but either way, it's an argument for the generalist path.