In my experience everyone is just rebuilding the same wheel over and over.
A lot of people may be more empowered to create things now with less up front effort but it doesn’t lead to having better ideas or more actual system architects.
Yeah, Apple has spent 3 years each on the 5nm and 3nm nodes with TSMC. There are some reports [1] that it will jump to 1.4nm after 2 years due to AI but there's no real proof. The source is Digitimes who are frequently wrong with their predictions and rumors.
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.
It's more than thousands, and not only it's not reasonable, it's not possible.
Plenty of games run on some critical optimizations that exploit native code quirks that may or may not hold up only because Windows papers over them by special-casing the game process at OS level. The source of such games may be stuck in IP limbo, with five different studios/companies claiming ownership (three of them dead or bankrupt), and even then, the only person who knows what and how needs to be reimplemented is on a remote tropical island, working for a competitor / happily retired / stuck collecting trash for a living, depending on how their career went.
Takes only a few such cases to turn out to be some well-known games with substantial legacy fanbase hoping to relive some childhood memories, to risk seriously damaging the "supporting everything" marketing angle.
Emulating underlying runtime is safer and more practical choice.
This 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.
> Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time.
This is only true in Android 5 and 6.
Starting with Android 7, due to amount of time it took to compile in tiny ARM CPUs, limited optimisation levels, and Java's dynamic abilities, there was a full reboot of this process.
Which is an Assembly hand written interpreter, intended to allow for quick startup in case the JIT cache is empty, a JIT compiler, and an AOT compiler that only compiles the hot paths that the JIT already had a look into, and during idle times while charging so that it can have the CPU all for itself when doing optimisations.
Additionally several other measures were taken to optmise this process, via Play Store Services, devices can share PGO data gathered by the JIT so that each device doesn't have to start from scratch, thus the interpreter step can be skipped when metadata is available. To further improve this process, developers can do training runs, and ship the metadata themselves on the APKs.
Also during the compilation to native code, depending on code access patterns, the executable code gets remapped so that there is an optimal alignment for the instruction cache when reading from the executable code cache.
Google certainly offers clang as part of the NDK, and game development is one of the few officially supported scenarios to run native code on Android.
Your message seems to be arguing both points at the same time - at least that's how it reads to me; first, that it's absolutely feasible to do this because Android did, and then, that in reality game developers there casually defeated those efforts anyway.
"It's not reasonable to expect thousands of existing games to port to ARM"
Realistically it is possible and not actually that difficult. The hardest part would be ensuring that specific code changes from older x86 code to modern ARM code actually translate over properly and perform as expected. The majority of work done there would have to be in the libraries that were used to build the game. For way older games, like the ones you'd run under DOS, it would be much easier, as most stuff was in ASM and C (you did have the occasional BASIC game or PASCAL game flying around which would likely need a little bit of extra work) so you'd just be doing direct translation of instructions.
I 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.
despite 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.
If 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.
“Emulator” is a term of art in this area which refers to emulation of a hardware (and usually machine instruction) environment. Ironically, “translation” (as in instruction translation), as proposed by a sibling comment, is an even more connoted-with-hardware-emulation term.
WINE is … well, most directly it’s just an implementation of an API (the Windows APIs). In webdev parlance it might be called a “polyfill”. Perhaps a “compatibility shim”?
I think in common usage, people expect an "emulator" to be a more sandboxed translation layer than Wine, for example, provides.
e.g. it's probably a security vuln if loading a Game Boy ROM reads arbitrary paths on your local filesystem determined by the ROM's code, not so much with Wine.
Someone made a cute demonstration that I think usefully encapsulates this a while ago. [1]
Mostly because the Gameboy doesn't have any IO register to reformat your hard disk. If the emulator interpreted some instruction as reformatting your hard disk, that would be a bug because it's not interpreting it as whatever it actually does on a real Gameboy.
For me an emulator works to simulate the hardware which is very different from translating API calls. THe result may appear to be same, but the approach is very different.
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.)
I 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.
That 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.
Because 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.
That 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.
Disclaimer: 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.
I 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"
I 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.
No, 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".
No, they don't. x86 is a superscalar processor, and it does what all superscalar processors do--translate the instructions into µops for execution and dispatch to the various execution units, with the µops not being 1-1 with the original instructions. However, it was supposed to be impossible for a CISC architecture to be superscalar, so this is what spawns the myth that it's somehow cheating by executing a RISC architecture under the hood.
The fact that x86 is not RISC, it contains many instructions which support memory as the source and destination or both, something which is often an advantage in terms of code density, and speed.
Yes, 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.
VLIW 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.
> Tech communities like this skew more libertarian
Indeed, this is historically a forum with lots of "temporarily embarrassed billionaires".
My observation is the opposite of the GP - that labor identity and consciousness (not "liberalism") is rising here, pushed in no small part by the transformation in labor value that LLMs have caused.
Because it ruffles x86 feathers, despite geekbench corresponding very closely to SPEC as well and there being no indication that the results aren’t comparable.
What people willfully conflate this with often is that you shouldn’t compare FLOP numbers between GPU arches and instead rely on benchmarks.
Geekbench when run on Asahi Linux is practically the same as when run on macOS, just like Linux and Windows in the same x86 chip don’t give significant differences.
Processors, not just Apple’s, change constantly between generations. The core instruction set doesn’t change, but they get new capabilities, not just with new instruction sets.
Remember the SoC isn’t just the CPU. It’s display engines, GPUs, storage controllers, video decoders and more.
Even outside of Apple, you’ll see hardware vendors provide Linux patches for their latest CPUs to keep working well. There’s some baseline functionality that works out of the box but it’s never a free ride.
The simulator is a different SDK target than iOS itself.
You have to compile completely independently for it, and depending on your dependencies they may not compile for the simulator.
Additionally the simulator runs a really ancient and feature restricted version of Metal. That means you can’t test a lot of graphical things that the hardware actually supports. I’m not sure if this supports GPU passthrough but the macOS VMs do, so that alone would be a huge improvement if possible.
Sure, you can also have iOS binaries forward relevant iOS SDK symbols to macOS. That doesn’t mean they’re not different SDKs with different limitations, and not everything that is on the store can be patched to run in the simulator because there are legitimately symbols missing or with stubbed functionality.
HBM itself is very expensive but it’s not really fair to compare to LPDDR or GDDR
They’re very different things.
The more logical argument to me is that Apple uses its upgrade price points as more than just direct BOM and rather as a proxy for things that are amortized across all their sales like support/warranty/etc so higher SKUs subsidize the costs of the lower ones.
I’m not sure I follow why the performance is “Insane”
This is a M5 level chip that runs slightly within a ballpark of M5 wattage (afaik M5 is between 15W max on an iPad and 30W max CPU+GPU on a cooled Mac)
This is running in a thermally unconstrained bench setup and has potentially worse power consumption with what will be lower than previous gen performance when this and the alleged M6 are truly out.
So tired of people on HN calling you out for being excited about tech.
It gets M5-level numbers at 12-14W.
It gets about 30% better perf than the A19 Pro at equal wattage on the whole 4W - 8W range.
So no it's not worse power consumption than prev gen. This is ARM's stock GPU having finally caught up and being competitive with Apple and Qualcomm's mobile GPUs.
This is insane to me. Stay cynical if you want, I have the right to be excited about it.
I’m not trying to say you shouldn’t be excited by it. But there’s a significant number of caveats to every single number you posted but you glossed over the points I made.
And in being defensive, you jumped straight from the topic you were discussing (GPU perf) to CPU perf numbers to try and make a point.
There’s a difference between being cynical and pragmatic, just as there’s a difference between being hyped and realistic.
You haven’t seen this in a product. You’re seeing development board numbers. Be excited all you want but it’s a public forum, if you want to just post without any responses make a blog.
No? The numbers I quoted were GPU numbers, sourced from this video [1].
Also I explicitly acknowledged in my first comment that real devices won't be able to draw that kind of power. But 4 watts is 4 watts whether it's in a test bench or a phone.
A lot of people may be more empowered to create things now with less up front effort but it doesn’t lead to having better ideas or more actual system architects.
reply