Gran Turismo 7 (PPSA01317)

[gjonn]

Current status (updated 2026-10-13)

Content version tested: 01.710.000

AnyPS5 commit: a local integration branch, not stock main: main at 6741e90 plus local driver and recompiler work. Most of it is not upstreamed (see the pull requests below).

Code: the work-in-progress branch is shared on my fork at gjonn/AnyPS5 · ppsa01317-music-rally-wip. It is one run-tree snapshot, not split into upstreamable changes.

System tested: Windows 11 Pro (build 26220), NVIDIA GeForce RTX 5090 Laptop GPU (driver 616.92), MinGW GCC 15.2, Release build.

Furthest point: In race (Music Rally)

What is shown

• Title screen and World Map: render with textures, at about 10–14 FPS. The World Map's terrain, forests and sunset lighting now match the console.
• Garage: loads about 25 s after you select it. The car view renders lit, with paint, wheels and tessellated tyres, in 3 of 3 test boots. The menus (Car Settings, Tuning Parts, Gifts, Car Collection) render with textures.
• Used Car dealership: about 30 FPS with a larger host-import budget. Car thumbnails stay grey offline, because the game downloads them.
• Music Rally: title screen > Music Rally > first song > Start loads the race. It runs with the HUD and Auto Drive until the song ends on "TRY AGAIN".
  • About 0.6–1.2 FPS in the race with the emulator's profiling on (it swings from run to run; see Performance below), and about 1 FPS on the pre-race screen.
  • Start only responds once its labels have loaded, about 30 s after the pre-race screen appears. At this frame rate it needs a press held for about 3 s.
• Saves: written correctly.
• Network: blocked; the title falls back cleanly.
• Audio: not checked (it was muted).
• Input: keyboard input works in menus.

Current blockers

• Stability: about 1 in 3 Music Rally loads fail.
  • Some hang while loading, sometimes after the game's own BVH assertion (refit_leaf_count == refit_leaf_index).
  • Others lose the Vulkan device about 30 s into the race, right after the game's compute shaders read garbage buffer descriptors.
  • Both point at CPU-written data that the GPU side does not see, or that gets overwritten.
