A 21B-Parameter Transformer Runs Doom’s Renderer Without Training

Cursor Horizon now has an unusual technical reference point: a 21-billion-parameter transformer that renders Doom without undergoing training. Developer Rob Porter compiled the game’s rendering algorithm directly into transformer weights. The result challenges the assumption that every large transformer learned its behavior from data.

This model does not predict what a Doom frame should resemble. It executes a translated rendering process, one generated token at a time. A prompt supplies scene geometry and camera state. The output contains intermediate calculations and drawing commands that a small host program converts into pixels.

That distinction separates the project from generative Doom experiments trained on gameplay videos. It also creates the central tension behind this Cursor Horizon story. Transformer inference has become a strange target for conventional software, yet the resulting program is drastically slower than the original game.

The public artifacts make the claim unusually inspectable. Porter released the compiler, renderer graph, checkpoints, prompt, decoding tools, and a reference implementation. However, most performance and accuracy results still come from the project’s own tests rather than independent replication.

Doom’s Renderer Became a Standard Transformer Checkpoint

The important change is not that an AI model produced a Doom image. It is that ordinary rendering code became the model’s weights.

Porter published the project on August 13, 2026, followed by a detailed community post. His technical write-up describes a compiler called torchwright. It turns computation graphs into the attention and feed-forward weights of a decoder-only transformer.

There is no optimization loop, training corpus, gradient update, or learned approximation of Doom gameplay. The compiler calculates the checkpoint’s weights from a graph written in Python. Those weights encode operations that the renderer needs during execution.

The generated artifact uses the standard Phi3ForCausalLM architecture. That matters because Hugging Face Transformers already knows how to load and execute it. Users do not need custom model code or the potentially sensitive trust_remote_code=True setting.

The flagship checkpoint contains 38 transformer layers and approximately 21 billion parameters. Its fp32 weight shards occupy 85.87 GB. A smaller 80-by-50 version uses 70 layers and 34.09 GB of fp32 shards.

The larger checkpoint receives a 3,614-token prompt representing the scene. It then generates 53,747 tokens before completing the frame. The combined sequence reaches 57,361 tokens.

Only part of that output directly paints pixels. The remaining tokens represent renderer operations, calculated values, control flow, and temporary state. They function more like an execution trace than natural language.

The published checkpoint includes the model configuration, tokenizer, prompt, palette, and decoding utilities. Its tokenizer uses readable words for operations and values. That choice makes portions of the execution trace understandable without decoding arbitrary token IDs.

The host program performs a deliberately narrow job. It remembers a cursor position, selects colors from Doom’s palette, and paints requested pixel runs. It does not calculate visibility, geometry, wall ordering, texture coordinates, or occlusion.

Five output commands control drawing. Two commands set the cursor’s coordinates. Two choose whether the cursor advances horizontally or vertically. The fifth paints a pixel run with a specified color and width.

That boundary is central to the project’s credibility. A model that merely asked external software to render Doom would be less interesting. Here, the checkpoint reportedly performs the view-dependent rendering work, while the host applies its drawing instructions mechanically.

The checkpoint is not the full Doom game. It does not implement gameplay, enemies, general sprites, sound, or player control. It implements a restricted version of the renderer for scenes using a fixed texture library.

The full output uses Doom’s 320-by-200 display resolution in low-detail mode. The renderer calculates 160 columns and displays each across two pixels. Nine wall textures and six floor or ceiling textures are compiled into the model.

Player position, viewing direction, map geometry, sector information, and the binary space partitioning tree arrive through the prompt. A binary space partitioning tree, or BSP tree, divides the map for efficient visibility ordering.

Those inputs can change without rebuilding the checkpoint, provided the scene stays within the compiled texture and configuration limits. Adding an unsupported texture requires recompilation.

This is why the Cursor Horizon framing deserves attention. The project treats a transformer checkpoint as an executable package format, not a learned knowledge store. Its parameters are program material generated by a compiler.

Why Cursor Horizon Challenges the Training-First Model

Torwright turns transformer architecture into a deterministic computing substrate, although it offers no practical replacement for conventional processors.

Most large language models acquire behavior through training. Engineers select an architecture, expose it to data, measure errors, and adjust weights through gradient descent. The final model contains patterns learned from those examples.

Torwright reverses that workflow. A developer defines a computation graph, and the compiler constructs weights that execute its operations. The finished transformer still predicts one token after another, but the prediction process follows a designed program.

