
When the Steam Frame was announced, the idea that a high-end VR showcase like Half-Life: Alyx would run natively on a modestly powerful, ARM-based headset seemed far-fetched - and Valve set expectations accordingly. Even earlier, the mood internally was simple: "this is never going to work." Yet, as Valve engineers used Alyx as a test-bed for standalone games on the headset, progress came surprisingly swiftly, and Alyx is shipping alongside Frame as a fully native game on the system.
Speaking to project lead and gameplay programmer Robin Walker and engineer Autumn Ashton, who did much of the port work alongside years on SteamVR, Steam Deck and driver development, that initial scepticism was well founded: Alyx was never designed to be squeezed. As Walker puts it, Alyx was the result of "overinvesting resources" to build "our best attempt at what a VR game could be." He goes to say that the team "didn't make any real compromises around performance or anything, because that was antithetical to the goal."
What shifted the calculus was hardware. Streaming to Frame was always going to be a good experience, but as the platform's feature set came together, a native build started to look less absurd. "As you start to get more features and the stack working - foveated rendering, eye tracking, and the fact that the headset has 16 gigs of RAM - it made us think 'maybe, maybe we could get there with some work'," says Ashton. Walker positions gaze-driven rendering as the thing that made the whole project thinkable: "I think the foveated rendering and eye tracking was this potential silver bullet. We didn't know how much value we were going to get out of that, but that was sort of the shining star or guiding light."
Ashton began hacking on a prototype, and immediately ran into the most fundamental difference between the two targets: Frame's GPU is a tiler, whereas a desktop part is an immediate-mode renderer. That distinction is invisible to players and brutal to a renderer that wasn't written with it in mind. "Half-Life: Alyx occasionally would break rendering to go do something else for a bit, then come back to it, and that has a much bigger cost on the Steam Frame than it would on a desktop," Ashton explains. The work was less a single architectural rewrite than an audit: "finding all these death by 1,000 cuts type things to go and find fixes for them - that was the main thing."
The prototype was enough to prove the idea, and Walker is candid that what followed was not glamorous. After that first milestone roughly 18 months ago, he says, "it's not particularly sexy, I guess, but then there's just a year and a half of grinding software work as we work through drivers, new features in SteamVR and so on." That grind is arguably the real story of the port, because very little of it lives inside Alyx itself. The overwhelming majority of the performance came from beneath the game.
Ashton makes the point that Alyx's value to Valve was as much diagnostic as commercial. "Half-Life: Alyx was a really good forcing function for getting other parts of the stack into shape for us to ship the Steam Frame," she says. "We discovered so many things in driver, so many things that we needed from the SteamVR side - that even if we didn't ship Half-Life: Alyx on Steam Frame, doing that one and a half years of work... it was completely worth it." Walker adds the strategic framing: driver and compositor work on new hardware is normally speculative, an attempt to guess at the shape of software that doesn't exist yet, and "it was super useful to have, for once, an extremely clear target: we need to make that thing run as well as it possibly can." Alyx, he notes, is "a superset of a lot of the problems that people have run into on VR".
The iteration speed that made 18 months of driver work possible came from the open-source stack. "We wouldn't have been able to do any of this without having open-source drivers, because we were iterating so quick," says Ashton. "You could have a problem, we'd see it in Alyx or any other game in the catalogue that we're helping third-party developers bring up, and we can have something testable within minutes potentially, instead of weeks or months away if you're working with a third-party vendor on drivers." It's a practical argument for Valve's Mesa-based approach, and it applies well beyond this one title.

When it comes to performance, Alyx renders at 36fps on Frame and is re-projected upward, but the technique is more sophisticated than a simple timewarp. "We're running at 36fps, but we're using depth reprojection," Ashton says. Using a hand held in front of the face as an example, she describes the parallax problem: the hand and the background move at different rates as you shift, and a naive reprojection can't reconcile them. "If we provide a depth texture from Alyx, or any other game provides a depth texture, we can incorporate that information into reprojection, so that even if you're doing this, we can be completely smooth. You wouldn't be able to tell." Alyx doesn't supply motion vectors, and the implicit motion-smoothing path in SteamVR that handles that case remains in beta - but many third-party VR developers already had motion-vector pipelines feeding the compositor, so Valve brought that route up first and those titles benefit too.
Image quality rests on eye tracking, and Ashton is unequivocal about its necessity: "I don't think it would have been shippable without having eye tracking giving us the gaze information to feed into foveated rendering." SteamVR exposes a fragment density map that developers can either consume automatically via the injection layer or author themselves for tighter control, and dialling in Alyx's own map was hand-tuning rather than automation - "probably about a week of going through a lot of content and all the different resolution levels that we wanted to tune it for". Only a couple of Alyx's shaders needed adjusting for the architecture; as Ashton notes, "the overarching majority of the work was done in the driver and SteamVR.
Perhaps the most consequential decision was one of restraint: Valve refused to touch the game's content. The team asked itself what version customers would most want shipped, and, as Walker explains, "it seemed really clear that the most valuable version would be one where we didn't go and change a bunch of content." The reason is the Workshop. "There's a vast amount of content in the Half-Life: Alyx Workshop these days, and if we went and changed a bunch of content to make Alyx run, that content would be unlikely to work, or we'd be asking Workshop people to come back and [make changes] - that's just not going to happen." The gap between a Frame version where all that community content simply works and one where it doesn't was, he says, "really, really significant". Valve's regard for that community is not abstract either. "We have hired multiple people now because of the work they did in Half-Life: Alyx levels."
The knock-on benefits are the ones players will feel. Because nothing was forked, Steam Cloud saves and crossplay work across Windows, Linux and Steam Frame, so you can take the streamed, higher-resolution PC experience at your desk and pick up the same save standalone. Controller support needed a pass but not a rewrite, since Alyx already carried a translation layer for the several headsets and controllers in circulation at launch; Ashton recalls changing "the backpack height very slightly on Steam Frame just to make it easier," and little else. The per-controller work, Walker notes, is stubbornly manual - just a case of going in and tuning it "until it feels as good as you can". Stutter, meanwhile, is handled by the Steam Shader Cache, which records a game's shaders and either delivers them precompiled or builds them server-side, so "as soon as you start playing a game, you're playing with a fully filled shader cache".
Where does this leave everyone else? Ashton is careful not to overclaim on Alyx's behalf: the route for third parties runs less through this port than through compatibility tooling such as FEX and Lepton, the goal being that developers can ship one build rather than several. Valve had its own in-house option here - the core engine was already running on ARM thanks to its past work on Dota and Artifact - which most studios won't, hence the emphasis on offering a menu of paths rather than a mandated one. Both are clear that the investment continues after launch, in the Steam Deck mould, where titles that ran at launch simply ran better a year on.
The most interesting takeaway, though, is the one Walker offers about Valve's own assumptions about the capabilities of native VR headsets: "Man, we really should be expecting more on our native work... we had decided there was just limits on what we could do in our native stuff that were probably accurate at some point, but they've just become inaccurate, and we weren't challenging ourselves enough." His hope is that the lesson spreads - that gamers and developers alike realise that "we can push native games further".
It will be fascinating to see how the arrival of Steam Frame affects the PC and standalone VR spaces, especially if we do see an uptick in the fidelity of standalone experiences. It's clear that Valve has worked hard on the whole ecosystem, not just the headset itself, and there's plenty more planned to improve performance and add features to this new ecosystem. It's hard to see Steam Frame becoming as mainstream as the Steam Deck when it costs over $1000, but a full pipeline means that Frame's value should at least improve over time.