[EagleBearerYS]

What

An optional scaler for the presented image: AMD FidelityFX Super Resolution 1.0, EASU upscaling plus RCAS sharpening. ANYPS5_UPSCALE=fsr turns it on. The default stays today's bilinear scaler.

No title needs this to run, and nothing changes unless it's set. With ANYPS5_UPSCALE unset, no upscaler object exists. The present path records exactly what it records today, and a test checks the output is bit-identical.

Where it helps: a display buffer shown in a larger window, for example a 1920x1080 buffer in a 2560x1440 or 3840x2160 window, which today is a bilinear stretch. Here is Planet of Lana (PPSA19450) with platform-ps5-video-out-width=1920 in its app0/Media/boot.config, maximized on a 2560x1440 panel, where the 1920x1080 buffer is presented at 2372x1334. The main menu at 1:1, bilinear on the left and FSR at the default sharpness 0.2 on the right:

The crops on their own: bilinear and FSR. The full frames: bilinear and FSR. That one-line edit of the title's own data file isn't part of this PR. megood's run of Bendy and the Ink Machine at 1920x1080 in a larger window, shared in the AnyPS5 Discord dev chat, is what pointed us at Unity's resolution settings. Titles that present 3840x2160 buffers in play, such as Resident Evil Village (PPSA01556) and Animal Well (PPSA22520), keep today's scaler in any smaller window, since FSR stays off where it can't upscale.

How to try it on a title: for Planet of Lana (PPSA19450), set platform-ps5-video-out-width=1920 in the dump's app0/Media/boot.config (it ships with 3840), run it in a window larger than 1920x1080, and compare ANYPS5_UPSCALE unset with ANYPS5_UPSCALE=fsr. Other Unity titles may have the same line, but none has been checked yet.

The test's synthetic pattern shows the difference in numbers. It's a 960x540 pattern upscaled to 1920x1080, shown as a 320x180 crop at 2x, with bilinear on the left and FSR at 0.2 on the right:

The one-pixel grid lines peak at 179 under bilinear and at 219 with FSR (the source line is 230). A 51/204 edge goes 89 → 166 under bilinear and 65 → 190 with FSR.

Sharpness 0.2 (left) against 2.0, the weakest (right). EASU is the same in both; RCAS's halo is 5-9 levels at 0.2 and 1 level at 2.0:

The whole synthetic FSR frame at half size, for context: image. These three are rendered by this PR's own code on lavapipe.

How:

• ANYPS5_UPSCALE and ANYPS5_FSR_SHARPNESS (0.0 sharpest to 2.0 weakest, default 0.2) are read once when the window's device is created, like ANYPS5_PRESENT_MODE. An empty value is the same as unset; any other bad value stops the start with a message naming the variable.

• With fsr, a presentation whose fitted image is larger than the display buffer on either axis goes through FSR:

  • present() renders today's output at the buffer's own size into a per-slot stage image;
  • EASU (FsrEasu.frag) scales it to the fitted size;
  • RCAS (FsrRcas.frag) sharpens it into the swapchain image, with the black letterbox around it.
    This covers the drawn, direct and shared present paths. Clear-only presents skip it.