The distinction resembles the difference between learning multiplication from examples and running a multiplication circuit. Both can produce the same answer. Their internal origins, reliability limits, and failure modes differ.

The open-source torchwright compiler supports linear operations, attention-based lookups, comparisons, selection, and multiplication. It schedules graph nodes across transformer layers and stores calculated values in the residual stream.

A residual stream is the evolving vector passed through a transformer’s layers. Torchwright assigns portions of that vector to program values. Once a value is no longer needed, another operation cancels it and reuses its space.

Attention performs more than semantic association in this arrangement. It retrieves values from earlier tokens by matching structured fields. Those fields can represent a node identifier, tree depth, operation type, or screen coordinate.

The feed-forward layers implement nonlinear operations. Torchwright offers operation libraries built from ReLU or SwiGLU activations. The compiler converts each graph operation into specific rows of feed-forward weights or attention heads.

This approach has academic predecessors. RASP introduced a programming language whose primitives map to transformer operations. DeepMind’s Tracr research compiled RASP programs into transformer weights for interpretability experiments.

Torwright extends that direction toward regular Python computation graphs and a stock Phi-3 output format. The target is significant because existing inference software can load the result without understanding its unusual origin.

That compatibility creates a provocative possibility. A standard checkpoint might contain learned statistical behavior, deliberately compiled logic, or a mixture of both. Its file structure alone would not reveal which path produced its weights.

For developers, this changes how model artifacts can be interpreted. Parameter count normally acts as a rough signal for learned capacity and inference cost. Here, 21 billion parameters primarily reflect an extremely inefficient compilation target.

The number does not mean the checkpoint possesses broad language knowledge. It cannot answer general questions or improvise Doom scenes outside its supported renderer. Its weights implement a constrained program rather than an open-ended linguistic model.

Cursor Horizon therefore captures a broader boundary problem. The transformer ecosystem now supplies loaders, accelerators, sharding, deployment tools, and standardized model classes. A compiler can exploit that infrastructure for software that was never trained.

That does not make transformers preferable to CPUs. It shows that their execution machinery is general enough to host explicitly constructed algorithms. Generality, efficiency, and usefulness remain separate questions.

The project’s strongest contribution is conceptual rather than commercial. It makes the distinction between architecture and training visible. A transformer is a mathematical structure. An LLM is one familiar application built by training that structure on language.

Porter’s model strips away the learning process while preserving familiar inference behavior. It accepts tokens, applies attention and feed-forward layers, selects a next token, and repeats. The loop looks ordinary even when the computation inside it is not.

This property also offers a controlled research environment. Since every weight comes from known graph operations, researchers can trace why a value appears. That differs sharply from interpreting a model whose internal features emerged from training.

However, the Doom checkpoint is far larger than typical interpretability test models. Its scale demonstrates that compiled constructions can reach modern model infrastructure. It also makes inspection and independent reproduction expensive.

The Transformer Executes Doom One Token at a Time

The renderer works by converting Doom’s mutable execution state into an append-only token history that attention can search.

Doom’s renderer walks a BSP tree from near regions to far regions. It projects walls onto screen columns, tracks which areas are already covered, and skips geometry hidden behind nearer surfaces.

Conventional code updates variables and data structures in memory. Autoregressive generation cannot modify earlier tokens. Each new token joins an append-only sequence that remains available to later transformer passes.

The compiled renderer resolves this mismatch by representing each state change as another token. Later operations use attention to find the newest relevant record or combine multiple earlier records.

A recursive tree traversal normally relies on a call stack. The model instead emits breadcrumb records during descent. When it reaches a leaf, attention retrieves the appropriate breadcrumb and determines where execution should resume.

Wall coverage requires another strategy. Doom stores covered horizontal ranges in a mutable structure called solidsegs. Those ranges help it avoid drawing walls already hidden by nearer geometry.

The transformer cannot merge or overwrite earlier range records. It appends every newly covered range. Subsequent operations query the accumulated history to find whether a column is covered and where the covered interval ends.

Floors and ceilings follow a related pattern. The wall pass records their visible boundaries for each screen column. A later pass retrieves those records and emits horizontal drawing runs.

The result is a token sequence that serves several roles. It is an instruction stream, working memory, call stack, state log, and output protocol. Attention provides the lookup mechanism connecting those roles.

Long calculations are also divided across generated tokens. A transformer layer can only perform a bounded amount of sequential work before passing its residual stream onward. Longer dependency chains would require more layers.

