v0.1.52: Vulkan renderer: new shaders are handed over faster on scene changes

What's new

15 Nov 2026

🐧 Linux and the Vulkan renderer: new shaders are handed over a little faster on scene changes

• Since v0.1.49 new shaders build in the background. A scene change brings a few hundred at once, and
  the renderer still did two slow searches for each one before handing it over: one through every
  shader made so far, for a free place in its table, and one through the shader's text sixteen times
  over, for cube-map textures. Each is now a single quick step. On this PC that saves about 18
  microseconds per shader, or a few milliseconds on a big scene change; slower processors save more.
  The Android port's measurements in the Android emulator pointed at it.
• When the renderer shuts down, shaders still waiting in the queue are dropped instead of built first.
  GT5 doesn't run that code when it quits, so players won't see a difference; the runtime's own test
  program does.
• Checked: the new cube-map search gives the same answers as the old one on 200,000 generated
  shader texts and on GT5's own; the Windows Vulkan test copy builds and runs, with shaders built in
  the background.

14 Nov 2026

📷 Photo Mode: Auto Focus no longer breaks the viewfinder, and photos after the first are exposed right
(brocolison and Arpadiam on Discord: a ghosted viewfinder after Auto Focus, later photos too dark)

• Auto Focus: GT5 measures the distance at the focus point by copying a small patch of the scene's
  depth back to the game for a few frames, and it reads that copy straight away. The port delivered it a
  frame or more late whenever the renderer fell behind (in the viewfinder's first seconds, or with a busy
  graphics card), so the camera focused on whatever that memory held before. Everything came out far
  out of focus, and the viewfinder showed a fan of overlapping copies of the car and the scenery. Copies
  the game asks for only now and then now arrive before it looks; the auto-exposure copy it makes every
  frame still arrives a little late, as the game expects.
• Exposure after a photo (1080p): the camera meters a tiny version of the viewfinder image every frame.
  A photo leaves a large working image in video memory that overlaps where that meter is drawn, and
  after the first photo the meter's last two steps read that old image instead of the fresh one. So the
  camera metered a frozen picture and drove the viewfinder, and every later photo, much too bright or
  too dark. The meter now reads its own fresh image. 720p wasn't affected.
• Checked on this PC with the European disc in Photo Travel (Kyoto - Gion), at 720p and 1080p: Auto
  Focus right after the viewfinder opens, and with the renderer slowed down on purpose, now gives a
  clean, sharp preview, where it showed overlapping copies before. At 1080p the viewfinder keeps its
  brightness after a photo (before, it climbed to nearly three times as bright within 40 seconds), and
  three photos in a row came out equally bright. Replay Photo Mode wasn't tried.

🐧 Linux: the game window opens on KDE Plasma under Wayland
(#32, lotushomerun: the game ran, with sound,
but no window ever appeared; Arch Linux, Radeon RX 5500 XT)

• To open its window the Vulkan renderer asks the graphics driver which picture formats the window
  can take. It made room for 64 answers. KDE Plasma on Wayland, with Mesa's driver, pairs every format
  with several colour spaces (for HDR) and gives well over 64. The driver then fills the 64 and says
  "there are more", which is a normal answer, but the renderer took it for an error, gave up on the
  window and carried on without one. It now takes all of them, and picks the ordinary (non-HDR) colour
  space when a format comes in several.
• If the window still can't be opened, play.err now says so in plain words, and that Ctrl+C in the
  terminal stops the game. On Wayland, SDL_VIDEODRIVER=x11 bash GT5/play.sh (through XWayland) is a
  way around it.
• Checked: with the same renderer on Windows the window still opens as before. There's no Plasma
  Wayland session here, so the case with more than 64 formats itself is untested.

🐧 Linux: no more freezes when something new comes on screen, and road markings sit on the road
(#20, melroy89: single frames of 0.3 to 0.7 s,
once 1.7 s, in races and licence tests on a Radeon RX 7900 XTX)

• The Vulkan renderer (the Linux build's) made every shader the game hadn't used before on the spot,
  while the game waited: translated into Vulkan's form, then compiled by the graphics driver. A new
  car, track or menu asks for 100 to 300 of them at once, so the picture stopped for up to seconds.
  Now they're built on spare CPU cores while the game keeps running (PS3RECOMP_VK_ASYNC_SHADERS, on
  in play.sh). The cost: something can be missing for its first few frames on screen.
  export PS3RECOMP_VK_ASYNC_SHADERS=0 in GT5/settings.sh goes back to the old way.