• Track minimap: shows garbage on the pre-race screen and in the race HUD. The UI samples a scratch-memory image that nothing in the emulator ever draws the map into. The cause is not found yet.
• Performance: the game's main thread mostly waits on GPU completion, and the GPU itself is busy only a small part of each frame. The limit is the emulator's draw threads. Guest-memory write tracking used to be the largest cost; it is now small (2026-10-13 update). The largest cost left is rebuilding the table of GPU-visible guest memory, and every cached draw setup with it, whenever the game frees memory or changes page protection early in a race. That is why race speed swings between about 0.6 and 1.2 FPS.
• Green/cyan flyover tint (fixed with a workaround): blended packed 11:11:10 render targets were rendered in a different bit layout than the one the game reads them back with. That turned foliage on the flyover camera into Inf/NaN. Those draws are now kept in the console's packed layout without the blend; a blend-preserving version is still in progress. This is probably also why the Garage's dynamic lighting probe used to fade to black.
• Local changes not yet upstreamed (selection):
  • MSAA draws rendered single-sampled, plus the CB resolve pass.
  • Quad-patch tessellation (a port of the triangle-patch tessellation from feat(shader): implement triangle-patch tessellation #1491, extended).
  • Null binding for descriptors behind untaken branches.

Open pull requests

• fix(libkernel): return errors from pread instead of aborting #4719: stops the game aborting when a file read fails (seen on first boot, reading its save folder).
• fix(shader): place hull input components by their offset in the control-point slot #4723: fixes tessellated surfaces reading the wrong part of their control points (part of the car body and tyres).
• fix(shader): load the PERSP_SAMPLE and LINEAR_SAMPLE I/J pairs #4797: loads the per-sample interpolation inputs that about 2,900 of the game's pixel shaders read. Without it the car, interior, terrain and World Map forests render flat or are missing.
• fix(agc): store small pending storage results at each flip #4841: stores small pending GPU results at each flip, so the game's CPU auto-exposure reads current values. Without it the Garage goes dark and interiors blow out to white.
• perf(agc): resolve static shader ABIs on the background pool #2589: compiles the shaders the game asks for while it loads the menu in the background, instead of one after another on its loading thread, so the menu shows up sooner.
• perf(agc): read DCC keys behind a pattern fill kernel's fast clear without a wait #5497: lets the game's per-frame fast clears of its render targets be recognised without stopping to wait for the GPU, which makes races noticeably smoother (about +31% FPS in the race test scene).
• Merged: feat(shader): read hull inputs at a control-point index computed from data #4727 (tessellated surfaces look up their control points from data, which this title's car body shaders do).
• Review note on perf(agc): pipeline queue-0 draw commits behind the packet worker #1201 (pipelined draws): a draw with a null storage image in its written set throws; fix suggested there.

How it was run

• Conversion: relinked with the relinker's --windows --to-intel.
• Environment: APS5_NET_OFFLINE=1. Without it, network retries add minutes to boot. The test runs also use the branch's opt-in speed settings (profiling/best-run.ps1 on the fork branch).

[gjonn]

Update: Garage car and World Map now render properly

Big visual jump today on the same local branch (still not stock main, still no races tried).

Garage car view. The car used to show as a flat grey silhouette or go completely black a few seconds after entering the Garage. Three things were behind it:

• The car body and tyres use quad-patch tessellation, which now works locally.
• The game sets its exposure by reading back a small brightness measurement from the GPU. That readback never reached the game, so exposure drifted to zero and everything faded to black. It now does.
• Draw speculation (one of the local speed-up options) was dropping the tessellated car draws, so it's off for now.

Car interior. Interior shots were blown out to white by the same exposure problem; they now look normal.

World Map: terrain, forests and lighting. Many of the game's pixel shaders were receiving blank interpolation data, so every triangle was shaded with a single colour: faceted terrain, flat mountains, faceted car paint, and alpha-tested foliage disappearing entirely (no forests). With that fixed, the World Map now matches a PS5 capture: smooth terrain, full forests, textured mountains and the sunset lighting.

Also:

• An occasional crash in game code while loading the Garage is avoided with a local setting; it comes from how Windows handles a write-tracking fault next to the game's stack.
• Menus run at about 12–14 FPS, the World Map at about 12.
• The first visit to a screen after an update stutters and pops in while shaders compile; later visits are smooth.

Next: a pull request for the interpolation fix (upstream main has the same issue), background shader pre-compiling to cut the pop-in, and performance.

[gjonn]

Update: Music Rally reaches a race and runs to the end

First race on the same local branch (still not stock main). Path: title screen > Music Rally > first song > Start.

What got it there:

• Starting the race called sceVideoOutVrrPegToFixedRate, which wasn't implemented locally, so the game aborted. It's now an accepted no-op (there's no variable refresh on the host). Main already has this.
• Picking the wrong title-screen icon opened the web browser dialog, whose Terminate threw and killed the game. Fixed locally; fix(libSceWebBrowserDialog): permit termination from finished state in sceWebBrowserDialogTerminate #4509 already covers it upstream.
• On the pre-race screen, Start only responds once its labels have loaded. At this frame rate the button needs a 1–2 s hold.

Result: the race loads with HUD and Auto Drive, the song plays out, and it ends on the "TRY AGAIN" screen. Offline networking stays on throughout.

Still wrong:

• Speed: about 2 FPS in the race. Each draw costs the emulator about 200 µs of CPU, with about 1,000 draws a frame. The cache of prepared draws that keeps the menus faster never hits in the race. That's being looked at now.
• Track map: the pre-race map and the HUD minimap (top right) are a block of garbage tiles.
• Green tint and cyan foliage: an earlier run showed these during the intro flyover (left image). They didn't come back in the latest run, but no fix targeted them, so they may return.
• Rare problems: one GPU device loss in 8 race loads, and a game crash when the intro was skipped with ENTER.

[gjonn]

Update: faster menu loading (PR #2589 reworked)

Not a visual change this time, so no screenshots.

While the menu loads, the game asks for several hundred shaders in a row from its loading thread. The emulator used to compile each one right there, one after another, so nothing new appeared on screen for a while. #2589 hands those compiles to the background shader threads, so the loading thread can carry on.

Earlier measurements on the same machine, from my local branch: the stretch with no new frames during menu load went from about 20 s to about 3 s, and the menu reached its normal frame rate roughly 10 s sooner.

Today I reworked the PR after review:

• If one of those shaders fails to compile, the game is no longer stopped at that point. The failure is logged, and only a draw that actually uses that shader is affected.
• A Linux test run shows the same speed-up (about 4.4 s down to 1.9 s in a synthetic test that mimics this burst).

The PR is waiting for another review.

[gjonn]

Update: race frame rate roughly doubled (write tracking)

Not a visual change this time, so no screenshots.

Before the GPU uses guest memory, the emulator asks Windows which pages the game's CPU has written since it last checked (GetWriteWatch). In the Music Rally race this was the biggest CPU cost of the threads that prepare and record draws: several seconds of every 10 seconds.

What I found today (local branch, still not stock main):

• Each GetWriteWatch call cost about 8 µs in game, however little memory it checked. The emulator gave Windows a 512 KiB result buffer on every call, and the call's cost grows with that buffer: about 0.3 µs with a buffer sized to the region, about 7 µs with the full one. Sizing the buffer to the region brings the calls under 1 µs. perf(libc): size each write-watch query to the region it covers #4875 (not mine) makes the same change on main, and I added these measurements there.
• Several threads kept re-checking the same large textures and render targets within the same short window. They now share each other's results.
• Along the way I fixed a few local-only races where two threads checking the same memory at once could lose a CPU write.

Result in the race (same song, the emulator's profiling on):

	before	after
Time spent on these checks per 10 s, queue thread	2.5–3.6 s	0.1–0.4 s
Same, draw preparation threads (all six)	2.2–4.5 s	0.4–1.0 s
Race frame rate	about 0.6 FPS	about 0.6–1.2 FPS

Why it still swings between 0.6 and 1.2 FPS. When the game frees memory or changes page protection early in the race (one to three times a second), the emulator rebuilds its table of GPU-visible guest memory, and every cached draw setup has to be rebuilt with it. In the slow runs that costs the draw recording thread 5–7 s of every 10 s. That's what I'm working on next.

[gjonn]

Update: race frame rate up again, and the menu is near 15 FPS

Same local branch as before (still not stock main). Today was about finding where the emulator waits instead of works.

What the measurements showed. In the Music Rally race the GPU was idle for a large part of every frame, and the emulator's own threads were mostly waiting too. Almost all GPU work goes through one global lock, which was held about 88% of the time. The thread that records the game's draws often waited for the GPU while holding it, so every other queue waited behind it.

What changed (local branch):

• Fairer lock hand-off. The draw thread used to grab the lock again before a waiting compute queue could wake up and take it. A thread that releases the lock while others wait now lets one of them in first.
• No GPU round trip for values the emulator already knows. When the game writes a small value with a GPU command and a later shader setup reads it back, the emulator now takes the value from its own record instead of waiting for the GPU to finish. A checking mode compared every such value against the real one and found no mismatches.
• Async compute no longer held behind graphics. Ordering submissions from another queue after earlier graphics work sometimes deadlocked this game for over 20 seconds. That ordering is turned off locally while a proper fix is worked out.
• Render-target fast clears. The game clears the compression metadata of some render targets every frame with a small compute kernel. The emulator didn't recognise it, so the next draw waited for the GPU to find out what had been written. It's now recognised. Upstream PR: perf(agc): read DCC keys behind a pattern fill kernel's fast clear without a wait #5497.
• Draw preparation moved off the critical thread. An existing option checks whether a draw can reuse earlier work on a helper thread, instead of on the thread that holds the lock. It was never enabled for the race; it's now on.
• A per-draw cost removed. A check added for the race (whether a shader writes the render layer) scanned the whole vertex shader on every draw. The answer is now cached per shader.

Result, same race and song, profiling on, car standing at the start (so runs compare):

	morning	evening
Heavy part of the race	about 1.2 FPS	about 2.3 FPS
GPU waits while holding the lock, per 10 s	3.1–3.5 s	about 0.2 s

Playing it, profiling off:

Scene	FPS
Main map	about 15
Music Rally song list	60
Track flyover before the race	4–5
Race while driving	about 1.8

Still wrong:

• Driving is GPU-bound now. While actually driving, the game draws about four times as many objects per frame as with the car standing still, and the GPU is busy most of the frame. Next: making the game's ray-tracing structure updates cheaper on the GPU, and letting them run alongside the graphics work instead of before it.
• Track map on the pre-race screen and the HUD minimap are still garbage tiles.
• Occasional crashes during boot, about 30 s in, at a known spot in mesh streaming. A restart gets past it.
• Rare Vulkan device loss in long sessions.

[gjonn]

Update: garage ~17 FPS with the car fully painted, HDR output, and what limits the race

Same local branch as before (not stock main). This session continued from the previous update.

Frame rate across the game (profiling off unless noted):

Scene	Before this week	Now
Garage / car viewer	about 14.5, car flat or missing with some settings	16–18, car fully painted
Main map	about 6.5	about 13–15
Music Rally song list	–	60
Track flyover before the race	–	4–5
Race, heavy part, car standing (profiling on)	about 1.2	about 2.3
Race while driving	–	about 1.8

Gran.Turismo.7._.FPS_.17.65.11799.2026-10-14.01-19-45.mp4

The garage gain mostly comes from the race work in the previous update: fairer GPU lock hand-off, draw preparation moved off the locked thread, a per-draw shader scan cached, fast-clear kernels recognised, and a warm shader cache. With those on, the car keeps its paint and detail.

New: HDR output.

• The emulator checks whether the monitor showing the game window is in Windows HDR mode, and whether the GPU offers an HDR10 swapchain there.
• Only then does the game see an HDR display, with the monitor's real brightness range. The game switches itself to 10-bit HDR10 output, which is passed straight through to an HDR10 swapchain.
• Turning Windows HDR off or on mid-game is detected within a second. When the game keeps sending HDR frames to an SDR display, they are now tone-mapped to SDR on the GPU instead of looking washed out.
• Upstream PRs (generic, not title-specific):
  • feat(agc): present BT.2100 PQ display buffers on an SDR output #5696: present BT.2100 PQ display buffers on an SDR output. Titles that register PQ display buffers no longer stop with "unsupported display pixel format".
  • feat(videoout): present PQ display buffers through an HDR10 swapchain #5697: present PQ display buffers through an HDR10 swapchain, with host HDR detection. Depends on feat(agc): present BT.2100 PQ display buffers on an SDR output #5696.

What limits the race. One async compute queue rebuilds the ray-tracing structures every frame: about 1,000 small dispatches per frame, each costing about 350 µs of emulator CPU time.

• As an experiment, skipping that queue's work entirely took the race while driving from about 1.8 to about 5 FPS. So that burst is roughly two thirds of the frame.
• Skipping it isn't a fix, since the ray-traced effects need it, but it shows where the work has to go.

Things tried against it this session, measured in the race:

• A separate recorder for that queue, then a second Vulkan queue so the GPU could overlap it with graphics. Both built and tested, both slower (−22% and −30%). The queue's work alternates with work that has to stay on the main queue, so every switch adds a submit and a wait, and the two queues ended up taking turns. Shelved.
• Reusing earlier shader-input captures when only per-frame pointers moved. The game hands out its per-draw data from a ring that moves every frame, so exact cache keys never repeat (99% misses at the map). The new reuse is exact (0 mismatches in about 300,000 verified draws) but not yet cheaper than the capture it replaces, so it stays off for now.

Main map profile, for anyone looking at the same scene:

• GPU: 41–55 ms per frame.
  • 4K passes about 15 ms.
  • Storage images written back to guest memory and re-uploaded each frame: about 10 ms.
  • Draws and dispatches: the rest.
• CPU: about 1,700 draws per frame at about 27 µs each on two serial threads.
• About half the storage write-back is two 240×135×127 volumes, written back because a compute pass binds overlapping memory as a writable buffer.

Other findings:

• 120 Hz mode. The game offers it once the emulator reports a 120 Hz display. It renders through a multisampled-depth path that isn't supported yet: the scene draws, but the final upscale doesn't run. Shelved for now; upstream feat(agc): multisampled color and depth targets with CB resolves #419, feat(agc): sample a multisampled color target through its 2D MSAA texture #4820 and feat(agc): sample native multisampled depth attachments #5496 cover exact multisampling.
• Memory. About 49 GB committed at the map once all shaders are warm. Ported perf(shader): keep only evaluable branch conditions in resource plans #5181 (compact resource plans). In this branch it trims plan memory by about 25%, because the branch lacks the control-flow planning the PR mostly targets.
• Stability.
  • Occasional Vulkan device loss right at race start (2 of about 8 starts). Fault reporting is on for the next one.
  • The usual random boot crash in mesh streaming.
  • A crash on exit that keeps the Vulkan pipeline cache from saving.

Still wrong:

• Track map tiles and the HUD minimap are garbage.
• The race is CPU-bound in that compute burst, and GPU-bound while driving.

[robykeee]

🚀 sei un grande