Our earlier DOOM demo ran a DOOM-style renderer on Chimera. Fixed-point arithmetic, texture lookups, and irregular control flow really put our processor’s general-purpose capabilities to work.
Experiments like Jev Plays Doom inspired the next step: a player. A decision model answers questions about the game, like “Should I fire? Which way should I move? Do I need to dodge?”, and turns those answers into actions. We wanted a player that answers those questions from the same frames a human sees. Chimera can already render DOOM and run transformer models, so we asked: can it do both at once, rendering the game and playing it?
Chimera renders every frame, and the ViT reads it and decides the next move. The panel on the right shows its answers to the questions it asks itself.
Choosing the right model
2026 has been a big year for getting transformers running on Chimera. We’ve brought up models for vision with BEVFormer, speech with Whisper, and action with pi0.5, so we had several working transformer implementations to draw from.
We chose a small vision transformer, or ViT. It divides an image into patches and uses attention to learn relationships between them, so information from anywhere on the screen can feed a decision about aiming, moving, or an incoming fireball.
Our ViT has about 2.1 million parameters. It takes the two most recent frames, which give it evidence of motion, plus health, ammunition, and armor values. In one forward pass it answers twelve questions, and a policy turns those answers into player controls.
Its questions include “Should I fire?”, “Should I dodge now?”, “Which way should I dodge?”, and “Where is the nearest enemy?” The rest ask what to do next and what matters most, whether it can see an enemy, how many there are and how close the nearest one is, whether a fireball is about to hit and where it’s coming from, and whether its health is low.
Training the player
All the Jev experiments also raised a training question: could a transformer that makes decisions from text teach a smaller model to make decisions from images? Then we could use a large model during training and still deploy a player small enough to run alongside the renderer.
We used LAYA, a 421-million-parameter decision model, as the teacher. LAYA reads descriptions of the game state and answers questions about firing, moving, and dodging. A small game-state expert learns those answers, with a physics-based reflex choosing the dodge direction.
The expert then plays the game to produce demonstrations for the ViT. The Chimera renderer draws every training frame, so the ViT learns from the same renderer it plays with. The expert reads exact positions from the game; the ViT has to work them out from the pixels.

Teaching the player. LAYA and the game-state expert are training tools; at play time the player sees only rendered frames and HUD values.
Running both on Chimera
The renderer is a C++ kernel. The ViT compiles through the Chimera Graph Compiler as a model graph, with no custom operators. Both kernels run on the same GPNPU and share its time between drawing frames and running the model. The host runs the game simulation, prepares the model’s inputs, and applies the policy.

Renderer and model execution. Rendering and inference share the processor's time budget; the host runs game simulation, input preparation and the action policy.
The renderer is branching, texture access, and fixed-point arithmetic; the model is attention and matrix math.
How well does it play?
The demo plays a defend-the-center arena, with enemies arriving in waves. Every wave asks the player to aim, move, and dodge.
We gave the player twelve arenas with enemy spawns it hadn’t seen in training. It survived all twelve two-and-a-half-minute games, with 269 kills across the runs. Both rendering and model inference ran in the Chimera instruction-set simulator.
Fireballs incoming: the player sees them in the frame, decides to dodge, and steps out of the way. Unmute to hear the player’s commentary.
The player also talks through its moves. When a move has a reason, it says the question behind it, the network’s answer, and the move: “Where is he? On my left. Strafing left.” A dodge gets a quick shout instead: “Step left. Fireball on my right.”
Its voice comes from a text-to-speech model: Kokoro-82M's text model runs on the host, and an 8 kHz vocoder distilled from it runs on Chimera as three int8 kernels. The player can say 300 different lines, and Chimera synthesizes all of them ahead of time.
Running it live on HAPS-200
Next, we moved the player and renderer from the simulator to a HAPS-200, an FPGA prototype of our QC-P processor. Even at 50 MHz, the renderer and model run live. In a 150-second reference episode, all 1,125 decisions and 2,250 rendered frames matched the simulator exactly.
Then we ran four independent games at once, each on a separate FPGA in our HAPS-200 setup. Each FPGA hosts a QC-P instance running both the renderer and the ViT, with all four games running simultaneously. Our real-time target was 15 rendered frames and 7.5 decisions per second for each game. In our throughput test, all four exceeded that target, each achieving approximately 1.46× real-time throughput. It quickly became our favorite thing to watch over lunch in our Burlingame office!
Four players, four games, live on HAPS-200.
It runs DOOM. It plays DOOM.
Our earlier DOOM post showed the renderer on an FPGA prototype. Now the player runs there too.
We've proven that Chimera can render DOOM and run a model that plays it, at the same time! This is general-purpose programmability in practice ... and a considerably more interesting answer to “Can it run DOOM?”
Explore the Chimera SDK and runnable demos. The DOOM player demo ships in SDK 26.10, including the renderer, trained model, compilation workflow, and validation.
