FEX caps its translated code cache at 1GB, answering its own September warning

FEX, the translator that turns x86 game code into Arm64 instructions inside Steam Frame’s Proton stack, now holds its cache of translated code to 1GB and throws away stale caches whenever it updates. Both changes answer gaps the project listed in its own September release post, which said the cache could “technically grow unbounded” and that there was no way to remove stale entries.

Valve’s own video thumbnail for signing in to Steam on a Steam Frame. Credit: Valve. Image: Valve

They arrived in FEX-2610, which the project dates October 7 and which GitHub’s release feed timestamps at 19:19:40 UTC the same day, read at 21:03 UTC on October 8. The disk cache is the feature aimed at JIT stutter: once it is switched on, FEX writes the Arm64 code it generates out to a database and looks the result up on later runs rather than translating the same game code again.

The cap answers the project’s own September warning

FEX shipped the cache as an opt-in in September and said at the time what was missing from it. “If the disk caching is enabled on applications that JIT code itself, then the cache can technically grow unbounded,” the FEX-2609 post says. “We haven’t yet implemented any caching size limits or any way to remove stale cache entries.”

Both gaps are closed in the FEX-2610 post. “Now when the disk cache is enabled it will automatically limit its cache size to 1GB, where we will then stop caching at that point,” it says. “This is configurable in the INI options for more or less space to be consumed, but because some edge cases allow it to have unbounded growth, it seems like a good balance at 1GB.” On upgrade, FEX “will automatically remove old disk caches that aren’t relevant to the new version”, so that owners do not “have multiple 1GB cache files laying around as they upgrade over time”.

There is a second cache on top of it, and the project is careful about who should bother. The optional in-memory buffer holds hot blocks of translated code, and is “only worth using if a game stutters frequently from JIT invocations and you have spare RAM to allow some additional caching”. A smaller change keys cached ELF files on the embedded GNU build-id, which FEX says helps where a game file has been replaced and an outdated cache would otherwise be used.

A software fallback for one chip’s random numbers

FEX-2610 also adds software versions of the x86 RDRAND and RDSEED instructions, which return random numbers and which some programs refuse to start without. It is off by default because, in the project’s words, “the performance isn’t as good as a hardware implementation”.

The reason it exists is blunter. The fallback is “also useful for platforms with Qualcomm Oryon where their RNG implementation is bugged and doesn’t return real values”, FEX writes. That is the project’s own characterisation of another company’s silicon rather than a Qualcomm statement, and FEX publishes no measurement alongside it.

A lighter month, by the project’s own account

The rest is housekeeping. FEX added support for AVX-VNNI, which it says some game libraries have started using, sped up the SSE4.2 string operations, re-enabled AMD’s 3DNow! after fixing its last known bug, and improved the x87 FXAM instruction because Mono uses it to detect denormals. The project puts the thin month down to the X.Org Developer’s Conference.

None of this is Valve’s work. FEX is a separate project that sits inside the Proton stack alongside Wine and DXVK on Arm64, and the disk cache remains opt-in, so the 1GB ceiling changes nothing for anyone who has never switched it on. For the people who did, the cache that could grow without limit now stops at 1GB, and the old ones go away on their own.

Note: Links to online stores in articles can be so-called affiliate links. If you buy through this link, MIXED receives a commission from the provider. For you the price does not change.