The renderer sometimes emits an intermediate result and consumes it during a later decoding step. That strategy spends more tokens to reduce the depth needed for each step.

Wall projection illustrates the tradeoff. The model calculates world angles, converts them into camera-relative angles, and then projects endpoints onto the screen. Intermediate angle tokens separate those dependent stages.

This design keeps the flagship model at 38 layers. It also contributes to the 53,747-token rollout required for one frame. Every extra intermediate handoff adds another full model pass.

The renderer source exposes this pipeline. Modules handle scene inputs, traversal, projection, rasterization, textures, and the output protocol. A separate Python renderer acts as a correctness reference.

The model generates tokens greedily, meaning it selects the highest-scoring next token without sampling. Randomness would be inappropriate because the checkpoint is intended to execute deterministic logic.

The Cursor Horizon keyword becomes useful here as a metaphor for the model’s state boundary. Its output cursor advances across a rendered image, while its attention horizon reaches backward through the execution history.

Yet the mechanism is more literal than poetic. Each new operation can inspect preceding scene facts and generated records. Nothing in the process requires the semantic flexibility associated with conversational models.

The prompt acts as read-only memory. It contains view-independent map facts plus the player’s position and direction. The generated portion acts as append-only working memory for view-dependent calculations.

The host later interprets drawing tokens using Doom’s 256-color palette. It moves a software cursor and paints requested runs. Porter’s minimal demonstration implements that side in 43 lines of Python.

That small host does not prove every rendering calculation sits inside the checkpoint. However, the public source makes the boundary testable. Reviewers can inspect prompt construction, graph modules, output decoding, and the reference comparison.

The project reports pixel-by-pixel checks against its Python renderer. For the flagship frame, it measured complete pixel coverage, 99.9 percent agreement within allowed color options, and 96.7 percent exact agreement.

Those figures differ slightly from the rounded 97 percent used in the original article. The repository’s canonical facts file attributes the latest measurements to an August 9 production render.

The lower-resolution checkpoint reportedly reached complete coverage, complete within-option color agreement, and 93.9 percent exact agreement. Its frame contained 3,964 compared pixels.

These are project-reported measurements. Independent tests have not yet established whether the same results hold across environments, prompts, or scene variations.

The Real Result Is 35 Frames Per Day

The project succeeds as a compiler demonstration precisely because it fails so dramatically as a practical Doom renderer.

The original Doom targeted 35 frames per second on early 1990s hardware. Porter’s full checkpoint produces approximately 0.0004 frames per second on an Nvidia B200 accelerator.

Greedy decoding took 2,383.5 seconds during the reported production run. Model loading and other overhead brought the end-to-end time to 2,528.1 seconds, or 42.1 minutes.

That yields roughly 35 frames per day, assuming continuous operation and similar timing. The comparison became the project’s most memorable joke. It also exposes the core cost of compiling ordinary software into autoregressive inference.

Every emitted token requires another pass through a 21-billion-parameter model. Drawing a frame involves tens of thousands of those passes. The architecture serializes operations that conventional hardware performs through compact instructions and parallel pipelines.

The B200 run reportedly reserved 151 GiB of memory at peak. The checkpoint alone occupies nearly 80 GiB when measured in binary gibibytes. This is not a program most readers can test on a desktop GPU.

The consumer checkpoint reduces resolution to 80 by 50 pixels. It produces a 7,007-token rollout and reportedly decodes in 338.3 seconds on one A100 with 80 GB of memory.

Its 34.09 GB checkpoint can also be distributed across two 32 GB consumer GPUs through automatic device mapping. That version makes replication more attainable, though it remains extravagant for a tiny frame.

Precision creates another limitation. The published models use fp32 weights. Conventional LLM deployments often reduce memory and compute through lower-precision formats or quantization.

Quantization is risky here because numerical errors do not merely soften language probabilities. They can corrupt program state, comparisons, address-like lookups, and cancellation inside the residual stream.

Torwright’s compiler documentation acknowledges that some nonlinear constructions use piecewise-linear approximations. Its tests measure error bounds for individual operations and compare compiled graph nodes with direct evaluation.

Those safeguards provide evidence, not mathematical certainty for every complete execution. Per-operation error bounds do not automatically compose across long chains. The compiler therefore relies on broader graph probes and output comparisons.

The project’s public Reddit discussion raised this concern directly. Porter said he expected careless quantization to produce corrupted output rather than a lower-fidelity image. He also noted that he had not tested that scenario.

