Matrix-Game 4.0 Brings Neural Game Rendering to RTX 5080 and 5070 Ti

Matrix-Game 4.0 now has optimized inference paths for the NVIDIA RTX 5080 and RTX 5070 Ti. Skywork added them on October 16, one day after its RTX 5090 runtime. The project makes an interesting division of work: a conventional engine runs the game, while a video model generates its finished appearance.

The current release documentation reports up to 67 frames per second on the RTX 5080 and 58 on the RTX 5070 Ti, using fixed prompts and SageAttention at 864 by 480 resolution. Those are steady-state model-throughput figures that exclude video input and output. They should not be presented as guaranteed gameplay frame rates.

The engine keeps the game consistent

The project's architecture gives the engine responsibility for world state and interaction rules. It produces a simple low-poly view, which the neural renderer uses as visual guidance. A coding agent can turn a player's request into changes to the rules and write prompts using the current engine state.

That arrangement gives developers a concrete place to inspect a gameplay problem. If a collision fails, the engine's rules are available to examine. If a wall changes appearance while the player moves, the rendering path needs attention. Keeping those responsibilities separate should make a prototype easier to debug than a system in which the same generated frames must carry every rule and object state.

For a developer experimenting with a new game mechanic, this suggests a useful sequence: establish that the mechanic works in the simple engine view, then evaluate how well the generated graphics preserve it. Visual quality and gameplay correctness need their own checks.

What the RTX 5090 numbers measure

The team's technical report describes a renderer built on Wan2.2 5B, generating four-frame chunks with one or two denoising steps. Its RTX 5090 demonstration runs at 480p and 60 FPS, with a reported 112 milliseconds from a keypress to the first frame showing a response.

The report separately lists approximately 83 FPS for one-step generation and 57 FPS for two steps, with about 18.2 GiB of peak GPU memory. These are developer measurements. The 83 FPS figure describes model generation throughput; the 60 FPS figure describes the demonstrated game session. Comparing either number with another system requires checking whether that system also includes rendering, streaming and display time.

The newer 5080 and 5070 Ti paths add another constraint: fixed prompts only. The 5080 setup encodes the prompt and releases the text encoder before loading the renderer to fit its 16 GB memory budget. That is a useful deployment tradeoff, but it limits the text conditioning available during play.

What developers can download

The Hugging Face release contains scene-specific weights and assets for Medieval Castle, Ancient Egypt and City Racing. Each checkpoint has about five billion parameters. The project includes inference code, but its training code and training data are not part of the release.

The scene weights and project assets use Apache 2.0, while shared components and some racing audio retain their own license and attribution requirements. Teams planning to redistribute a demo should keep those notices with the relevant files. There is no hosted API price attached to this downloadable release; running it still requires suitable hardware and setup.

The installation guide uses Python 3.12 with NVIDIA CUDA and documents Ubuntu dependencies. Game capture also needs working hardware graphics support. The standalone game can run on macOS, but the neural model has no tested Apple MPS path. A supported browser on another computer can display the stream; the inference workload still runs on the configured host.

These models are specialized to the supplied scenes and camera profiles. The model card warns about appearance drift and geometry errors with unfamiliar geometry, fast camera movement, occlusion and long sessions. A successful example in one scene therefore gives limited evidence about a completely different game.

A useful prototype needs a playable test

The first evaluation should be a small, repeatable route through one supported scene. Include a quick turn and a return to an object that left the screen. Compare the generated image with the engine view and measure the response a player actually sees. A throughput counter alone cannot reveal whether an important visual detail remains stable.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product launches and engineering work into clear stories that developers can understand and share.

Book a 30-minute call