• With the performance overlay (feat(agc,videoout): show an optional performance overlay with F10 #6012) on: RCAS ends in COLOR_ATTACHMENT_OPTIMAL, and the overlay records from there when the frame was drawn or upscaled. Otherwise the overlay records from TRANSFER_DST_OPTIMAL as it does today. The overlay's entry dependency orders it after RCAS's writes, so its text is neither scaled nor sharpened.

• Where it can't upscale (1:1 or a smaller window), FSR stays off for that frame, which is presented exactly as without ANYPS5_UPSCALE. RCAS alone would cost frame rate there without adding detail.

  • On lavapipe it costs 2.8x today's blit at 2560x1440.
  • Before this gate, Planet of Lana (PPSA19450), showing a 3840x2160 buffer in a 1084x610 window, dropped from 12.05 to 5.75 fps with RCAS alone.
  • On lavapipe the cost shows up as draws waiting while the presentation holds the GPU mutex, since QueuePresent waits for the presentation's rendering inside it.
  • FSR's start line says so: [present] ANYPS5_UPSCALE=fsr: FSR 1 EASU and RCAS when the window is larger than the display buffer, the normal scaler otherwise; RCAS sharpness 0.20.

• HDR10 (feat(videoout): present PQ display buffers through an HDR10 swapchain #5697) and SDR: FSR runs on the values the display receives, sRGB-encoded for SDR and PQ code values for HDR10, never on linear light. Both are perceptual encodings, which is what FSR 1 expects. EASU's deringing keeps each output inside its 2x2 neighbourhood. RCAS limits its negative lobe to stay inside [0, 1], and the shader clamps its result to [0, 1] after AMD's approximate reciprocal, so PQ output stays a valid code.

• Cost when upscaling: two images per presentation in flight (7.9 + 31.6 MiB per slot for a 1080p buffer in a 4K window) and two extra passes per frame. The table gives FSR's GPU time per frame (the stage write, EASU and RCAS) against today's bilinear blit, as the median over 200 frames from agc_driver_presentation_pass_tests --fsr-cost. The times are GPU timestamps of 200 back-to-back frames after 20 warm-up frames, offscreen with no other GPU work. The RTX 3070 column is from this head. Its clocks weren't held: during the measured frames nvidia-smi (every 100 ms) showed it in P3 and P0, at 780 to 945 MHz graphics and 5,501 to 6,001 MHz memory. So these are mid-clock figures, upper bounds for both passes at full clock. FSR and the blit were timed in the same frames at the same clocks, so the comparison is like for like at those clocks. lavapipe runs on the CPU, so only its ratios mean anything. Recording FSR costs 45-55 µs of CPU per frame on the RTX 3070 when it upscales (median; 89-101 at p95), against 3-4 µs for the blit.

  Case	RTX 3070 Laptop: FSR / blit, median (p95)	lavapipe: FSR / blit
  1920x1080 into 2560x1440	0.53 (0.55) / 0.07 (0.08) ms	74.3 / 7.8 ms
  1920x1080 into 3840x2160	1.13 (1.19) / 0.14 (0.15) ms	165.2 / 16.8 ms
  1280x720 into 3840x2160 (EASU beyond 2x)	1.33 (1.33) / 0.14 (0.14) ms	153.6 / 16.1 ms
  1920x1080 or 3840x2160 at 1:1, 3840x2160 into 2560x1440	FSR off: the blit alone	FSR off: the blit alone

  The cost mode measures RCAS alone too, which is what FSR would run where it can't upscale. At 1920x1080 1:1 it costs 0.12 ms against the blit's 0.05 on the RTX 3070 (20.6 against 5.0 on lavapipe), at 3840x2160 1:1 0.46 against 0.20, and for 3840x2160 into 2560x1440 0.29 against 0.15 (34.7 against 9.2 on lavapipe). That gives no detail for the cost, so FSR stays off there.

  The shaders derive the EASU and RCAS constants per pixel from the sizes and the sharpness in their push constants, about 20 ALU per pixel; AMD's samples compute them once on the CPU, which would save that at the cost of a larger push-constant block. When off, the cost is two getenv calls at device creation and one bool per present.

Things to know:

• EASU is designed for up to twice the display buffer's size on each axis. Larger factors, such as a 1280x720 buffer in a 3840x2160 window, still work but look softer.
• RCAS normalizes with AMD's approximate reciprocal (APrxMedRcpF1), so it darkens flat areas by a fixed fraction of their value that depends only on the sharpness: 0.17% at the default 0.2 (0.5 → 0.4992), 0.32% at 0.0 and 0.07% at 2.0. That's at most one 8-bit level in SDR and three 10-bit codes in HDR10. Fixing it would mean editing AMD's header, so it's left as is; USAGE says so, and the tests bound it.
• 2.0 is RCAS's weakest setting, not off. With fsr selected, RCAS always runs.
• An invalid ANYPS5_FSR_SHARPNESS stops the start even without fsr, like any invalid setting.
• When the window shrinks from larger than the display buffer to smaller, each presentation slot keeps its upscaled image until EASU runs again or the device is torn down: the window's size at 4 bytes a pixel, so about 33 MB per slot at 3840x2160.

Third-party code: the FSR headers are vendored, not a submodule, which departs from AGENTS.md's submodule rule. A maintainer agreed in the dev chat that vendoring these two headers is fine. 3rdparty/FidelityFX-FSR/ holds ffx-fsr/ffx_a.h, ffx-fsr/ffx_fsr1.h and license.txt (MIT), copied unmodified from tag v1.0.2 (a21ffb8f6c). Its README gives the source, the commit and each file's SHA-256.

• Why: every FSR 1 release tag carries two submodules for AMD's sample, Cauldron and Cauldron-Media. The project's recursive checkouts (CI, release.yml, BUILD.md) would fetch them: about 337 MB at depth 1 and 1.47 GB with full history, for 243 KB of headers. .gitmodules can't stop recursion into a submodule's own submodules.
• The three files match tag v1.0.2 byte for byte, and the README's SHA-256 table matches them.
• If a submodule is wanted after all, commit 1 switches and the include path stays the same.

Commits:

1. build(agc): the vendored FSR 1.0.2 headers and license, with the README.
2. feat(agc): PresentationUpscaler, UpscaleMode, the EASU and RCAS shaders, and the hooks into PresentationPass, PresentationScaler and VulkanDevice::present.
   • FSR runs only for presentations it can upscale (50aa233's gate).
   • The stage's render pass ends with a dependency that orders its writes and final layout transition before EASU and RCAS sample it (PresentationPass::ExitDependency, shared with the upscaler's passes).
   • With the performance overlay on, the overlay draws after RCAS, unscaled.
   • The three shader modules are created with Graphics::CreateShaderModule, as main's presentation pass and overlay create theirs.
   • docs/dev/ENVIRONMENT.md gets rows for ANYPS5_UPSCALE and ANYPS5_FSR_SHARPNESS.
   • USAGE gets its "Upscaling" section, after "Storing GPU results at each flip".
3. test(agc): agc_driver_presentation_fsr, with the exit dependency's three layouts; agc_driver_present_upscale, which presents through VulkanDevice on a headless surface in all four combinations of FSR and the overlay and counts the presentations that ran FSR; and agc_performance_overlay's over-FSR case.
4. test(agc): the --fsr-cost mode of agc_driver_presentation_pass_tests (30febcf), not registered with ctest.

Tested

• Planet of Lana (PPSA19450) with platform-ps5-video-out-width=1920 in app0/Media/boot.config, built at this head, on the RTX 3070 Laptop GPU (driver 617.42, Windows 11), maximized on a 2560x1440 panel, with the performance overlay on. Six runs: four in the order bilinear, FSR, FSR, bilinear, then a later pair, FSR then bilinear (ANYPS5_UPSCALE unset or fsr). Clocks weren't held; nvidia-smi logged them every second.

  • The log has guest 1920x1080 presented at 2372x1334, and with fsr the start line [present] ANYPS5_UPSCALE=fsr: FSR 1 EASU and RCAS when the window is larger than the display buffer, the normal scaler otherwise; RCAS sharpness 0.20. The performance overlay reads RES: 1920X1080 / 2560X1334.

  Run	Main menu, +90 to +150 s	In play, +420 to +500 s
  1, bilinear	26.8 fps (GPU 33%, median 870 MHz; P0 42%, P3 38%, P5 19%)	16.2 fps (GPU 30%, 885 MHz; P0 38%, P3 28%, P5 33%)
  2, FSR	28.2 fps (GPU 32%, 975 MHz; P0 78%)	12.7 fps (GPU 33%, 765 MHz; P5 75%)
  3, FSR	38.0 fps (GPU 36%, 1,185 MHz; P0 83%)	not measured (the Controls screen, not play)
  4, bilinear	36.4 fps (GPU 38%, 1,125 MHz; P0 80%)	18.3 fps (GPU 32%, 945 MHz; P0 61%)
  5, FSR	37.1 fps (GPU 44%, 930 MHz; P0 14%, P3 85%)	19.3 fps (GPU 34%, 930 MHz; P0 76%, P3 19%, P5 3%)
  6, bilinear	34.8 fps (GPU 37%, 1,050 MHz; P0 82%, P3 17%)	21.7 fps (GPU 34%, 930 MHz; P0 90%, P3 6%, P5 3%)

  • Main menu: FSR was ahead of bilinear in all three pairs, by 5% (28.2 against 26.8), 4% (38.0 against 36.4) and 7% (37.1 against 34.8). The pairs ran at different clocks from one another, so each comparison is within its pair, and in the third the two arms' clocks differed too (FSR mostly in P3, bilinear mostly in P0).
  • In play, the pair at similar clocks is runs 5 and 6: both at a 930 MHz median, mostly in P0 (FSR 76%, bilinear 90%; clocks weren't locked), and captures at +420 s show both in play. FSR ran at 19.3 fps against bilinear's 21.7, about 11% lower. That's FSR's cost in this scene in that one pair. The first pair's larger gap (12.7 against 16.2) had the FSR run in P5 for 75% of its window, so it mixes in the clock state. Run 3's play window reached the Controls screen instead of play.
  • The 1:1 menu crops above show FSR visibly sharper than bilinear.

• agc_driver_presentation_fsr (Vulkan; it runs agc_driver_presentation_pass_tests --fsr) covers:

  • upscale-mode parsing;
  • EASU from 960x540 to 1920x1080 on edges, a thin-line grid and a gradient: no NaN or Inf, values in [0, 1], flat regions flat, the gradient monotonic, and a 10-90% edge rise of 1.52 px against 2.20 for bilinear, across vertical and horizontal edges;
  • RCAS at 1:1: at sharpness 2.0 the image changes by at most 0.024; at 0.2 edge contrast goes from 0.2331 to 0.2482; flat areas stay uniform;
  • the default path: with ANYPS5_UPSCALE unset the output is bit-identical, and the stage equals today's fitted image when FSR doesn't upscale;
  • SDR and HDR10 presents: B8G8R8A8 flat greys within one code; a PQ checkerboard into A2B10G10R10 at sharpness 0 gives valid codes, a flat region stays flat, and the letterbox is black.

• agc_driver_present_upscale presents through VulkanDevice on a VK_EXT_headless_surface swapchain (1084x610) and counts the presentations that ran FSR. With fsr, 3840x2160, 1084x610 and 1920x1080 buffers don't run it and a 960x540 buffer does; with the variable empty, nothing does. With the gate removed it fails: "FSR ran on a 3840x2160 display buffer in a 1084x610 window, where it cannot upscale". It skips where the extension is missing.

• Linux, CI's Linux job (Ubuntu 24.04, GCC 13.3, CI's configure flags, lavapipe, an unprivileged user), at the head, against main 7e69be6 built the same way:

  • 1,864 of 1,868 tests pass, against 1,862 of 1,866 on main.
  • Per test, every test on main has the same status here. The two new tests, agc_driver_presentation_fsr and agc_driver_present_upscale, pass.
  • The 4 failures are the same on both: that machine's three IPv6 socket tests, and guest_net_buffer_validation, which fails on main there too.
  • check_test_registration.py finds nothing unregistered on either. check_skips.py flags only guest_sce_net on both, as on every branch on that machine.
  • Each of the four commits builds and passes the presentation and overlay tests that exist at it, headless and under Xvfb.
  • agc_driver_presentation_pass, agc_driver_presentation_fsr, agc_driver_present_upscale, agc_performance_overlay and agc_performance_overlay_statistics pass 10 of 10, headless and under Xvfb.

• Validation with VK_LAYER_KHRONOS_validation and synchronization validation. The layer reports a planted write-after-write hazard on that machine, so validation was on.

  • Setup: Xvfb at 1920x1080. The 18 VideoOut and presentation tests that CTest runs offscreen ran again on X11, in a window larger than their buffers, so EASU runs. For example, video_out_hdr_present's 259x137 buffer is presented at 1152x609.
  • Tests: the presentation, present-upscale, overlay and VideoOut display tests: 43 here and 41 on main, plus the 18 on X11.
  • Configurations: main, then this PR unset, with fsr, with fsr at sharpness 2.0, and with fsr and the performance overlay on (ANYPS5_OVERLAY=1).
  • Messages: the only one in any configuration is VUID-VkDeviceCreateInfo-pNext-pNext, once per device, from a device struct that layer version doesn't know. Every test main has gets the same count here. The 6 extra come from agc_driver_present_upscale, which opens a device per case.
  • No synchronization hazard appears, and no other message of any severity. Before H1's fix, agc_driver_presentation_fsr had 10.
  • Pass and fail are the same in all five.
  • Where FSR ran: with fsr, FSR's start line appears 13 times in each configuration, from video_out_hdr_present, six guest_video_out_* tests, agc_driver_present_upscale and three X11 flip and frame-dump tests. With the overlay on as well, the overlay tests pass, and the screen capture below shows the overlay drawn over an FSR presentation.

• Off is bit-identical on screen too: X screen captures at the third present of video_out_hdr_present, compared pixel by pixel.

  • With ANYPS5_UPSCALE unset, main and this PR differ in 0 of 2,073,600 pixels, in three capture pairs.
  • With the overlay on and FSR unset, they differ only inside the overlay panel's numbers: 151 and 130 pixels, against 171 and 128 between two runs of the same tree. With the panel painted out, they differ in 0.
  • With fsr, 679,356 pixels differ, all in the presented image: the frame is sharper at the band edges. Adding the overlay to fsr changes only the panel (11,023 pixels).

• GitHub's runners at 672308b (run): the presentation, present-upscale and overlay tests pass 10 runs in a row on Linux, with none skipped. On Windows they build and pass, with 5 of the 8 skipping: the runner has no Vulkan device, so the RTX 3070 run below covers those. The libc and libkernel suites pass on both, run with APS5_SKIP_TIMING_TESTS=1, which relaxes precise_wait's median bounds on GitHub's hosted runners.

• Validation, main against this PR, on GitHub's Linux runner (run): VK_LAYER_KHRONOS_validation with ANYPS5_NO_SHADER_CACHE=1 and ANYPS5_REQUIRE_VULKAN=1 on llvmpipe, for the same tests plus agc_driver_image_table_vouched_lookups. The loader inserted the layer 5 times on main and 12 with this PR. Both logs report only VUID-VkDeviceCreateInfo-pNext-pNext, so this PR adds no VUID- message.

• RTX 3070 Laptop GPU at this head (driver 617.42, Windows 11 10.0.26300), offscreen, no other GPU work: agc_driver_presentation_pass (3.7 s), agc_driver_presentation_fsr (10.9 s) and agc_performance_overlay (2.5 s) pass. agc_driver_present_upscale skips: NVIDIA's Windows driver has no VK_EXT_headless_surface, which it needs. The figures match lavapipe's: EASU's edge rise is 1.52 px against bilinear's 2.20 on both axes, RCAS at sharpness 2.0 changes the image by at most 0.0241, and edge contrast goes 0.2331 → 0.2482 at 0.2. The tests take the first Vulkan device, which on this laptop is the integrated GPU, so the loader was limited to NVIDIA's driver for that run. The cost mode (--fsr-cost) gives the RTX 3070 column above.

• HDR10 is tested at the component level only: no HDR10 swapchain was available. lavapipe's offers only SRGB_NONLINEAR, and this PC's displays run SDR.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt (AMD's headers are vendored as they are)
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source, except AMD's two FSR 1 headers and license, which are vendored, as a maintainer agreed in the dev chat (see above)
• Generic behaviour, not specific to one title
• Depends on: fix(agc): bound the sampled depth-plane copies #7705, feat(agc): toggle runtime switches in alternating phases of one run #8160, feat(tools): split the periodic reports of an APS5_AB run by phase #8161, fix(agc): recognise the copy kernel as Demon's Souls 01.007.000 compiles it #8552, feat(relinker): trace function imports on macOS #9408 (merge order only, see Overlap)
• Unblocks: none (an opt-in scaler; no title needs it to run)
• GPUs tested: NVIDIA GeForce RTX 3070 Laptop GPU (driver 617.42, Windows 11 10.0.26300; the tests offscreen and Planet of Lana (PPSA19450)); lavapipe (Mesa 25.2.8, LLVM 20.1.2, Ubuntu 24.04)
• AI-assisted: yes

Overlap:

• The performance overlay, feat(agc,videoout): show an optional performance overlay with F10 #6012 (ours), is merged. This PR composes with it in VulkanDevice::present (commit 2) and covers both on together (commit 3), as described under How.
• Open PRs this one conflicts with (merge-tree of each head against this one, 2026-10-23), each a small textual conflict:
  • fix(agc): bound the sampled depth-plane copies #7705 (AnthonyClemens, bounded depth-plane copies), feat(agc): toggle runtime switches in alternating phases of one run #8160 and feat(tools): split the periodic reports of an APS5_AB run by phase #8161 (Celegans12, A/B runtime switch phases and their reports): rows at the same place in docs/dev/ENVIRONMENT.md.
  • fix(agc): recognise the copy kernel as Demon's Souls 01.007.000 compiles it #8552 (Sam-mon7, Demon's Souls copy kernel): neighbouring lines in libSceAgcDriver/CMakeLists.txt.
  • feat(relinker): trace function imports on macOS #9408 (rursache, relinker import tracing on macOS): neighbouring sections in docs/user/USAGE.md.
  • perf(agc): GPU descriptor heap on VK_EXT_descriptor_heap (APS5_GPU_HEAP) #9508 (Raghav314, GPU descriptor heap): one declaration in PresentationPass.hpp. perf(agc): GPU descriptor heap on VK_EXT_descriptor_heap (APS5_GPU_HEAP) #9508 makes draw()'s Slot& non-const, and this PR adds recordInto() next to it; both apply.
• Merge order: this PR goes after fix(agc): bound the sampled depth-plane copies #7705, feat(agc): toggle runtime switches in alternating phases of one run #8160, feat(tools): split the periodic reports of an APS5_AB run by phase #8161, fix(agc): recognise the copy kernel as Demon's Souls 01.007.000 compiles it #8552 and feat(relinker): trace function imports on macOS #9408, and adds its rows and lines next to theirs when it merges main. Against perf(agc): GPU descriptor heap on VK_EXT_descriptor_heap (APS5_GPU_HEAP) #9508, which is much larger, it can go first; if perf(agc): GPU descriptor heap on VK_EXT_descriptor_heap (APS5_GPU_HEAP) #9508 lands first, this PR keeps its non-const Slot&.

[MarcZX10]

Reviewed the current implementation and reported validation for head 672308b453c902d8434842e8bb8e9779eba33da3. The feature has substantial focused coverage and evidence across lavapipe and the RTX 3070, including default-off bit identity and presentation-path checks. One integration blocker remains: check_main_sync.py shows this head is 4 ahead/209 behind fetched upstream/main at 0db47b263, with four changed paths also modified after the merge base: core/libs/prx/libSceAgcDriver/CMakeLists.txt, Execution/src/VulkanDevice.cpp, and both usage/environment docs. The reported full Linux suite and tests are on base 7e69be679, so they do not establish the combined current-main tree. Please rebase/merge current main, resolve these shared paths, rerun overlap and the focused presentation/upscale/overlay/VideoOut tests on the resulting head, and report any changed failures. This request is for current-main integration evidence required by the repository contribution checklist; it is not about queue size. Local conventions pass; hosted checks currently cover policy only and skip product builds.

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
PR 10507	core/libs/prx/libSceAgcDriver/Execution/include/PresentationPass.hpp L5-6, L26-27, L58 core/libs/prx/libSceAgcDriver/Execution/src/PresentationPass.cpp L182-183, L282-287, L295-296 core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp L507-508, L730-731, L903, L3604-3605, L3647

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 1368	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 1395	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 1896	core/libs/prx/libSceAgcDriver/CMakeLists.txt docs/dev/ENVIRONMENT.md
PR 2434	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 4040	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 4072	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 4472	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 5021	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/user/USAGE.md
PR 5371	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 5441	core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 5925	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/user/USAGE.md
PR 6044	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6171	docs/user/USAGE.md
PR 6186	core/libs/prx/libSceAgcDriver/CMakeLists.txt docs/dev/ENVIRONMENT.md
PR 6187	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6188	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 6192	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6202	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 6209	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6280	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6300	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6412	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6481	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6501	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6617	docs/dev/ENVIRONMENT.md
PR 6642	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6808	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 6924	docs/dev/ENVIRONMENT.md docs/user/USAGE.md
PR 6960	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 6977	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 7048	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 7201	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 7223	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 7275	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 7369	core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 7449	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/dev/ENVIRONMENT.md
PR 7457	core/libs/prx/libSceAgcDriver/CMakeLists.txt docs/dev/ENVIRONMENT.md
PR 7484	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/dev/ENVIRONMENT.md
PR 7604	core/libs/prx/libSceAgcDriver/CMakeLists.txt docs/dev/ENVIRONMENT.md
PR 7618	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 7677	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 7814	docs/dev/ENVIRONMENT.md
PR 7918	docs/user/USAGE.md
PR 7922	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/dev/ENVIRONMENT.md
PR 7942	docs/user/USAGE.md
PR 8004	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/dev/ENVIRONMENT.md
PR 8014	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 8077	docs/dev/ENVIRONMENT.md
PR 8246	core/libs/prx/libSceAgcDriver/CMakeLists.txt docs/dev/ENVIRONMENT.md
PR 8365	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 8484	core/libs/prx/libSceAgcDriver/CMakeLists.txt docs/dev/ENVIRONMENT.md
PR 8542	core/libs/prx/libSceAgcDriver/CMakeLists.txt docs/dev/ENVIRONMENT.md
PR 8592	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 8999	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9348	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9356	core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/dev/ENVIRONMENT.md
PR 9387	core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/dev/ENVIRONMENT.md
PR 9400	core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/dev/ENVIRONMENT.md
PR 9431	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9432	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9508	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/include/PresentationPass.hpp core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/PresentationPass.cpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp core/libs/prx/libSceAgcDriver/tests/PresentationPass.cpp docs/dev/ENVIRONMENT.md docs/user/USAGE.md
PR 9521	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 9672	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9673	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9674	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9675	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9676	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/dev/ENVIRONMENT.md
PR 9748	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 9842	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9891	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9892	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9893	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9895	core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp
PR 9897	core/libs/prx/libSceAgcDriver/CMakeLists.txt
PR 9898	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/dev/ENVIRONMENT.md
PR 10193	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/include/PresentationPass.hpp core/libs/prx/libSceAgcDriver/Execution/include/VulkanDevice.hpp core/libs/prx/libSceAgcDriver/Execution/src/PresentationPass.cpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp core/libs/prx/libSceAgcDriver/tests/PresentationPass.cpp docs/dev/ENVIRONMENT.md docs/user/USAGE.md
PR 10194	core/libs/prx/libSceAgcDriver/CMakeLists.txt core/libs/prx/libSceAgcDriver/Execution/src/PresentationPass.cpp core/libs/prx/libSceAgcDriver/Execution/src/PresentationScaler.cpp core/libs/prx/libSceAgcDriver/Execution/src/VulkanDevice.cpp docs/dev/ENVIRONMENT.md
PR 10231	docs/dev/ENVIRONMENT.md
PR 10244	docs/dev/ENVIRONMENT.md
PR 10254	docs/dev/ENVIRONMENT.md
PR 10264	docs/dev/ENVIRONMENT.md
PR 10272	docs/dev/ENVIRONMENT.md

[EagleBearerYS]

@adriadam10 a question about the merge queue, since you wrote on #9790 that MarcZX10's CHANGES_REQUESTED blocks it until it's addressed. On this PR, and on #10159, his latest review asks only for a refresh against main and a rerun, with no defect in the change. Does a review like that still block the queue? If it does, we'll merge main and rerun on both before you get to them; if not, we'll leave the heads as they are until a conflict or your review asks for it.