Another limitation concerns generality. The checkpoint supports a selected region, fixed resolution, and textures needed around E1M1’s opening area. It does not reproduce the entire renderer across all Doom content.

Sprites remain unimplemented. The weapon and status bar are fixed to the pistol-start state. The model renders a scene, not an interactive game loop with normal gameplay systems.

The project’s map prompt also undergoes preparation before inference. Host-side code crops the level to a fixed world-space region and encodes static facts as tokens. The repository describes that boundary as comparable to loading a level.

Critics can reasonably ask whether this still counts as Doom running inside a transformer. The most defensible answer is narrower: view-dependent rendering logic runs inside a compiled checkpoint for a constrained Doom scene.

It would be inaccurate to claim that Doom itself has become an LLM. The checkpoint has no learned language ability, and it does not implement the complete game. “Transformer-hosted renderer” is the cleaner description.

The Cursor Horizon angle should preserve that distinction. The project expands what a standard model file can represent, but it does not show a competitive new route for graphics computing.

It also has not received broad independent verification. The repository supplies code, weights, prompts, measurements, and comparison tools. Reproducing the flagship result still requires expensive hardware and substantial download capacity.

Community reaction reflects both sides. Developers praised the compiler idea and laughed at its performance. Others asked whether parallel outputs, alternative architectures, or diffusion systems would render frames more efficiently.

Those suggestions miss part of the project’s deliberate constraint. Porter wanted a standard text-generation model that ordinary Hugging Face classes could load. That choice tied the renderer to an inefficient one-token-per-step loop.

Changing the architecture could improve speed while weakening the demonstration. The project is interesting because it accepts the limitations of a vanilla causal transformer and still completes the rendering process.

What Cursor Horizon Should Watch Next

The next test is not another impressive screenshot. It is whether outsiders can reproduce, compress, and generalize the compiled execution.

The first signal is independent reproduction. A third party should run the released low-resolution checkpoint, compare its output against the reference renderer, and publish hardware and software details.

Successful replication would strengthen the claim that a stock checkpoint executes the documented graph. Divergent output would expose sensitivity to transformer versions, numerical kernels, device placement, or floating-point behavior.

The second signal is lower-precision execution. A validated bf16, fp16, or quantized build would reduce the project’s hardware barrier. It would also test whether torchwright can manage residual cancellation and comparisons under reduced precision.

Success would make compiled transformers easier to study and distribute. Failure would clarify that exact numerical behavior remains a major constraint for this programming model.

The third signal is broader scene support. The same checkpoint should render multiple positions, directions, and compatible map regions without recompilation. Published comparisons should cover more than the flagship E1M1 view.

That test would separate a general renderer implementation from a highly optimized demonstration path. It would also show how the append-only state mechanism behaves as geometry and token counts vary.

Parallelism remains an important longer-term question. Porter’s current design uses one generated token for each bounded computation step. A system that emitted several safe operations per pass might reduce the enormous decoding burden.

However, that change must preserve the project’s central claim. Moving geometry calculations or visibility decisions into host code would improve performance by relocating the renderer, not by improving compiled transformer execution.

Future torchwright examples may prove more informative than faster Doom frames. Deterministic parsers, protocol validators, calculators, and transparent algorithmic modules fit the compiler’s strengths better than real-time graphics.

Compiled logic might also be combined with trained components. A learned model could handle ambiguous language while a constructed subnetwork enforces a calculation or protocol. That possibility remains speculative and technically difficult.

Security researchers should watch standard checkpoint formats as well. Existing model scanners often focus on serialized code, unsafe loading, or suspicious files. Directly constructed weights introduce behavior without shipping conventional executable code.

That does not make torchwright malicious. Its source and intent are unusually open. The broader lesson is that “no custom code” does not mean “no programmed behavior.”

Developers should also resist treating parameter count as an intelligence score. This checkpoint has 21 billion parameters because its compiler maps a renderer into a cumbersome architecture. Size alone reveals little about learned knowledge or useful reasoning.

For Cursor Horizon readers, the practical takeaway is a sharper mental model of transformers. Training is one way to set their weights. Compilation is another, even when the result is wildly inefficient.

The project is most valuable as an executable argument. It shows that familiar model infrastructure can carry deterministic programs, not only statistical memories. It also shows why conventional computers remain exceptionally good at conventional computation.

Try reading the execution trace, inspecting the compiler graph, or reproducing the smaller checkpoint. Then ask the question that matters beyond Doom: which algorithms gain something from transformer-native execution, and which merely become expensive curiosities?