• Checked on this PC with the Windows build of the same Vulkan renderer (NVIDIA card), from the title
  screen to the B-1 licence test with no shaders cached yet. Before: 16 frames of 250 ms or more, 10 s
  frozen in all, the worst 2.2 s (and 5.9 s with the driver's own cache empty too). Now: none of
  250 ms or more, the worst 210 ms, and the pictures were complete once the shaders were built.
• GT5 moves road markings, skid marks and its shadow maps a tiny step towards or away from the camera
  (the PS3's polygon offset), so they don't flicker against the surface under them. The Vulkan
  renderer ignored that and now applies it (PS3RECOMP_VK_DEPTH_BIAS=0 turns it off). Whether it is
  also what made the car bodies flicker on the 7900 XTX isn't known yet: that didn't show here.
• play.err now has a [slow-frame] line for every frame of 250 ms or more, as the Windows build
  does, splitting it into new shaders (translation and driver), textures, waiting for the GPU and the
  rest (PS3RECOMP_VK_HITCH_MS sets the limit, 0 turns it off). A texture the renderer can't create
  is now logged too.
• Not seen on this PC yet (NVIDIA, European disc): the flickering car bodies, the see-through road in
  the B-2 intro, the missing textures in a braking test and the dark title-screen scene. With
  PS3_SKIP_INTRO=1 (play.sh's default) the scene behind the title is GT5's own replay of a race at
  dusk or at night, drawn live, and it is just as dark in the Windows build. Questions for those are
  on #20.

📷 Photo Mode pictures have their real colours again: no more yellow-green tint or coloured ghost copies
(brocolison and Arpadiam on Discord: tinted, ghosted and very dark photos)

• GT5 builds a photo from about 50 slightly shifted renders, averaged one after another into a
  high-precision image (that gives photos their smooth edges and depth of field). Each render is blended
  in with a weight the game sets as a constant blend colour. For this kind of image the PS3 keeps that
  constant in two registers, and the port read its second half (blue and alpha) from the wrong one, so
  blue was blended with a weight of 0 and kept whatever the image held before: black, which gave the
  yellow-green tint, or part of an older render, which gave the coloured ghost copies. The weight was
  also taken per colour channel where the PS3 uses the alpha value for all of them.
• Checked on this PC with the European disc in Photo Travel (Kyoto - Gion): before, the saved photo had
  no blue at all (pink blossom came out yellow, the night sky green); now its colours match the
  viewfinder, and a 3840 x 2160 photo (16:9, x2) has no ghost copies.
• Not fixed yet: after a photo is taken, the viewfinder and the next photos can come out much darker.
  That happened before this change too and is being looked into. Auto Focus did not show ghost copies
  on this PC.

🛡️ The game starts on PCs where Windows forces Control Flow Guard on every program
(#31, Fantomas3228: the game closed a second
after Play, with a log that just stopped)

• Windows Security's Exploit protection can turn Control Flow Guard (CFG) on for all programs. With it
  on, Windows checks every longjmp the program makes, and the SPU code's fast jumps (which skip
  unwinding, for speed) failed that check: Windows ended the game on the spot (fast fail, exit code
  0xC0000409) as the first SPU job ran.
• Now the game asks Windows whether CFG is on for it, and if so makes those jumps the standard way.
  play.err then says [spu] Control Flow Guard is on for this process. PCs without CFG forced on keep
  the faster jumps.
• Checked on this PC by starting the game with CFG switched on for that one run: before, it closed
  after 2 s with 0xC0000409 at the same line as in #31; now it runs normally. No Windows setting needs
  changing any more (Fantomas3228's workaround, Set-ProcessMitigation -Name gt5.exe -Disable CFG,
  can stay or be undone).

📺 Options > Display no longer crashes the game (reported by Arpadiam on Discord: the Resolution
list was empty, and leaving the screen with OK closed the game)

• The port described the TV's video modes to the game with a block of data missing (the TV's colour
  information comes before the list of modes), so GT5 read its list 20 bytes too early, found a mode
  with resolution 0, showed an empty Resolution list and failed when the screen was confirmed.
• The list now has the layout the PS3 uses, with one mode: the one the port draws (1080p or 720p, as
  set in the launcher), at 59.94/60 Hz, the way RPCS3 reports it.
• Checked on this PC with the European disc: Display Settings shows 1920 x 1080 59.94p, and OK
  returns to Options with the game still running. The 2.11 update's Resolution row is not tested here.

☀️ Races at 1080p get the right brightness: no more blown-out white or too-dark tracks (reported by
Keduboneur78 on...

v0.1.51: Photo Mode: Auto Focus no longer ghosts the viewfinder; exposure after a photo stays right at 1080p

What's new

14 Nov 2026

📷 Photo Mode: Auto Focus no longer breaks the viewfinder, and photos after the first are exposed right
(brocolison and Arpadiam on Discord: a ghosted viewfinder after Auto Focus, later photos too dark)

• Auto Focus: GT5 measures the distance at the focus point by copying a small patch of the scene's
  depth back to the game for a few frames, and it reads that copy straight away. The port delivered it a
  frame or more late whenever the renderer fell behind (in the viewfinder's first seconds, or with a busy
  graphics card), so the camera focused on whatever that memory held before. Everything came out far
  out of focus, and the viewfinder showed a fan of overlapping copies of the car and the scenery. Copies
  the game asks for only now and then now arrive before it looks; the auto-exposure copy it makes every
  frame still arrives a little late, as the game expects.
• Exposure after a photo (1080p): the camera meters a tiny version of the viewfinder image every frame.
  A photo leaves a large working image in video memory that overlaps where that meter is drawn, and
  after the first photo the meter's last two steps read that old image instead of the fresh one. So the
  camera metered a frozen picture and drove the viewfinder, and every later photo, much too bright or
  too dark. The meter now reads its own fresh image. 720p wasn't affected.
• Checked on this PC with the European disc in Photo Travel (Kyoto - Gion), at 720p and 1080p: Auto
  Focus right after the viewfinder opens, and with the renderer slowed down on purpose, now gives a
  clean, sharp preview, where it showed overlapping copies before. At 1080p the viewfinder keeps its
  brightness after a photo (before, it climbed to nearly three times as bright within 40 seconds), and
  three photos in a row came out equally bright. Replay Photo Mode wasn't tried.

🐧 Linux: the game window opens on KDE Plasma under Wayland
(#32, lotushomerun: the game ran, with sound,
but no window ever appeared; Arch Linux, Radeon RX 5500 XT)

• To open its window the Vulkan renderer asks the graphics driver which picture formats the window
  can take. It made room for 64 answers. KDE Plasma on Wayland, with Mesa's driver, pairs every format
  with several colour spaces (for HDR) and gives well over 64. The driver then fills the 64 and says
  "there are more", which is a normal answer, but the renderer took it for an error, gave up on the
  window and carried on without one. It now takes all of them, and picks the ordinary (non-HDR) colour
  space when a format comes in several.
• If the window still can't be opened, play.err now says so in plain words, and that Ctrl+C in the
  terminal stops the game. On Wayland, SDL_VIDEODRIVER=x11 bash GT5/play.sh (through XWayland) is a
  way around it.
• Checked: with the same renderer on Windows the window still opens as before. There's no Plasma
  Wayland session here, so the case with more than 64 formats itself is untested.

🐧 Linux: no more freezes when something new comes on screen, and road markings sit on the road
(#20, melroy89: single frames of 0.3 to 0.7 s,
once 1.7 s, in races and licence tests on a Radeon RX 7900 XTX)

• The Vulkan renderer (the Linux build's) made every shader the game hadn't used before on the spot,
  while the game waited: translated into Vulkan's form, then compiled by the graphics driver. A new
  car, track or menu asks for 100 to 300 of them at once, so the picture stopped for up to seconds.
  Now they're built on spare CPU cores while the game keeps running (PS3RECOMP_VK_ASYNC_SHADERS, on
  in play.sh). The cost: something can be missing for its first few frames on screen.
  export PS3RECOMP_VK_ASYNC_SHADERS=0 in GT5/settings.sh goes back to the old way.
• Checked on this PC with the Windows build of the same Vulkan renderer (NVIDIA card), from the title
  screen to the B-1 licence test with no shaders cached yet. Before: 16 frames of 250 ms or more, 10 s
  frozen in all, the worst 2.2 s (and 5.9 s with the driver's own cache empty too). Now: none of
  250 ms or more, the worst 210 ms, and the pictures were complete once the shaders were built.
• GT5 moves road markings, skid marks and its shadow maps a tiny step towards or away from the camera
  (the PS3's polygon offset), so they don't flicker against the surface under them. The Vulkan
  renderer ignored that and now applies it (PS3RECOMP_VK_DEPTH_BIAS=0 turns it off). Whether it is
  also what made the car bodies flicker on the 7900 XTX isn't known yet: that didn't show here.
• play.err now has a [slow-frame] line for every frame of 250 ms or more, as the Windows build
  does, splitting it into new shaders (translation and driver), textures, waiting for the GPU and the
  rest (PS3RECOMP_VK_HITCH_MS sets the limit, 0 turns it off). A texture the renderer can't create
  is now logged too.
• Not seen on this PC yet (NVIDIA, European disc): the flickering car bodies, the see-through road in
  the B-2 intro, the missing textures in a braking test and the dark title-screen scene. With
  PS3_SKIP_INTRO=1 (play.sh's default) the scene behind the title is GT5's own replay of a race at
  dusk or at night, drawn live, and it is just as dark in the Windows build. Questions for those are
  on #20.

📷 Photo Mode pictures have their real colours again: no more yellow-green tint or coloured ghost copies
(brocolison and Arpadiam on Discord: tinted, ghosted and very dark photos)

• GT5 builds a photo from about 50 slightly shifted renders, averaged one after another into a
  high-precision image (that gives photos their smooth edges and depth of field). Each render is blended
  in with a weight the game sets as a constant blend colour. For this kind of image the PS3 keeps that
  constant in two registers, and the port read its second half (blue and alpha) from the wrong one, so
  blue was blended with a weight of 0 and kept whatever the image held before: black, which gave the
  yellow-green tint, or part of an older render, which gave the coloured ghost copies. The weight was
  also taken per colour channel where the PS3 uses the alpha value for all of them.
• Checked on this PC with the European disc in Photo Travel (Kyoto - Gion): before, the saved photo had
  no blue at all (pink blossom came out yellow, the night sky green); now its colours match the
  viewfinder, and a 3840 x 2160 photo (16:9, x2) has no ghost copies.
• Not fixed yet: after a photo is taken, the viewfinder and the next photos can come out much darker.
  That happened before this change too and is being looked into. Auto Focus did not show ghost copies
  on this PC.

🛡️ The game starts on PCs where Windows forces Control Flow Guard on every program
(#31, Fantomas3228: the game closed a second
after Play, with a log that just stopped)

• Windows Security's Exploit protection can turn Control Flow Guard (CFG) on for all programs. With it
  on, Windows checks every longjmp the program makes, and the SPU code's fast jumps (which skip
  unwinding, for speed) failed that check: Windows ended the game on the spot (fast fail, exit code
  0xC0000409) as the first SPU job ran.
• Now the game asks Windows whether CFG is on for it, and if so makes those jumps the standard way.
  play.err then says [spu] Control Flow Guard is on for this process. PCs without CFG forced on keep
  the faster jumps.
• Checked on this PC by starting the game with CFG switched on for that one run: before, it closed
  after 2 s with 0xC0000409 at the same line as in #31; now it runs normally. No Windows setting needs
  changing any more (Fantomas3228's workaround, Set-ProcessMitigation -Name gt5.exe -Disable CFG,
  can stay or be undone).

📺 Options > Display no longer crashes the game (reported by Arpadiam on Discord: the Resolution
list was empty, and leaving the screen with OK closed the game)

• The port described the TV's video modes to the game with a block of data missing (the TV's colour
  information comes before the list of modes), so GT5 read its list 20 bytes too early, found a mode
  with resolution 0, showed an empty Resolution list and failed when the screen was confirmed.
• The list now has the layout the PS3 uses, with one mode: the one the port draws (1080p or 720p, as
  set in the launcher), at 59.94/60 Hz, the way RPCS3 reports it.
• Checked on this PC with the European disc: Display Settings shows 1920 x 1080 59.94p, and OK
  returns to Options with the game still running. The 2.11 update's Resolution row is not tested here.

☀️ Races at 1080p get the right brightness: no more blown-out white or too-dark tracks (reported by
Keduboneur78 on Discord: Speed Test's track near-white even at −1.0 EV)

• GT5 sets each frame's exposure from a small 16x8 copy of the scene that it reads back from the
  graphics chip. In 1080p mode that copy sits in memory that a bigger image left over from an earlier
  scene also covers, and the Windows renderer read it from that leftover image. So auto-exposure judged
  every race by a frozen patch of whatever was shown before (often the title screen's white city), and
  a race came out as bright or as dark as that patch suggested: Speed Test blown out to white, or High
  Speed Ring almost black on this PC.
• It now reads the image the game actually measures into, as the Linux and Android renderer already
  did. 720p mode was never affected.
• Checked on this PC with the European disc: High Speed Ring at 1080p averages a brightness of 81, like
  the same start at 720p (84); before, with the leftover patch, it was 17. The play.err now says which
  image feeds the exposure ([blit-readback] source now ...). LD_RECT_PICK=0 brings back the old
  behaviour. Speed Test itself is a DLC course not tested here.

📦 **Ins...

v0.1.50: Linux: the game window opens on KDE Plasma under Wayland (#32)

What's new

14 Nov 2026

🐧 Linux: the game window opens on KDE Plasma under Wayland
(#32, lotushomerun: the game ran, with sound,
but no window ever appeared; Arch Linux, Radeon RX 5500 XT)

• To open its window the Vulkan renderer asks the graphics driver which picture formats the window
  can take. It made room for 64 answers. KDE Plasma on Wayland, with Mesa's driver, pairs every format
  with several colour spaces (for HDR) and gives well over 64. The driver then fills the 64 and says
  "there are more", which is a normal answer, but the renderer took it for an error, gave up on the
  window and carried on without one. It now takes all of them, and picks the ordinary (non-HDR) colour
  space when a format comes in several.
• If the window still can't be opened, play.err now says so in plain words, and that Ctrl+C in the
  terminal stops the game. On Wayland, SDL_VIDEODRIVER=x11 bash GT5/play.sh (through XWayland) is a
  way around it.
• Checked: with the same renderer on Windows the window still opens as before. There's no Plasma
  Wayland session here, so the case with more than 64 formats itself is untested.

🐧 Linux: no more freezes when something new comes on screen, and road markings sit on the road
(#20, melroy89: single frames of 0.3 to 0.7 s,
once 1.7 s, in races and licence tests on a Radeon RX 7900 XTX)

• The Vulkan renderer (the Linux build's) made every shader the game hadn't used before on the spot,
  while the game waited: translated into Vulkan's form, then compiled by the graphics driver. A new
  car, track or menu asks for 100 to 300 of them at once, so the picture stopped for up to seconds.
  Now they're built on spare CPU cores while the game keeps running (PS3RECOMP_VK_ASYNC_SHADERS, on
  in play.sh). The cost: something can be missing for its first few frames on screen.
  export PS3RECOMP_VK_ASYNC_SHADERS=0 in GT5/settings.sh goes back to the old way.
• Checked on this PC with the Windows build of the same Vulkan renderer (NVIDIA card), from the title
  screen to the B-1 licence test with no shaders cached yet. Before: 16 frames of 250 ms or more, 10 s
  frozen in all, the worst 2.2 s (and 5.9 s with the driver's own cache empty too). Now: none of
  250 ms or more, the worst 210 ms, and the pictures were complete once the shaders were built.
• GT5 moves road markings, skid marks and its shadow maps a tiny step towards or away from the camera
  (the PS3's polygon offset), so they don't flicker against the surface under them. The Vulkan
  renderer ignored that and now applies it (PS3RECOMP_VK_DEPTH_BIAS=0 turns it off). Whether it is
  also what made the car bodies flicker on the 7900 XTX isn't known yet: that didn't show here.
• play.err now has a [slow-frame] line for every frame of 250 ms or more, as the Windows build
  does, splitting it into new shaders (translation and driver), textures, waiting for the GPU and the
  rest (PS3RECOMP_VK_HITCH_MS sets the limit, 0 turns it off). A texture the renderer can't create
  is now logged too.
• Not seen on this PC yet (NVIDIA, European disc): the flickering car bodies, the see-through road in
  the B-2 intro, the missing textures in a braking test and the dark title-screen scene. With
  PS3_SKIP_INTRO=1 (play.sh's default) the scene behind the title is GT5's own replay of a race at
  dusk or at night, drawn live, and it is just as dark in the Windows build. Questions for those are
  on #20.

📷 Photo Mode pictures have their real colours again: no more yellow-green tint or coloured ghost copies
(brocolison and Arpadiam on Discord: tinted, ghosted and very dark photos)

• GT5 builds a photo from about 50 slightly shifted renders, averaged one after another into a
  high-precision image (that gives photos their smooth edges and depth of field). Each render is blended
  in with a weight the game sets as a constant blend colour. For this kind of image the PS3 keeps that
  constant in two registers, and the port read its second half (blue and alpha) from the wrong one, so
  blue was blended with a weight of 0 and kept whatever the image held before: black, which gave the
  yellow-green tint, or part of an older render, which gave the coloured ghost copies. The weight was
  also taken per colour channel where the PS3 uses the alpha value for all of them.
• Checked on this PC with the European disc in Photo Travel (Kyoto - Gion): before, the saved photo had
  no blue at all (pink blossom came out yellow, the night sky green); now its colours match the
  viewfinder, and a 3840 x 2160 photo (16:9, x2) has no ghost copies.
• Not fixed yet: after a photo is taken, the viewfinder and the next photos can come out much darker.
  That happened before this change too and is being looked into. Auto Focus did not show ghost copies
  on this PC.

🛡️ The game starts on PCs where Windows forces Control Flow Guard on every program
(#31, Fantomas3228: the game closed a second
after Play, with a log that just stopped)

• Windows Security's Exploit protection can turn Control Flow Guard (CFG) on for all programs. With it
  on, Windows checks every longjmp the program makes, and the SPU code's fast jumps (which skip
  unwinding, for speed) failed that check: Windows ended the game on the spot (fast fail, exit code
  0xC0000409) as the first SPU job ran.
• Now the game asks Windows whether CFG is on for it, and if so makes those jumps the standard way.
  play.err then says [spu] Control Flow Guard is on for this process. PCs without CFG forced on keep
  the faster jumps.
• Checked on this PC by starting the game with CFG switched on for that one run: before, it closed
  after 2 s with 0xC0000409 at the same line as in #31; now it runs normally. No Windows setting needs
  changing any more (Fantomas3228's workaround, Set-ProcessMitigation -Name gt5.exe -Disable CFG,
  can stay or be undone).

📺 Options > Display no longer crashes the game (reported by Arpadiam on Discord: the Resolution
list was empty, and leaving the screen with OK closed the game)

• The port described the TV's video modes to the game with a block of data missing (the TV's colour
  information comes before the list of modes), so GT5 read its list 20 bytes too early, found a mode
  with resolution 0, showed an empty Resolution list and failed when the screen was confirmed.
• The list now has the layout the PS3 uses, with one mode: the one the port draws (1080p or 720p, as
  set in the launcher), at 59.94/60 Hz, the way RPCS3 reports it.
• Checked on this PC with the European disc: Display Settings shows 1920 x 1080 59.94p, and OK
  returns to Options with the game still running. The 2.11 update's Resolution row is not tested here.

☀️ Races at 1080p get the right brightness: no more blown-out white or too-dark tracks (reported by
Keduboneur78 on Discord: Speed Test's track near-white even at −1.0 EV)

• GT5 sets each frame's exposure from a small 16x8 copy of the scene that it reads back from the
  graphics chip. In 1080p mode that copy sits in memory that a bigger image left over from an earlier
  scene also covers, and the Windows renderer read it from that leftover image. So auto-exposure judged
  every race by a frozen patch of whatever was shown before (often the title screen's white city), and
  a race came out as bright or as dark as that patch suggested: Speed Test blown out to white, or High
  Speed Ring almost black on this PC.
• It now reads the image the game actually measures into, as the Linux and Android renderer already
  did. 720p mode was never affected.
• Checked on this PC with the European disc: High Speed Ring at 1080p averages a brightness of 81, like
  the same start at 720p (84); before, with the leftover patch, it was 17. The play.err now says which
  image feeds the exposure ([blit-readback] source now ...). LD_RECT_PICK=0 brings back the old
  behaviour. Speed Test itself is a DLC course not tested here.

📦 Install game updates and DLC from their .pkg files (asked for by Keduboneur78 on Discord: "just
import PKG files the way RPCS3 does")

• The launcher's Help > Install a game update or DLC (.pkg) takes the packages you pick
  (GT5\scripts\install_pkg.ps1 <files or folder> does the same). Before, an update meant installing it
  in RPCS3, copying its folder into GT5\hdd0 by hand and unlocking its executable.
• It reads each package's header, puts updates in version order, and has RPCS3 install them: RPCS3's
  window opens for each, and the script answers its Do you want to install this package? and closes
  it when the install is done. Updates RPCS3 already has are skipped, and its errors are passed on
  (Update is for version 01.12, but you don't have any data installed).
• Then the game's folder is copied from RPCS3's dev_hdd0 to GT5\hdd0 (all but EBOOT.BIN), and
  update_exe.ps1 unlocks the update's executable into GT5\input\EBOOT.elf. What's left is one
  setup.bat to build the game for that version.
• Checked with the European updates 1.05 and 1.06 and a copy of RPCS3 0.0.37:
  • 1.05, already installed, was skipped; 1.06 installed with no clicks.
  • The folder landed in GT5\hdd0 as version 01.06.
  • EBOOT.elf became 1.06's executable, with the disc's kept beside it.
• RPCS3 doesn't start from a temporary folder: run it from a normal one. DLC vouchers still need
  their licence keys (README, DLC).

🩺 The launcher says why the game stopped, when Windows knows (for reports like
#31, where the game closed at once and its log
just stopped)

• Some crashes skip the game's own crash report: a "fast fail" (exception 0xC0000409) ends the game
  on the spot. So does Microsoft Defender stopping it. Either way play.err stops mid-start with no
  ...

v0.1.49: Linux: no more freezes when something new comes on screen, and road markings sit on the road (#20)

What's new

14 Nov 2026

🐧 Linux: no more freezes when something new comes on screen, and road markings sit on the road
(#20, melroy89: single frames of 0.3 to 0.7 s,
once 1.7 s, in races and licence tests on a Radeon RX 7900 XTX)

• The Vulkan renderer (the Linux build's) made every shader the game hadn't used before on the spot,
  while the game waited: translated into Vulkan's form, then compiled by the graphics driver. A new
  car, track or menu asks for 100 to 300 of them at once, so the picture stopped for up to seconds.
  Now they're built on spare CPU cores while the game keeps running (PS3RECOMP_VK_ASYNC_SHADERS, on
  in play.sh). The cost: something can be missing for its first few frames on screen.
  export PS3RECOMP_VK_ASYNC_SHADERS=0 in GT5/settings.sh goes back to the old way.
• Checked on this PC with the Windows build of the same Vulkan renderer (NVIDIA card), from the title
  screen to the B-1 licence test with no shaders cached yet. Before: 16 frames of 250 ms or more, 10 s
  frozen in all, the worst 2.2 s (and 5.9 s with the driver's own cache empty too). Now: none of
  250 ms or more, the worst 210 ms, and the pictures were complete once the shaders were built.
• GT5 moves road markings, skid marks and its shadow maps a tiny step towards or away from the camera
  (the PS3's polygon offset), so they don't flicker against the surface under them. The Vulkan
  renderer ignored that and now applies it (PS3RECOMP_VK_DEPTH_BIAS=0 turns it off). Whether it is
  also what made the car bodies flicker on the 7900 XTX isn't known yet: that didn't show here.
• play.err now has a [slow-frame] line for every frame of 250 ms or more, as the Windows build
  does, splitting it into new shaders (translation and driver), textures, waiting for the GPU and the
  rest (PS3RECOMP_VK_HITCH_MS sets the limit, 0 turns it off). A texture the renderer can't create
  is now logged too.
• Not seen on this PC yet (NVIDIA, European disc): the flickering car bodies, the see-through road in
  the B-2 intro, the missing textures in a braking test and the dark title-screen scene. With
  PS3_SKIP_INTRO=1 (play.sh's default) the scene behind the title is GT5's own replay of a race at
  dusk or at night, drawn live, and it is just as dark in the Windows build. Questions for those are
  on #20.

📷 Photo Mode pictures have their real colours again: no more yellow-green tint or coloured ghost copies
(brocolison and Arpadiam on Discord: tinted, ghosted and very dark photos)

• GT5 builds a photo from about 50 slightly shifted renders, averaged one after another into a
  high-precision image (that gives photos their smooth edges and depth of field). Each render is blended
  in with a weight the game sets as a constant blend colour. For this kind of image the PS3 keeps that
  constant in two registers, and the port read its second half (blue and alpha) from the wrong one, so
  blue was blended with a weight of 0 and kept whatever the image held before: black, which gave the
  yellow-green tint, or part of an older render, which gave the coloured ghost copies. The weight was
  also taken per colour channel where the PS3 uses the alpha value for all of them.
• Checked on this PC with the European disc in Photo Travel (Kyoto - Gion): before, the saved photo had
  no blue at all (pink blossom came out yellow, the night sky green); now its colours match the
  viewfinder, and a 3840 x 2160 photo (16:9, x2) has no ghost copies.
• Not fixed yet: after a photo is taken, the viewfinder and the next photos can come out much darker.
  That happened before this change too and is being looked into. Auto Focus did not show ghost copies
  on this PC.

🛡️ The game starts on PCs where Windows forces Control Flow Guard on every program
(#31, Fantomas3228: the game closed a second
after Play, with a log that just stopped)

• Windows Security's Exploit protection can turn Control Flow Guard (CFG) on for all programs. With it
  on, Windows checks every longjmp the program makes, and the SPU code's fast jumps (which skip
  unwinding, for speed) failed that check: Windows ended the game on the spot (fast fail, exit code
  0xC0000409) as the first SPU job ran.
• Now the game asks Windows whether CFG is on for it, and if so makes those jumps the standard way.
  play.err then says [spu] Control Flow Guard is on for this process. PCs without CFG forced on keep
  the faster jumps.
• Checked on this PC by starting the game with CFG switched on for that one run: before, it closed
  after 2 s with 0xC0000409 at the same line as in #31; now it runs normally. No Windows setting needs
  changing any more (Fantomas3228's workaround, Set-ProcessMitigation -Name gt5.exe -Disable CFG,
  can stay or be undone).

📺 Options > Display no longer crashes the game (reported by Arpadiam on Discord: the Resolution
list was empty, and leaving the screen with OK closed the game)

• The port described the TV's video modes to the game with a block of data missing (the TV's colour
  information comes before the list of modes), so GT5 read its list 20 bytes too early, found a mode
  with resolution 0, showed an empty Resolution list and failed when the screen was confirmed.
• The list now has the layout the PS3 uses, with one mode: the one the port draws (1080p or 720p, as
  set in the launcher), at 59.94/60 Hz, the way RPCS3 reports it.
• Checked on this PC with the European disc: Display Settings shows 1920 x 1080 59.94p, and OK
  returns to Options with the game still running. The 2.11 update's Resolution row is not tested here.

☀️ Races at 1080p get the right brightness: no more blown-out white or too-dark tracks (reported by
Keduboneur78 on Discord: Speed Test's track near-white even at −1.0 EV)

• GT5 sets each frame's exposure from a small 16x8 copy of the scene that it reads back from the
  graphics chip. In 1080p mode that copy sits in memory that a bigger image left over from an earlier
  scene also covers, and the Windows renderer read it from that leftover image. So auto-exposure judged
  every race by a frozen patch of whatever was shown before (often the title screen's white city), and
  a race came out as bright or as dark as that patch suggested: Speed Test blown out to white, or High
  Speed Ring almost black on this PC.
• It now reads the image the game actually measures into, as the Linux and Android renderer already
  did. 720p mode was never affected.
• Checked on this PC with the European disc: High Speed Ring at 1080p averages a brightness of 81, like
  the same start at 720p (84); before, with the leftover patch, it was 17. The play.err now says which
  image feeds the exposure ([blit-readback] source now ...). LD_RECT_PICK=0 brings back the old
  behaviour. Speed Test itself is a DLC course not tested here.

📦 Install game updates and DLC from their .pkg files (asked for by Keduboneur78 on Discord: "just
import PKG files the way RPCS3 does")

• The launcher's Help > Install a game update or DLC (.pkg) takes the packages you pick
  (GT5\scripts\install_pkg.ps1 <files or folder> does the same). Before, an update meant installing it
  in RPCS3, copying its folder into GT5\hdd0 by hand and unlocking its executable.
• It reads each package's header, puts updates in version order, and has RPCS3 install them: RPCS3's
  window opens for each, and the script answers its Do you want to install this package? and closes
  it when the install is done. Updates RPCS3 already has are skipped, and its errors are passed on
  (Update is for version 01.12, but you don't have any data installed).
• Then the game's folder is copied from RPCS3's dev_hdd0 to GT5\hdd0 (all but EBOOT.BIN), and
  update_exe.ps1 unlocks the update's executable into GT5\input\EBOOT.elf. What's left is one
  setup.bat to build the game for that version.
• Checked with the European updates 1.05 and 1.06 and a copy of RPCS3 0.0.37:
  • 1.05, already installed, was skipped; 1.06 installed with no clicks.
  • The folder landed in GT5\hdd0 as version 01.06.
  • EBOOT.elf became 1.06's executable, with the disc's kept beside it.
• RPCS3 doesn't start from a temporary folder: run it from a normal one. DLC vouchers still need
  their licence keys (README, DLC).

🩺 The launcher says why the game stopped, when Windows knows (for reports like
#31, where the game closed at once and its log
just stopped)

• Some crashes skip the game's own crash report: a "fast fail" (exception 0xC0000409) ends the game
  on the spot. So does Microsoft Defender stopping it. Either way play.err stops mid-start with no
  error in it. Windows records both, so the launcher now looks when the game ends. It checks the
  Application log for an Application Error in gt5.exe (the exception, the module and the offset)
  and Defender's history, for the time the game ran.
• What it finds is shown in the launcher ("The game stopped. Windows says: ...") and added to
  play.err as a [launcher] Windows says: line, so Help > Save logs carries it into a report.
• Checked against this PC's own records: they hold three earlier gt5.exe fast-fails from test builds,
  read back with the code, module and offset. The update rebuilds the launcher (Update.bat, or the
  launcher's update).

🎵 Leaner SPU code: GT5's sound mixer 22% faster, all SPU jobs 14% less CPU (one re-lift, done by
update.ps1)

• The sound mixer is one SPU job run on one host thread 187.5 times a second (once per 256-sample block
  of 48 kHz audio), and nothing else can share that work out. On a stand-in for a 4-core laptop (the
  tested rig's i9 limited to 4 of its efficient cores) it was the one thread running flat out: about a
  full core, and short of real time.
• Its hottest loops filter the sound samp...

v0.1.48: Photo Mode pictures have their real colours again: no more yellow-green tint or coloured ghost copies

What's new

14 Nov 2026

📷 Photo Mode pictures have their real colours again: no more yellow-green tint or coloured ghost copies
(brocolison and Arpadiam on Discord: tinted, ghosted and very dark photos)

• GT5 builds a photo from about 50 slightly shifted renders, averaged one after another into a
  high-precision image (that gives photos their smooth edges and depth of field). Each render is blended
  in with a weight the game sets as a constant blend colour. For this kind of image the PS3 keeps that
  constant in two registers, and the port read its second half (blue and alpha) from the wrong one, so
  blue was blended with a weight of 0 and kept whatever the image held before: black, which gave the
  yellow-green tint, or part of an older render, which gave the coloured ghost copies. The weight was
  also taken per colour channel where the PS3 uses the alpha value for all of them.
• Checked on this PC with the European disc in Photo Travel (Kyoto - Gion): before, the saved photo had
  no blue at all (pink blossom came out yellow, the night sky green); now its colours match the
  viewfinder, and a 3840 x 2160 photo (16:9, x2) has no ghost copies.
• Not fixed yet: after a photo is taken, the viewfinder and the next photos can come out much darker.
  That happened before this change too and is being looked into. Auto Focus did not show ghost copies
  on this PC.

🛡️ The game starts on PCs where Windows forces Control Flow Guard on every program
(#31, Fantomas3228: the game closed a second
after Play, with a log that just stopped)

• Windows Security's Exploit protection can turn Control Flow Guard (CFG) on for all programs. With it
  on, Windows checks every longjmp the program makes, and the SPU code's fast jumps (which skip
  unwinding, for speed) failed that check: Windows ended the game on the spot (fast fail, exit code
  0xC0000409) as the first SPU job ran.
• Now the game asks Windows whether CFG is on for it, and if so makes those jumps the standard way.
  play.err then says [spu] Control Flow Guard is on for this process. PCs without CFG forced on keep
  the faster jumps.
• Checked on this PC by starting the game with CFG switched on for that one run: before, it closed
  after 2 s with 0xC0000409 at the same line as in #31; now it runs normally. No Windows setting needs
  changing any more (Fantomas3228's workaround, Set-ProcessMitigation -Name gt5.exe -Disable CFG,
  can stay or be undone).

📺 Options > Display no longer crashes the game (reported by Arpadiam on Discord: the Resolution
list was empty, and leaving the screen with OK closed the game)

• The port described the TV's video modes to the game with a block of data missing (the TV's colour
  information comes before the list of modes), so GT5 read its list 20 bytes too early, found a mode
  with resolution 0, showed an empty Resolution list and failed when the screen was confirmed.
• The list now has the layout the PS3 uses, with one mode: the one the port draws (1080p or 720p, as
  set in the launcher), at 59.94/60 Hz, the way RPCS3 reports it.
• Checked on this PC with the European disc: Display Settings shows 1920 x 1080 59.94p, and OK
  returns to Options with the game still running. The 2.11 update's Resolution row is not tested here.

☀️ Races at 1080p get the right brightness: no more blown-out white or too-dark tracks (reported by
Keduboneur78 on Discord: Speed Test's track near-white even at −1.0 EV)

• GT5 sets each frame's exposure from a small 16x8 copy of the scene that it reads back from the
  graphics chip. In 1080p mode that copy sits in memory that a bigger image left over from an earlier
  scene also covers, and the Windows renderer read it from that leftover image. So auto-exposure judged
  every race by a frozen patch of whatever was shown before (often the title screen's white city), and
  a race came out as bright or as dark as that patch suggested: Speed Test blown out to white, or High
  Speed Ring almost black on this PC.
• It now reads the image the game actually measures into, as the Linux and Android renderer already
  did. 720p mode was never affected.
• Checked on this PC with the European disc: High Speed Ring at 1080p averages a brightness of 81, like
  the same start at 720p (84); before, with the leftover patch, it was 17. The play.err now says which
  image feeds the exposure ([blit-readback] source now ...). LD_RECT_PICK=0 brings back the old
  behaviour. Speed Test itself is a DLC course not tested here.

📦 Install game updates and DLC from their .pkg files (asked for by Keduboneur78 on Discord: "just
import PKG files the way RPCS3 does")

• The launcher's Help > Install a game update or DLC (.pkg) takes the packages you pick
  (GT5\scripts\install_pkg.ps1 <files or folder> does the same). Before, an update meant installing it
  in RPCS3, copying its folder into GT5\hdd0 by hand and unlocking its executable.
• It reads each package's header, puts updates in version order, and has RPCS3 install them: RPCS3's
  window opens for each, and the script answers its Do you want to install this package? and closes
  it when the install is done. Updates RPCS3 already has are skipped, and its errors are passed on
  (Update is for version 01.12, but you don't have any data installed).
• Then the game's folder is copied from RPCS3's dev_hdd0 to GT5\hdd0 (all but EBOOT.BIN), and
  update_exe.ps1 unlocks the update's executable into GT5\input\EBOOT.elf. What's left is one
  setup.bat to build the game for that version.
• Checked with the European updates 1.05 and 1.06 and a copy of RPCS3 0.0.37:
  • 1.05, already installed, was skipped; 1.06 installed with no clicks.
  • The folder landed in GT5\hdd0 as version 01.06.
  • EBOOT.elf became 1.06's executable, with the disc's kept beside it.
• RPCS3 doesn't start from a temporary folder: run it from a normal one. DLC vouchers still need
  their licence keys (README, DLC).

🩺 The launcher says why the game stopped, when Windows knows (for reports like
#31, where the game closed at once and its log
just stopped)

• Some crashes skip the game's own crash report: a "fast fail" (exception 0xC0000409) ends the game
  on the spot. So does Microsoft Defender stopping it. Either way play.err stops mid-start with no
  error in it. Windows records both, so the launcher now looks when the game ends. It checks the
  Application log for an Application Error in gt5.exe (the exception, the module and the offset)
  and Defender's history, for the time the game ran.
• What it finds is shown in the launcher ("The game stopped. Windows says: ...") and added to
  play.err as a [launcher] Windows says: line, so Help > Save logs carries it into a report.
• Checked against this PC's own records: they hold three earlier gt5.exe fast-fails from test builds,
  read back with the code, module and offset. The update rebuilds the launcher (Update.bat, or the
  launcher's update).

🎵 Leaner SPU code: GT5's sound mixer 22% faster, all SPU jobs 14% less CPU (one re-lift, done by
update.ps1)

• The sound mixer is one SPU job run on one host thread 187.5 times a second (once per 256-sample block
  of 48 kHz audio), and nothing else can share that work out. On a stand-in for a 4-core laptop (the
  tested rig's i9 limited to 4 of its efficient cores) it was the one thread running flat out: about a
  full core, and short of real time.
• Its hottest loops filter the sound sample by sample. In the lifted code, a loop that starts where its
  function starts wrote every SPU register it changed back to memory and read it again on every pass.
  Such a loop now keeps them in CPU registers from one pass to the next, as other loops already did.
• The SPU stores a single number by building a mask for its position and shuffling it into the 16
  bytes it writes back. Where that mask was just built, the shuffle is now a direct insert.
• Measured with the per-job SPU timer, alternating the old and new builds three times on all cores:
  the mixer from 1.99 to 1.56 ms per block (−22%), all SPU jobs from 40.0 to 34.4 s of CPU per
  minute (−14%). On the 4 efficient cores, with another game running at the same time: the mixer from
  3.9-4.2 to 3.1 ms per block.
• Checked by lifting every SPU job both ways and running both from every entry point on random states:
  the same registers, local store and channel traffic in about 15,000 runs (15 job images and the 4
  busiest Wws job images). A race looks and sounds as before.
• The lifter's --no-loop-head-loads and --no-insert-peephole give the old output, for comparison.
• Needs one re-lift (the SPU lifter changed); update.ps1 does it.

---

Updating: the launcher's Updates page (Update now), or double-click Update.bat in your install folder, or run powershell -ExecutionPolicy Bypass -File update.ps1 there (close the game first). It goes straight to this version however far behind you are, re-lifts and rebuilds only what this version needs, and keeps your saves and settings. Installed before update.ps1 existed, or from a ZIP: see Updating in the README. Any other version: update.ps1 -List, then update.ps1 -Version <version>.
New install: download GT5-Installer.bat below and double-click it, or see the README. Full history: CHANGELOG.md.

v0.1.47: The game starts with Windows' Control Flow Guard forced on (#31), and Options > Display no longer crashes it

What's new

14 Nov 2026

🛡️ The game starts on PCs where Windows forces Control Flow Guard on every program
(#31, Fantomas3228: the game closed a second
after Play, with a log that just stopped)

• Windows Security's Exploit protection can turn Control Flow Guard (CFG) on for all programs. With it
  on, Windows checks every longjmp the program makes, and the SPU code's fast jumps (which skip
  unwinding, for speed) failed that check: Windows ended the game on the spot (fast fail, exit code
  0xC0000409) as the first SPU job ran.
• Now the game asks Windows whether CFG is on for it, and if so makes those jumps the standard way.
  play.err then says [spu] Control Flow Guard is on for this process. PCs without CFG forced on keep
  the faster jumps.
• Checked on this PC by starting the game with CFG switched on for that one run: before, it closed
  after 2 s with 0xC0000409 at the same line as in #31; now it runs normally. No Windows setting needs
  changing any more (Fantomas3228's workaround, Set-ProcessMitigation -Name gt5.exe -Disable CFG,
  can stay or be undone).

📺 Options > Display no longer crashes the game (reported by Arpadiam on Discord: the Resolution
list was empty, and leaving the screen with OK closed the game)

• The port described the TV's video modes to the game with a block of data missing (the TV's colour
  information comes before the list of modes), so GT5 read its list 20 bytes too early, found a mode
  with resolution 0, showed an empty Resolution list and failed when the screen was confirmed.
• The list now has the layout the PS3 uses, with one mode: the one the port draws (1080p or 720p, as
  set in the launcher), at 59.94/60 Hz, the way RPCS3 reports it.
• Checked on this PC with the European disc: Display Settings shows 1920 x 1080 59.94p, and OK
  returns to Options with the game still running. The 2.11 update's Resolution row is not tested here.

☀️ Races at 1080p get the right brightness: no more blown-out white or too-dark tracks (reported by
Keduboneur78 on Discord: Speed Test's track near-white even at −1.0 EV)

• GT5 sets each frame's exposure from a small 16x8 copy of the scene that it reads back from the
  graphics chip. In 1080p mode that copy sits in memory that a bigger image left over from an earlier
  scene also covers, and the Windows renderer read it from that leftover image. So auto-exposure judged
  every race by a frozen patch of whatever was shown before (often the title screen's white city), and
  a race came out as bright or as dark as that patch suggested: Speed Test blown out to white, or High
  Speed Ring almost black on this PC.
• It now reads the image the game actually measures into, as the Linux and Android renderer already
  did. 720p mode was never affected.
• Checked on this PC with the European disc: High Speed Ring at 1080p averages a brightness of 81, like
  the same start at 720p (84); before, with the leftover patch, it was 17. The play.err now says which
  image feeds the exposure ([blit-readback] source now ...). LD_RECT_PICK=0 brings back the old
  behaviour. Speed Test itself is a DLC course not tested here.

📦 Install game updates and DLC from their .pkg files (asked for by Keduboneur78 on Discord: "just
import PKG files the way RPCS3 does")

• The launcher's Help > Install a game update or DLC (.pkg) takes the packages you pick
  (GT5\scripts\install_pkg.ps1 <files or folder> does the same). Before, an update meant installing it
  in RPCS3, copying its folder into GT5\hdd0 by hand and unlocking its executable.
• It reads each package's header, puts updates in version order, and has RPCS3 install them: RPCS3's
  window opens for each, and the script answers its Do you want to install this package? and closes
  it when the install is done. Updates RPCS3 already has are skipped, and its errors are passed on
  (Update is for version 01.12, but you don't have any data installed).
• Then the game's folder is copied from RPCS3's dev_hdd0 to GT5\hdd0 (all but EBOOT.BIN), and
  update_exe.ps1 unlocks the update's executable into GT5\input\EBOOT.elf. What's left is one
  setup.bat to build the game for that version.
• Checked with the European updates 1.05 and 1.06 and a copy of RPCS3 0.0.37:
  • 1.05, already installed, was skipped; 1.06 installed with no clicks.
  • The folder landed in GT5\hdd0 as version 01.06.
  • EBOOT.elf became 1.06's executable, with the disc's kept beside it.
• RPCS3 doesn't start from a temporary folder: run it from a normal one. DLC vouchers still need
  their licence keys (README, DLC).

🩺 The launcher says why the game stopped, when Windows knows (for reports like
#31, where the game closed at once and its log
just stopped)

• Some crashes skip the game's own crash report: a "fast fail" (exception 0xC0000409) ends the game
  on the spot. So does Microsoft Defender stopping it. Either way play.err stops mid-start with no
  error in it. Windows records both, so the launcher now looks when the game ends. It checks the
  Application log for an Application Error in gt5.exe (the exception, the module and the offset)
  and Defender's history, for the time the game ran.
• What it finds is shown in the launcher ("The game stopped. Windows says: ...") and added to
  play.err as a [launcher] Windows says: line, so Help > Save logs carries it into a report.
• Checked against this PC's own records: they hold three earlier gt5.exe fast-fails from test builds,
  read back with the code, module and offset. The update rebuilds the launcher (Update.bat, or the
  launcher's update).

🎵 Leaner SPU code: GT5's sound mixer 22% faster, all SPU jobs 14% less CPU (one re-lift, done by
update.ps1)

• The sound mixer is one SPU job run on one host thread 187.5 times a second (once per 256-sample block
  of 48 kHz audio), and nothing else can share that work out. On a stand-in for a 4-core laptop (the
  tested rig's i9 limited to 4 of its efficient cores) it was the one thread running flat out: about a
  full core, and short of real time.
• Its hottest loops filter the sound sample by sample. In the lifted code, a loop that starts where its
  function starts wrote every SPU register it changed back to memory and read it again on every pass.
  Such a loop now keeps them in CPU registers from one pass to the next, as other loops already did.
• The SPU stores a single number by building a mask for its position and shuffling it into the 16
  bytes it writes back. Where that mask was just built, the shuffle is now a direct insert.
• Measured with the per-job SPU timer, alternating the old and new builds three times on all cores:
  the mixer from 1.99 to 1.56 ms per block (−22%), all SPU jobs from 40.0 to 34.4 s of CPU per
  minute (−14%). On the 4 efficient cores, with another game running at the same time: the mixer from
  3.9-4.2 to 3.1 ms per block.
• Checked by lifting every SPU job both ways and running both from every entry point on random states:
  the same registers, local store and channel traffic in about 15,000 runs (15 job images and the 4
  busiest Wws job images). A race looks and sounds as before.
• The lifter's --no-loop-head-loads and --no-insert-peephole give the old output, for comparison.
• Needs one re-lift (the SPU lifter changed); update.ps1 does it.

---

Updating: the launcher's Updates page (Update now), or double-click Update.bat in your install folder, or run powershell -ExecutionPolicy Bypass -File update.ps1 there (close the game first). It goes straight to this version however far behind you are, re-lifts and rebuilds only what this version needs, and keeps your saves and settings. Installed before update.ps1 existed, or from a ZIP: see Updating in the README. Any other version: update.ps1 -List, then update.ps1 -Version <version>.
New install: download GT5-Installer.bat below and double-click it, or see the README. Full history: CHANGELOG.md.

v0.1.46: Races at 1080p get the right brightness: auto-exposure read a leftover image (Speed Test blown out to white, some tracks far too dark)

What's new

14 Nov 2026

☀️ Races at 1080p get the right brightness: no more blown-out white or too-dark tracks (reported by
Keduboneur78 on Discord: Speed Test's track near-white even at −1.0 EV)

• GT5 sets each frame's exposure from a small 16x8 copy of the scene that it reads back from the
  graphics chip. In 1080p mode that copy sits in memory that a bigger image left over from an earlier
  scene also covers, and the Windows renderer read it from that leftover image. So auto-exposure judged
  every race by a frozen patch of whatever was shown before (often the title screen's white city), and
  a race came out as bright or as dark as that patch suggested: Speed Test blown out to white, or High
  Speed Ring almost black on this PC.
• It now reads the image the game actually measures into, as the Linux and Android renderer already
  did. 720p mode was never affected.
• Checked on this PC with the European disc: High Speed Ring at 1080p averages a brightness of 81, like
  the same start at 720p (84); before, with the leftover patch, it was 17. The play.err now says which
  image feeds the exposure ([blit-readback] source now ...). LD_RECT_PICK=0 brings back the old
  behaviour. Speed Test itself is a DLC course not tested here.

📦 Install game updates and DLC from their .pkg files (asked for by Keduboneur78 on Discord: "just
import PKG files the way RPCS3 does")

• The launcher's Help > Install a game update or DLC (.pkg) takes the packages you pick
  (GT5\scripts\install_pkg.ps1 <files or folder> does the same). Before, an update meant installing it
  in RPCS3, copying its folder into GT5\hdd0 by hand and unlocking its executable.
• It reads each package's header, puts updates in version order, and has RPCS3 install them: RPCS3's
  window opens for each, and the script answers its Do you want to install this package? and closes
  it when the install is done. Updates RPCS3 already has are skipped, and its errors are passed on
  (Update is for version 01.12, but you don't have any data installed).
• Then the game's folder is copied from RPCS3's dev_hdd0 to GT5\hdd0 (all but EBOOT.BIN), and
  update_exe.ps1 unlocks the update's executable into GT5\input\EBOOT.elf. What's left is one
  setup.bat to build the game for that version.
• Checked with the European updates 1.05 and 1.06 and a copy of RPCS3 0.0.37:
  • 1.05, already installed, was skipped; 1.06 installed with no clicks.
  • The folder landed in GT5\hdd0 as version 01.06.
  • EBOOT.elf became 1.06's executable, with the disc's kept beside it.
• RPCS3 doesn't start from a temporary folder: run it from a normal one. DLC vouchers still need
  their licence keys (README, DLC).

🩺 The launcher says why the game stopped, when Windows knows (for reports like
#31, where the game closed at once and its log
just stopped)

• Some crashes skip the game's own crash report: a "fast fail" (exception 0xC0000409) ends the game
  on the spot. So does Microsoft Defender stopping it. Either way play.err stops mid-start with no
  error in it. Windows records both, so the launcher now looks when the game ends. It checks the
  Application log for an Application Error in gt5.exe (the exception, the module and the offset)
  and Defender's history, for the time the game ran.
• What it finds is shown in the launcher ("The game stopped. Windows says: ...") and added to
  play.err as a [launcher] Windows says: line, so Help > Save logs carries it into a report.
• Checked against this PC's own records: they hold three earlier gt5.exe fast-fails from test builds,
  read back with the code, module and offset. The update rebuilds the launcher (Update.bat, or the
  launcher's update).

🎵 Leaner SPU code: GT5's sound mixer 22% faster, all SPU jobs 14% less CPU (one re-lift, done by
update.ps1)

• The sound mixer is one SPU job run on one host thread 187.5 times a second (once per 256-sample block
  of 48 kHz audio), and nothing else can share that work out. On a stand-in for a 4-core laptop (the
  tested rig's i9 limited to 4 of its efficient cores) it was the one thread running flat out: about a
  full core, and short of real time.
• Its hottest loops filter the sound sample by sample. In the lifted code, a loop that starts where its
  function starts wrote every SPU register it changed back to memory and read it again on every pass.
  Such a loop now keeps them in CPU registers from one pass to the next, as other loops already did.
• The SPU stores a single number by building a mask for its position and shuffling it into the 16
  bytes it writes back. Where that mask was just built, the shuffle is now a direct insert.
• Measured with the per-job SPU timer, alternating the old and new builds three times on all cores:
  the mixer from 1.99 to 1.56 ms per block (−22%), all SPU jobs from 40.0 to 34.4 s of CPU per
  minute (−14%). On the 4 efficient cores, with another game running at the same time: the mixer from
  3.9-4.2 to 3.1 ms per block.
• Checked by lifting every SPU job both ways and running both from every entry point on random states:
  the same registers, local store and channel traffic in about 15,000 runs (15 job images and the 4
  busiest Wws job images). A race looks and sounds as before.
• The lifter's --no-loop-head-loads and --no-insert-peephole give the old output, for comparison.
• Needs one re-lift (the SPU lifter changed); update.ps1 does it.

---

Updating: the launcher's Updates page (Update now), or double-click Update.bat in your install folder, or run powershell -ExecutionPolicy Bypass -File update.ps1 there (close the game first). It goes straight to this version however far behind you are, re-lifts and rebuilds only what this version needs, and keeps your saves and settings. Installed before update.ps1 existed, or from a ZIP: see Updating in the README. Any other version: update.ps1 -List, then update.ps1 -Version <version>.
New install: download GT5-Installer.bat below and double-click it, or see the README. Full history: CHANGELOG.md.

v0.1.45: Install game updates and DLC from their .pkg files (launcher, Help), through RPCS3

What's new

14 Nov 2026

📦 Install game updates and DLC from their .pkg files (asked for by Keduboneur78 on Discord: "just
import PKG files the way RPCS3 does")

• The launcher's Help > Install a game update or DLC (.pkg) takes the packages you pick
  (GT5\scripts\install_pkg.ps1 <files or folder> does the same). Before, an update meant installing it
  in RPCS3, copying its folder into GT5\hdd0 by hand and unlocking its executable.
• It reads each package's header, puts updates in version order, and has RPCS3 install them: RPCS3's
  window opens for each, and the script answers its Do you want to install this package? and closes
  it when the install is done. Updates RPCS3 already has are skipped, and its errors are passed on
  (Update is for version 01.12, but you don't have any data installed).
• Then the game's folder is copied from RPCS3's dev_hdd0 to GT5\hdd0 (all but EBOOT.BIN), and
  update_exe.ps1 unlocks the update's executable into GT5\input\EBOOT.elf. What's left is one
  setup.bat to build the game for that version.
• Checked with the European updates 1.05 and 1.06 and a copy of RPCS3 0.0.37:
  • 1.05, already installed, was skipped; 1.06 installed with no clicks.
  • The folder landed in GT5\hdd0 as version 01.06.
  • EBOOT.elf became 1.06's executable, with the disc's kept beside it.
• RPCS3 doesn't start from a temporary folder: run it from a normal one. DLC vouchers still need
  their licence keys (README, DLC).

🩺 The launcher says why the game stopped, when Windows knows (for reports like
#31, where the game closed at once and its log
just stopped)

• Some crashes skip the game's own crash report: a "fast fail" (exception 0xC0000409) ends the game
  on the spot. So does Microsoft Defender stopping it. Either way play.err stops mid-start with no
  error in it. Windows records both, so the launcher now looks when the game ends. It checks the
  Application log for an Application Error in gt5.exe (the exception, the module and the offset)
  and Defender's history, for the time the game ran.
• What it finds is shown in the launcher ("The game stopped. Windows says: ...") and added to
  play.err as a [launcher] Windows says: line, so Help > Save logs carries it into a report.
• Checked against this PC's own records: they hold three earlier gt5.exe fast-fails from test builds,
  read back with the code, module and offset. The update rebuilds the launcher (Update.bat, or the
  launcher's update).

🎵 Leaner SPU code: GT5's sound mixer 22% faster, all SPU jobs 14% less CPU (one re-lift, done by
update.ps1)

• The sound mixer is one SPU job run on one host thread 187.5 times a second (once per 256-sample block
  of 48 kHz audio), and nothing else can share that work out. On a stand-in for a 4-core laptop (the
  tested rig's i9 limited to 4 of its efficient cores) it was the one thread running flat out: about a
  full core, and short of real time.
• Its hottest loops filter the sound sample by sample. In the lifted code, a loop that starts where its
  function starts wrote every SPU register it changed back to memory and read it again on every pass.
  Such a loop now keeps them in CPU registers from one pass to the next, as other loops already did.
• The SPU stores a single number by building a mask for its position and shuffling it into the 16
  bytes it writes back. Where that mask was just built, the shuffle is now a direct insert.
• Measured with the per-job SPU timer, alternating the old and new builds three times on all cores:
  the mixer from 1.99 to 1.56 ms per block (−22%), all SPU jobs from 40.0 to 34.4 s of CPU per
  minute (−14%). On the 4 efficient cores, with another game running at the same time: the mixer from
  3.9-4.2 to 3.1 ms per block.
• Checked by lifting every SPU job both ways and running both from every entry point on random states:
  the same registers, local store and channel traffic in about 15,000 runs (15 job images and the 4
  busiest Wws job images). A race looks and sounds as before.
• The lifter's --no-loop-head-loads and --no-insert-peephole give the old output, for comparison.
• Needs one re-lift (the SPU lifter changed); update.ps1 does it.

---

Updating: the launcher's Updates page (Update now), or double-click Update.bat in your install folder, or run powershell -ExecutionPolicy Bypass -File update.ps1 there (close the game first). It goes straight to this version however far behind you are, re-lifts and rebuilds only what this version needs, and keeps your saves and settings. Installed before update.ps1 existed, or from a ZIP: see Updating in the README. Any other version: update.ps1 -List, then update.ps1 -Version <version>.
New install: download GT5-Installer.bat below and double-click it, or see the README. Full history: CHANGELOG.md.

v0.1.44: The launcher says why the game stopped when Windows recorded it (a crash the game couldn't report, or Microsoft Defender)

What's new

14 Nov 2026

🩺 The launcher says why the game stopped, when Windows knows (for reports like
#31, where the game closed at once and its log
just stopped)

• Some crashes skip the game's own crash report: a "fast fail" (exception 0xC0000409) ends the game
  on the spot. So does Microsoft Defender stopping it. Either way play.err stops mid-start with no
  error in it. Windows records both, so the launcher now looks when the game ends. It checks the
  Application log for an Application Error in gt5.exe (the exception, the module and the offset)
  and Defender's history, for the time the game ran.
• What it finds is shown in the launcher ("The game stopped. Windows says: ...") and added to
  play.err as a [launcher] Windows says: line, so Help > Save logs carries it into a report.
• Checked against this PC's own records: they hold three earlier gt5.exe fast-fails from test builds,
  read back with the code, module and offset. The update rebuilds the launcher (Update.bat, or the
  launcher's update).

🎵 Leaner SPU code: GT5's sound mixer 22% faster, all SPU jobs 14% less CPU (one re-lift, done by
update.ps1)

• The sound mixer is one SPU job run on one host thread 187.5 times a second (once per 256-sample block
  of 48 kHz audio), and nothing else can share that work out. On a stand-in for a 4-core laptop (the
  tested rig's i9 limited to 4 of its efficient cores) it was the one thread running flat out: about a
  full core, and short of real time.
• Its hottest loops filter the sound sample by sample. In the lifted code, a loop that starts where its
  function starts wrote every SPU register it changed back to memory and read it again on every pass.
  Such a loop now keeps them in CPU registers from one pass to the next, as other loops already did.
• The SPU stores a single number by building a mask for its position and shuffling it into the 16
  bytes it writes back. Where that mask was just built, the shuffle is now a direct insert.
• Measured with the per-job SPU timer, alternating the old and new builds three times on all cores:
  the mixer from 1.99 to 1.56 ms per block (−22%), all SPU jobs from 40.0 to 34.4 s of CPU per
  minute (−14%). On the 4 efficient cores, with another game running at the same time: the mixer from
  3.9-4.2 to 3.1 ms per block.
• Checked by lifting every SPU job both ways and running both from every entry point on random states:
  the same registers, local store and channel traffic in about 15,000 runs (15 job images and the 4
  busiest Wws job images). A race looks and sounds as before.
• The lifter's --no-loop-head-loads and --no-insert-peephole give the old output, for comparison.
• Needs one re-lift (the SPU lifter changed); update.ps1 does it.

---

Updating: the launcher's Updates page (Update now), or double-click Update.bat in your install folder, or run powershell -ExecutionPolicy Bypass -File update.ps1 there (close the game first). It goes straight to this version however far behind you are, re-lifts and rebuilds only what this version needs, and keeps your saves and settings. Installed before update.ps1 existed, or from a ZIP: see Updating in the README. Any other version: update.ps1 -List, then update.ps1 -Version <version>.
New install: download GT5-Installer.bat below and double-click it, or see the README. Full history: CHANGELOG.md.

v0.1.43: Leaner SPU code: the sound mixer 22% faster, all SPU jobs 14% less CPU (one re-lift)

What's new

14 Nov 2026

🎵 Leaner SPU code: GT5's sound mixer 22% faster, all SPU jobs 14% less CPU (one re-lift, done by
update.ps1)

• The sound mixer is one SPU job run on one host thread 187.5 times a second (once per 256-sample block
  of 48 kHz audio), and nothing else can share that work out. On a stand-in for a 4-core laptop (the
  tested rig's i9 limited to 4 of its efficient cores) it was the one thread running flat out: about a
  full core, and short of real time.
• Its hottest loops filter the sound sample by sample. In the lifted code, a loop that starts where its
  function starts wrote every SPU register it changed back to memory and read it again on every pass.
  Such a loop now keeps them in CPU registers from one pass to the next, as other loops already did.
• The SPU stores a single number by building a mask for its position and shuffling it into the 16
  bytes it writes back. Where that mask was just built, the shuffle is now a direct insert.
• Measured with the per-job SPU timer, alternating the old and new builds three times on all cores:
  the mixer from 1.99 to 1.56 ms per block (−22%), all SPU jobs from 40.0 to 34.4 s of CPU per
  minute (−14%). On the 4 efficient cores, with another game running at the same time: the mixer from
  3.9-4.2 to 3.1 ms per block.
• Checked by lifting every SPU job both ways and running both from every entry point on random states:
  the same registers, local store and channel traffic in about 15,000 runs (15 job images and the 4
  busiest Wws job images). A race looks and sounds as before.
• The lifter's --no-loop-head-loads and --no-insert-peephole give the old output, for comparison.
• Needs one re-lift (the SPU lifter changed); update.ps1 does it.

13 Nov 2026

🛞 A steering wheel that stops answering no longer keeps driving the car (reported by brocolison on
Discord, Genius Speed Wheel 3)

• Once, mid-race, the car accelerated by itself and steered left with no control. The button setting he
  added afterwards (PS3_WHEEL_BUTTONS=cross=1,square=2,circle=3,triangle=4,start=10) is the same as the
  defaults, so it can't be what fixed it. The likeliest cause is the wheel briefly not answering (a USB
  hiccup, a loose cable): the port went on giving the game the wheel's last state, throttle and steering
  included, for a second or more, then dropped the wheel and looked for it again only every few seconds.
• Now after 50 ms without an answer the rim is centred and the pedals released, with the wheel still
  attached. After a second it's closed and looked for every half second. When the same wheel comes back,
  it keeps the rest points measured at the start, so a pedal held at that moment doesn't count as released.
• play.err says [wheel] not answering and answering again when it happens. Not tried on a real wheel
  (this PC has none); it builds and the game runs as before without one.

📺 Linux: the main menu at about 25-30 fps on a Steam Deck (was about 17)

• With the waits above gone, the menu's GPU waits came from two places, both every frame: each new
  render target was cleared in a submission of its own, waited on after first waiting for the open
  batch, and each released target made the renderer wait for every batch before it destroyed its
  cached framebuffers. GT5's menu releases and recreates a target or two a frame.
• A new colour or depth target is now cleared in the open batch, before the draws that use it (and
  a new texture is readied there too: in a race those waits were about 1.2 s in every 5 s), and
  framebuffers go to the same deferred list as released images, destroyed once the batches that may
  use them are done. (When a batch's list has no room left, that batch is waited on and they go at
  once, where before the extra entries were dropped.)
• On a Steam Deck in the main menu: time waiting for the GPU from about 1.2 s to 0.01 s per 5 s, the
  median frame from 53-58 to 35-36 ms, about 25-27 frames a second, most of them at two vblanks.

🪟 Linux: a present no longer waits for the frame to be drawn

• Each frame is copied into the window, and that copy shared the present's command buffer, so it was
  waited on at once; it sits in the GPU queue behind the frame being drawn, so every present waited
  for the whole frame's GPU work: about 11 ms of the graphics thread per frame on a Steam Deck. The
  window copy now has three command buffers, fences and acquire semaphores of its own, and one is
  waited on only when its turn comes round again, three presents later.
• On a Steam Deck in the main menu: a present 11 ms to 0.4 ms, the median frame 62-64 to 53-58 ms
  (the menu is still paced to three or four vblanks).

⚡ Game code: vector multiply-adds four lanes at a time (Windows and Linux)

• The PS3's vector multiply-add (vmaddfp) and negated multiply-subtract (vnmsubfp) were done one lane
  at a time, with several checks per lane, and without the CPU's fused multiply-add: about a tenth
  of a busy GT5 game thread. Now all four lanes go at once with one fused multiply-add, the same
  flush and NaN rules applied to the four together. The results are bit for bit the same: checked on
  4 million inputs per operation (random values, zeros, denormals, infinities, NaNs, rounding
  midpoints, both flush modes) against the per-lane code.
• The recompiled game code is built with FMA for it (every AVX2 CPU has FMA). Floating-point
  contraction stays off, so no other result changes.
• On a Steam Deck in a race: the game thread from about 69% to 62% busy.

🧮 Linux: texture binding no longer re-hashes every car's cube map at every draw

• Each car's small ambient cube map was checked for changes at every draw that bound it, by hashing
  its six faces byte by byte: in a race on a Steam Deck, about 87% of the time spent binding
  textures, itself about 13% of the graphics thread. It is now checked once a frame, as the texture
  cache checks a texture, and hashed 8 bytes at a time: texture binding fell to about 0.2% of all
  the CPU time. The cars look the same.

⚡ Linux on small CPUs: the graphics thread naps instead of spinning while it waits for SPU work

• GT5's SPU jobs fill gaps in the graphics command stream, and the graphics thread waits at each gap
  (on a Steam Deck about 1,000-1,400 times a second in a race). It watches the gap so it carries on
  the moment it is filled, yielding between looks; on Linux that yield returns at once when nothing
  else is queued on the core, so the wait was a spin, about a fifth of the thread's time, on cores
  the SPU threads filling the gaps could have used.
• With 8 logical CPUs or fewer it now watches for the first 30 us, then naps 50 us between looks: a
  short wait still ends at once, a longer one at most 50 us late. GCM_FIFO_NAP=0 spins as before,
  =1 naps on any CPU.
• On a Steam Deck over the same ~70 s of a race: the graphics thread 70% to 56% busy, frames about
  135 to 110 ms on average (82-100 ms on the faster stretches).

🧊 Linux: the shader cache survives updates

• Each cached shader was stamped with the time its translator was built, and any other stamp counted
  as stale. Every update re-patches and rebuilds that code, so after every update the whole cache was
  thrown away and the next races compiled every shader again (on a Steam Deck, close to half the
  graphics thread for minutes). The stamp is now a version number, raised when the translator's
  settings change; the shader text and the glslang version still decide a hit as before.
• Checked on a Steam Deck: after the translator code was rebuilt, the menus wrote 7 shaders instead
  of all 295 again. Caches written by older builds miss once, the first time.

🌗 Linux: race shadows read on the GPU, and the dark band ahead of the car is gone

• GT5 reads its 1024x2048 shadow map as a 16-bit depth texture twice a race frame. The Vulkan
  renderer could convert depth on the GPU only for the other way GT5 reads depth, so each read
  waited for the GPU, copied the depth back, converted it on the CPU and uploaded it again. Now a
  compute pass rounds every depth to 16 bits on the GPU, in command order, exactly as the CPU did
  (round(d * 65535) in 32-bit integers), into the R16 texture the texture unit samples.
• The shadow map is drawn in three bands of 682 rows, and only the last band counted as drawn, so
  the copy through memory carried that band alone; the other two came from stale memory, which
  showed as a darker band a little ahead of the car. All three bands are read now.
• On a Steam Deck in a race: time waiting for the GPU from about 1.6-2.1 to 0.7-0.9 s per 5 s, the
  depth readbacks gone, frames about 113-143 ms.

⚡ Linux: races about 30% faster on a Steam Deck (the CPU and GPU now work at the same time)

• The Vulkan renderer waited for the GPU after every batch of draws and at every present, so the
  walker idled while the GPU drew and the GPU idled while the walker recorded the next batch (a Steam
  Deck's GPU went from 100% to 0% in turns). Now up to three batches are in flight, each with its own
  command buffer, fence, descriptor pool, share of the vertex, index, uniform and upload rings and
  list of objects to destroy; a full batch or a present is submitted and recording carries on. Only
  what needs the GPU done still waits for it: readbacks, destroying objects, the engine's own wait.
  VK_ASYNC_FLUSH=0 brings back a wait after every batch.
• The present isn't waited on either: the next present finishes it, so the window shows a frame when
  the next one is presented.
• 16-car races kept only 8 of the cars' small ambient cube maps, so they evicted each other every
  frame, and each miss created a texture and decoded the cube again (about 7 a frame). Now 64 are
  kept: texture creations in a race went from 259 to 2 per 5 s.
• On a Steam Deck (OLED, SteamOS 3.9), same race: frames ~175-185 ms to ~122-127 ms (about 5.5 to
  8.3 a second), time waiting...