[HN Gopher] FEX-emu - Run x86 applications on ARM64 Linux devices
___________________________________________________________________
FEX-emu - Run x86 applications on ARM64 Linux devices
Author : open-paren
Score : 284 points
Date : 2025-11-12 20:15 UTC (9 days ago)
(HTM) web link (fex-emu.com)
(TXT) w3m dump (fex-emu.com)
| open-paren wrote:
| > FEX allows you to run x86 applications on ARM64 Linux devices,
| similar to qemu-user and box64. It offers broad compatibility
| with both 32-bit and 64-bit binaries, and it can be used
| alongside Wine/Proton to play Windows games.
|
| > It supports forwarding API calls to host system libraries like
| OpenGL or Vulkan to reduce emulation overhead. An experimental
| code cache helps minimize in-game stuttering as much as possible.
| Furthermore, a per-app configuration system allows tweaking
| performance per game, e.g. by skipping costly memory model
| emulation. We also provide a user-friendly FEXConfig GUI to
| explore and change these settings.
|
| > On the technical side, FEX features an advanced binary
| recompiler that supports all modern extensions of the x86(-64)
| instruction set, including AVX/AVX2. The heart of this recompiler
| is a custom IR that allows us to generate more optimized code
| than a traditional splatter JIT. A comprehensive system call
| translation layer takes care of differences between the emulated
| and host operating systems and implements even niche features
| like seccomp. A modular core enables FEX to be used as a
| WoW64/ARM64EC backend in Wine.
|
| Used by the new Steam Frame
| (https://store.steampowered.com/sale/steamframe) which is an
| ARM64 Snapdragon 8 Gen 3 that will run PC and PCVR gaming titles.
| sitkack wrote:
| Not just used by, Valve is sponsoring FEX.
|
| https://news.ycombinator.com/item?id=45903610#:~:text=Valve%...
| cubefox wrote:
| I wouldn't call this random comment reliable testimony that
| they are sponsoring FEX.
| teroshan wrote:
| As the random commenter I agree. By "support" I meant that
| they have a line of product and a strategy that relies on
| FEX to work and work as seamlessly as possible.
|
| If they contribute to FEX at even a fraction of what they
| did to wine and Proton it is indeed huge.
| Lightkey wrote:
| https://gamersnexus.net/pc-builds-news/valve-steam-
| machine-d... "Valve has devoted significant resources to
| the development of FEX emulation."
| thehias wrote:
| Man, Fex is Valve, Valve is Fex! The steam logo is right
| there in the logo!
|
| https://files.mastodon.social/accounts/headers/110/652/595/
| 6...
|
| Center of left side, it is a Valve product. All main devs
| are employed by Valve.
| mirashii wrote:
| https://www.igalia.com/2025/11/helpingvalve.html
| geerlingguy wrote:
| CodeWeavers' Crossover just released a Preview version for Arm
| that incorporates Fex and allows games like Cyberpunk 2077 to
| run: https://www.codeweavers.com/blog/mjohnson/2025/11/6/twist-
| ou...
|
| I've tested it on an Ampere workstation, and was trying it on a
| Pi, but it seems with Trixie, there may be some bugs with both
| that and box64 right now, I was having trouble with both of
| them.
| nialv7 wrote:
| Hey, it's that YouTube guy with cursed Raspberry Pi setups!
| somanyphotons wrote:
| What motivates CodeWeavers specifically to work on this?
| aj_hackman wrote:
| They make CrossOver, which is a productized version of Wine
| that lets you run Windows software on MacOS. They also work
| closely with Valve, who have just announced Steam Frame (a
| device that runs SteamOS on ARM).
| GeekyBear wrote:
| > The main corporate sponsor of Wine is CodeWeavers, which
| employs Julliard and many other Wine developers to work on
| Wine and on CrossOver, CodeWeavers' supported version of
| Wine.
|
| https://en.wikipedia.org/wiki/Wine_(software)
| globalnode wrote:
| Does that mean I can run windows games on my rpi? (In theory at
| least)
| adgjlsfhk1 wrote:
| Yes (just possibly at ~2 fps)
| GCUMstlyHarmls wrote:
| Into the Breach is back on the menu.
|
| There's probably a mountain of x86 games that would not
| need to hit above 15-30fps to be fun.
| ThatPlayer wrote:
| Into the Breach can even run on a Pi 4:
| https://youtu.be/jF6xGlmKVUQ
| geerlingguy wrote:
| Put a GPU on it, and you can get 30+ fps in some newer(ish)
| games, 60+ fps in older games.
| coredog64 wrote:
| A binary recompiler for running x86 on a different
| architecture? Where have I heard this story before?
|
| https://en.wikipedia.org/wiki/FX!32
| cultofmetatron wrote:
| I'n incredibly impressed by valve's commitment to playing the
| long game. It makes sense to have the frame by arm since the
| system is lighter and its clear this is just the trojan horse to
| get arm linux into every gamer's house. I wouldn't be surprised
| if we end up with an arm steamdeck 1-2 version from now when the
| tech is ready.
| sitkack wrote:
| Too bad Arm doesn't allow architectural licenses, because this
| is _exactly_ the kind of thing Valve and the FEX developers
| would want to extend the ISA to support. I bet we see a RISC-V
| backend to FEX in the next 6 months, it probably already exists
| in a private repo.
|
| FEX is the shootstring, extra special discount budget (not
| maligning) version of Rosetta. Apple should sell Rosetta to
| Valve.
| JoshTriplett wrote:
| > Too bad Arm doesn't allow architectural licenses
|
| QEMU exists. I doubt they want the bad press of suing an Open
| Source project everyone is using.
| happymellon wrote:
| ARM were perfectly fine getting the bad press for suing
| Qualcomm for releasing the Snapdragon that was finally
| performing enough despite these companies paying them a lot
| of money.
|
| They seemed quite happy to destroy their eco system if they
| won.
|
| https://www.rcrwireless.com/20251001/business/qualcomm-
| arm-2
| anthk wrote:
| And GBA emulators. And before that, BBC Accorn ones with
| Risc OS.
| geerlingguy wrote:
| Box64 already runs on RISC-V. Just, the available processors
| are so slow it's hard to even play 5-10 year old games.
| snvzz wrote:
| This means that, when the much faster chips implementing
| RVA23 arrive next year, they'll be immediately able to run
| Box64.
| jsheard wrote:
| My understanding is that Rosetta sidesteps a bunch of tricky
| memory model issues by using non-standard hardware extensions
| only present in Apple Silicon, so even if Apple did share
| Rosetta, which they certainly won't, it wouldn't work
| properly on Valves hardware anyway.
| fooblaster wrote:
| yeah that is correct. The m series chips can turn on total
| store ordering memory model solely for Rosetta. There's
| also some hardware extensions to arm to support x86
| condition codes in the hardware because it's way more
| instruction efficient that way.
| astrange wrote:
| If you mean FEAT_FlagM, that's standard in ARMv8.4.
| (There's also FlagM2 and AFP that are optional.)
|
| The JavaScript instruction is cooler though.
|
| https://developer.arm.com/documentation/dui0801/g/A64-Flo
| ati...
| gorkish wrote:
| RISC is dead; long live RISC
| sgerenser wrote:
| The latter is now an optional feature in the mainstream
| Arm ISA now (FEAT_FlagM and FEAT_FlagM2). Similarly the
| "alternate floating point mode" that Apple uses to match
| nuances of x86 FP semantics is a standard architectural
| feature as well. The TSO option though is Apples own
| thing.
| astrange wrote:
| It's not only present in Apple Silicon, it's just not
| required by the ARM standard. Fujitsu also has an ARM64 CPU
| with TSO.
| wmf wrote:
| There are a bunch of undocumented flags and instructions
| beyond TSO.
| astrange wrote:
| Trust me on this one?
| chadaustin wrote:
| https://dougallj.wordpress.com/2022/11/09/why-is-
| rosetta-2-f...
|
| > Apple M1 has an undocumented extension that, when
| enabled, ensures instructions like ADDS, SUBS and CMP
| compute PF and AF and store them as bits 26 and 27 of
| NZCV respectively, providing accurate emulation with no
| performance penalty.
| astrange wrote:
| Oh yeah, maybe that one was too obscure for me. I don't
| think I've ever seen something use PF/AF...
|
| You do want FEAT_AFP though, so you do want ARMv8.6+.
| bonzini wrote:
| SETP is used rarely to compute parity, though it doesn't
| really save anything if you can use POPCNT. PF is also
| used by floating point comparisons with a different
| meaning though that is not useful for the Arm extension
| from Apple.
|
| AF indeed is basically unused. The problem for both is
| that you need them for accurate emulation "just in case".
| dangus wrote:
| Perhaps another interesting aspect of this is that it'll
| be Apple with their vertical stack that will decide when
| to physically remove this logic from the chips.
|
| macOS 26 is the last OS with an Intel build. Presumably
| this means that in all likelihood, M6 chips will remove
| this functionality.
| wtallis wrote:
| Why do you assume that dropping support for Intel
| hardware from the OS will coincide with dropping hardware
| features that help support for x86 applications? Have you
| not seen Apple's documentation that states they plan to
| retain some Rosetta functionality beyond macOS 27 for the
| sake of x86 games?
| lugu wrote:
| Nice article on this topic:
| https://lwn.net/Articles/970907/
| sitkack wrote:
| There are also RISC-V designs with TSO. If you are
| targeting x86 workloads, it makes sense to have a per
| thread TSO mode.
| nullbyte808 wrote:
| better yet, Apple should make it open-source on github.
| scotty79 wrote:
| > Apple should sell Rosetta to Valve.
|
| Isn't Rosetta kinda bad though? And won't get much better
| because it's not open source?
| MobiusHorizons wrote:
| Rosetta performance is best in class to my knowledge,
| although they had the benefit of being able to add custom
| instructions and modes to the cpu to make some parts
| easier. Meaning Rosetta would not have helped valve unless
| they built the frame on apple silicon.
|
| As for not improving, it is likely that Apple no longer
| feels the need to invest in Rosetta improvements now that
| Apple silicon is so dominant and software support is
| already very strong, but nothing is stopping them from
| investing in it if they need it for example for gaming
| scotty79 wrote:
| Rosetta is abandonware:
| https://developer.apple.com/documentation/apple-
| silicon/abou...
|
| Why would a company on its way to the moon, entrust such
| an important project as translation layer between two
| major architectures to a single rinky-dinky corp that got
| rich selling common electronics marketed as luxury fluff,
| that's on the decline and has head so far stuck up its
| butt that it thinks it can do whatever it wants, instead
| of just write it themselves with support of the global
| developer community?
|
| Apple could never do games because there are no luxury
| games. That's completely out of their zone of
| comprehensibility.
| dontlaugh wrote:
| I don't know if the two companies have such different
| futures.
|
| The games industry as a whole is in potentially terminal
| decline, have you seen all of the redundancies lately?
| kokada wrote:
| The AAA games industry with their multi-million budgets
| and "being too big to fail" mentality is on decline. It
| seems that anything that is not a new Call of Duty is
| considered not worth by the industry.
|
| But smaller games and indie studios are thriving. We got
| lots of very interesting indie games this year.
| LeFantome wrote:
| You are looking for Felix86
|
| https://felix86.com/
| clausecker wrote:
| ARM already has most stuff required for this on board. Two
| proprietary extensions are used by Rosetta: one emulates the
| parity (rarely used) and half-carry (obsolete) flags, which
| can also be emulated conventionally. The other implementa TSO
| memory ordering, which can either be ignored or implemented
| with explicit barriers; some other chips apparently have a
| similar setting.
|
| The other stuff is all present in ARMv8.5 I think.
| theoldgreybeard wrote:
| It's amazing what you can do when you have a business that
| prints money hand over first and you have no obligations to
| shareholders.
| notepad0x90 wrote:
| Last I heard, they don't even have bosses there, a flat
| hierarchy. They vote on things and pick each other to work on
| teams and appraise performance. Perhaps that radical culture
| has merit to it?
| wmf wrote:
| Anything works when you have infinite money and the company
| is privately owned by a chill dude.
| systematizeD wrote:
| How much did Gabe own Valve, 50%?
|
| Gabe Ownership/co-founder:
|
| - Valve - Yacht Companies - Starfish Neuroscience (Neuralink)
| - Submarine Companies
| bbminner wrote:
| I've heard that to ship hl2 (or anything really) they had to
| stip some of that flatness somewhat.
| pjmlp wrote:
| I would appreciate more if they also would take devs into
| SteamOS water, instead of relying on Microsoft kindness.
| Havoc wrote:
| Helps that they are in dominant position and basically just
| need to not fuck up
| Venn1 wrote:
| I tried out FEX on a modern ARM board with a discrete GPU. Really
| impressed with the performance.
|
| https://interfacinglinux.com/2025/06/30/fex-emu-gaming-on-th...
| roody15 wrote:
| Wow decent results.. impressed.
| Plagman wrote:
| I would keep in mind that the results reported there are
| likely quite a bit lower (in terms of CPU-side performance)
| than what you could achieve in practice, because it's running
| all of x86 Steam+Proton in the emulator. In a pre-configured
| environment (like SteamOS for ARM), the Steam client and
| Proton itself would be native ARM code, and emulation would
| stop at the win32 API boundary (or at certain critical
| libraries' APIs if you're using Linux apps).
| Lightkey wrote:
| Fancy seeing the Plagman here. Last time I saw you was on
| Freenode (R.I.P.). So you are still working for Valve? ;-)
| TinkersW wrote:
| FEX is a CPU JIT, so your GPU settings are irrelevant to it, it
| is translated but not by FEX, and there is no real perf hit for
| the GPU
|
| The old games don't really matter with regards to FEX perf, so
| the only relevant bit is the semi newer games at 30/40 fps,
| which seems very slow to me, given that you are only running at
| 1080p/Medium, so you likely have a CPU bottleneck there.
| fooblaster wrote:
| How does fex deal with the fact that the memory model on arm is
| weak and x86 is total store ordering. It seems like would need to
| hammer performance by putting memory barriers everywhere to
| handle all cases. Perhaps fex only works when there are well
| defined mutexes it can gain visibility into? anyone know?
| nialv7 wrote:
| I think that's right, there is no better way than just adding
| barriers. On Apple hardware it can probably make use of the
| special memory ordering mode, but on normal ARM64 there's
| probably nothing it can do.
| ant6n wrote:
| There's one trick: run those threads on one cpu. But that may
| be slower than barriers on multiple CPU's, unless the code
| uses a lot of library code that can be emulated directly,
| separately on other cpus.
| jsheard wrote:
| Looks like they do expensive conservative TSO emulation by
| default, but they're able to piggyback on compiler work that
| Microsoft did to make newer Windows x86 binaries easier to
| emulate. Since MSVC 2019 they annotate the executable with
| metadata that informs an emulator of when TSO is or isn't
| needed for correctness.
|
| https://fex-emu.com/FEX-2510/
|
| FEX also has settings which weaken or disable TSO altogether,
| favoring performance over correctness. You wouldn't want to
| rely on those for anything important but a game possibly
| crashing isn't the end of the world.
| dbdr wrote:
| So that optimization only works on executables produced by
| MSVC? Are those annotations documented and/or produced by
| other compilers?
| saagarjha wrote:
| No.
| trollbridge wrote:
| It would be nice to see more Arm chips adopt Apple's approach
| (which fixes this problem) for Rosetta 2. Basically, Apple's
| chips can be switched into a TSO mode and a few other minor
| tweaks that make x86 code run much, much faster.
| nullbyte808 wrote:
| Now we just need a decent ARM Linux laptop.
| overfeed wrote:
| Snapdragon Elite X laptops are plenty decent.
| ben-schaaf wrote:
| Not for Linux they're not. IIRC Audio and camera don't work,
| and firmware is non-redistributable and so you need to mooch
| it off a Windows partition. On top of that the performance on
| Linux hasn't been great either.
| LeFantome wrote:
| Highly depends on which laptop
| donkeylazy456 wrote:
| Qualcomm's linux support is not.
| overfeed wrote:
| That's true Qualcomm in general, but is fortunately
| outdated for the Snapdragon Elite _X_ (and only the X).
| Qualcomm has been upstreaming patches to Linus ' tree[1] -
| but only for the Elite X - the Elite P processors get the
| classic Qualcomm treatment.
|
| 1. https://www.qualcomm.com/developer/blog/2024/05/upstream
| ing-...
| wtallis wrote:
| You're mangling Qualcomm's branding to the point that
| it's impossible to be sure what you're trying to say.
| Qualcomm's current laptop SoCs are called "Snapdragon X
| Elite" or "Snapdragon X Plus" or "Snapdragon X", all
| derived from various bins of two SoC designs, and all
| pretty much in the same boat for driver support purposes.
| "Snapdragon X2 Elite" and lesser siblings are due in the
| first half of next year, so a respectable degree of Linux
| support would mean having driver support for those chips
| in an upstream kernel release _now_ so that there might
| be a mainstream distro supporting the hardware at some
| point in the quarter after the hardware ships.
| overfeed wrote:
| My apologies to you and the entire Qualcomm marketing
| team for my brand-guideline violations - I was going off
| the top of my head. What I meant in my inscrutable
| comment was: "Elite X" => "X Elite", "Elite P" => "X
| Plus", I really should not have mangled the products
| using such an elegant and intuitive naming convention.
| wtallis wrote:
| Ok, so having clarified the naming, it still looks like
| you're wrong about which chips are getting driver support
| upstreamed, because the Snapdragon X Plus parts are (with
| maybe one exception, IIRC) literally _the same chip_ as
| the Snapdragon X Elite parts. Do you really believe that
| the upstream Linux kernel would accept patches that are
| specifically crafted to only work on certain bins of the
| chip, or to fail to enable a peripheral if not enough of
| the CPU cores are enabled?
| overfeed wrote:
| Don't take my word for it - go to the Ubuntu Concept
| Snapdragon thread[1] and search for "plus" or "x1p".
|
| > Do you really believe that the upstream Linux kernel
| would accept patches that are specifically crafted to
| only work on certain bins of the chip, or to fail to
| enable a peripheral if not enough of the CPU cores are
| enabled?
|
| It takes more than a kernel patch to boot a laptop.
| Qualcomm has been neglecting to release the dtbs for Plus
| laptops. If you want good peripheral support, don't buy a
| "plus" variant. Getting back ro your question, the answer
| is "Yes, Linux has always accepted patches that only work
| on _some_ configurations " with no requirement to support
| _all_ h /w configurations or variants. Infact, some
| configurations are so obscure only the submitter can test
| - the maintainer/subsystem tsar/Linus may not even know
| what the potential variants are.
|
| 1. https://discourse.ubuntu.com/t/ubuntu-concept-
| snapdragon-x-e...
| thehias wrote:
| Get a MacBook with Asahi Linux
| thehamkercat wrote:
| Asahi Linux doesn't support M3/M4/M5
| sitkack wrote:
| And? Get an M1/M2 off of ebay or craigslist.
| rollcat wrote:
| Anyone can recommend something viable for simple tasks? I don't
| need 32GB of VRAM, just a reliable machine for everyday tasks
| that's decent, lightweight, has a good battery.
|
| (I know I'm describing an M2 Air, but I'd like to explore
| alternatives.)
| myndpage wrote:
| I have the azus ZenBook a14 with X Elite, 32GB ram, 1TB SSD.
| Overall it works great on Ubuntu concept. Only speakers and
| camera do not work (I heard speakers can work with some
| risk). I just use usb headphones instead and my webcam. The
| laptop itself is very light with long battery life. I expect
| it to be better supported at some point hopefully, but it's
| getting there.
| LeFantome wrote:
| I would wait for X2 Elite laptops at this point.
|
| Qualcomm is already upstreaming support into Linux.
| danans wrote:
| Lenovo Chromebook Plus 12 or Acer - Chromebook Plus Spin 514.
| Both have an M2 equivalent MediaTek Kompanio ARM CPU/GPU, and
| comes with native Debian VM built in (Crostini) that runs
| standard Linux desktop apps. Battery life and performance are
| great. You can even get it pretty loaded up with RAM to run
| smaller LLMs if that's your jam.
|
| As you can tell from my past comments about Chromebooks as
| Linux workstations here, I'm a daily user and very happy with
| them.
| LeFantome wrote:
| I would wait for X2 Elite laptops at this point.
|
| Qualcomm is already upstreaming support into Linux.
|
| Take this with a grain of salt but since we are one the topic
| of games....
|
| https://www.techpowerup.com/343081/qualcomm-says-90-of-games...
| willis936 wrote:
| Alternatively: we need fex-emu to run on macos.
| jasonjmcghee wrote:
| Curious how this will impact the major games that are
| incompatible due to denuvo type stuff
| paulryanrogers wrote:
| IIUC that DRM involves kernel level tricks and attestation,
| which means it'll basically never happen. Online gaming looks
| similarly doomed.
| dralley wrote:
| Plenty of online games work fine. Rocket League, Squad, Arc
| Raiders etc. are just the ones that I play.
| rounce wrote:
| In the case of those which use EAC/EOS they need to be
| explicitly approved to run under Wine/Proton by the
| developer. There are some cases (eg. iRacing) where the
| developer refuses to enable support for whatever reason,
| and on those we're still stuck.
| ThatPlayer wrote:
| It's not just 'running under Wine', it's a different
| anti-cheat with different capabilities and the same name.
|
| It's like comparing Office 2024 Excel on Windows to Excel
| for iPad. They're both called Excel, and share basic
| features, but once you start using features like VBA, it
| will not run on iPad Excel.
|
| Also does it even work in Wine? Last I checked EAC only
| worked in Proton with the env variable to enable it being
| _PROTON_ _EAC_RUNTIME
| sintax wrote:
| Denuvo anti-tamper DRM doesn't use kernel level tricks, it's
| all userspace and works just fine on Linux/Proton. It's the
| kernel level anti-cheats that don't work on Linux. And some
| user level anti cheats (like AntiCheat Expert) that only work
| on the Steam Deck as they check the CPU/GPU of the system and
| refuse to work if it's not the one in the Steam Deck (which
| also means those don't work on platforms like the ROG Ally).
| sedatk wrote:
| That doesn't even work properly on x86 Wine, so ARM is pretty
| much hopeless right now.
| akimbostrawman wrote:
| That is false. Denuvo DRM works on Linux and has for many
| years.
| sedatk wrote:
| I didn't say it doesn't work _at all_ , but it's been
| problematic. An example:
|
| https://www.gamingonlinux.com/2025/05/denuvo-will-lock-
| you-o...
| akimbostrawman wrote:
| That issue only happens if there are other issue with the
| game unrelated to denuvo on wine which requires trying
| different prefixes resulting in the DRM locking you out.
| Its the fault of the horrible DRM.
| akimbostrawman wrote:
| Denuvo DRM works on Linux and has for many years.
| yakaccount4 wrote:
| I believe a lot of the folks working on FEX are also core
| contributors to Dolphin, the Wii/GC emulator.
| zozbot234 wrote:
| Nope, Dolphin emulates PowerPC not ARM or ARM64. Totally
| different architecture.
| yakaccount4 wrote:
| I was saying some of the top contributors of Dolphin are also
| top contributors of this project based on GitHub data.
| HelloUsername wrote:
| That's really cool! I didn't know, thx for your comment :)
| cubefox wrote:
| One problem I see is that (e.g.) Qualcomm Adreno GPUs don't even
| run most Windows games well when executed natively under Windows,
| due to games only being optimized for GeForce and Radeon. I
| assume this problem only gets worse when trying to run DirectX
| games through some sort of translation layer with FEX/DXVK.
| LeFantome wrote:
| The GPU is not run through a translation layer. The GPU is not
| an x86-64 CPU.
|
| Only the CPU code has to be emulated. The GPU runs natively.
|
| That does not help with poorly supported GPUs of course.
| cubefox wrote:
| Pretty sure the GPU doesn't understand DirectX, which is used
| for Windows games, so it must be run through a translation
| layer.
| scheeseman486 wrote:
| Wrapping graphics APIs adds effectively zero overhead if
| the featureset of the hardware and drivers are a close
| enough match.
| Philpax wrote:
| See the corresponding Igalia article for more details:
| https://www.igalia.com/2025/11/helpingvalve.html
| skywal_l wrote:
| Presentation at FOSDEM2022:
| https://archive.fosdem.org/2022/schedule/event/fex/
|
| A little old but still interesting.
| pona-a wrote:
| How is it different to box64? I couldn't really find much online
| comparing these two except a brench by box64 themselves.
| systematizeD wrote:
| No different. Box64 only drm free game first, later they
| support drm games.
|
| Fex straight drm games.
| yonatan8070 wrote:
| Are you referring to Linux's Direct Rendering Manager or to
| Digital Rights Management in this context?
| systematizeD wrote:
| Digital Rights Management
| hydroreadsstuff wrote:
| Some companies like to stress the efficiency or performance of
| Arm SoCs, but really this is a hedge against more expensive x86
| hardware. AMD has increased prices of mobile SoCs radically
| recently. I'm looking forward to having more affordable SoC
| options for laptops, handhelds and desktops, perhaps from
| Mediatek or other lower-cost vendors.
|
| The history of the PC is one of commoditization. A fractured
| multi-polar landscape is detrimental to the
| ecosystem/productivity and should ultimately fail.
|
| x86 emulation is an important puzzle piece, and I'm happy Valve
| recognizes this and sponsors it.
| LeFantome wrote:
| This is for the Steam Frame
| VikingCoder wrote:
| So, can you run Steam and games on a Raspberry Pi 500?
| LeFantome wrote:
| Yup
| VikingCoder wrote:
| Like, already, or in theory?
___________________________________________________________________
(page generated 2025-11-21 23:01 UTC)