mirror of
https://github.com/shadps4-emu/shadPS4.git
synced 2026-04-25 15:56:00 +03:00
[GH-ISSUE #4049] [GAME BUG]: The Gravity Rush 2 renders a downsized copy of the scene in the top‑left quarter of the screen, creating a recursive feedback effect. #1208
Labels
No labels
Bloodborne
bug
contributor wanted
documentation
enhancement
frontend
good first issue
help wanted
linux
pull-request
question
release
verification progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/shadPS4#1208
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @wuguo13842 on GitHub (Feb 18, 2026).
Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/4049
I'm sorry, my English is not very good, the text is generated by "ai", I'm sorry.!
I'm not very familiar with the process on GitHub, sorry.
Do you want me to grab any more information?
Checklist (we expect you to perform these steps before opening the issue)
Describe the Bug
I'm experiencing a "picture-in-picture" rendering issue exclusively on my NVIDIA RTX 2070 Ti (Windows) while testing Gravity Rush 2 with this PR (gr2fix branch). The problem does not occur on AMD GPUs or Linux systems according to user reports.
Description
The game renders a downsized copy of the scene in the top‑left quarter of the screen, creating a recursive feedback effect. The rest of the screen renders correctly.
Investigation so far
The fragment shader that blends the depth‑of‑field layer uses correct full‑screen UV coordinates.
The compute shader (hash 0x8503bcb7) writes a full‑screen texture but only processes pixels whose coordinates are less than two values read from ssbo_1 at indices 4 and 5.
The original values at those indices are 1920.0 and 1088.0 (as floats). Even after forcing them to 4096.0 (to cover the whole screen), the problem persists.
Logs confirm that the forced values are successfully written.
This suggests the issue may lie elsewhere – possibly a missing memory barrier, incorrect image layout transition, or resource aliasing that only manifests on NVIDIA drivers.
Steps to reproduce
Build this PR on Windows with an NVIDIA GPU.
Launch Gravity Rush 2 and observe the top‑left corner after the first few frames.
I've attached relevant logs showing the forced buffer writes. Any insight or guidance on further debugging would be greatly appreciated. Thanks!
is RenderDoc file here
https://1drv.ms/u/c/76f2fe0b033370d0/IQDQBFqC2Yu5SafVTR9YW2c7AUZ2Do3FzaDERknHSLaFSPQ?e=d653BN
https://1drv.ms/u/c/76f2fe0b033370d0/IQDA57nZJEUIRoMFCp6v_DyjAeJFSS2lT-xzRF9ZFdE4rl8?e=6maewH
CUSA04934.log
Do you want me to grab any more information?
Reproduction Steps
After setting up the compilation environment on Windows and successfully compiling, I attempted to modify the code to fix some errors in the repair log. While some fixes succeeded, unfortunately, they were unrelated to the issue at hand.
I began analyzing the image cache and RenderDoc data, but due to limited capabilities, my attempts at modification consistently failed.
Specify OS Version
Windows 11 26100.4202
CPU
4790k
GPU
NVIDIA RTX 2070 Ti
Amount of RAM in GB
32G
Amount of VRAM in GB
8G
Log File
CUSA04934.log
Do you want me to grab any more information?
@wuguo13842 commented on GitHub (Feb 18, 2026):
However, the second report is unverified and may be inaccurate—it could refer to AMD graphics cards on Linux instead.
@wuguo13842 commented on GitHub (Feb 19, 2026):
Oh, and one more thing—I saw a fix for Nvidia's picture-in-picture issue in the commit history. Compiling it myself and forcing it to run on “Gravity Rush 2” didn't solve the problem.
@Randomuser8219 commented on GitHub (Feb 19, 2026):
The whole issue is because IMAGE_MIP_STORE is not implemented on NVIDIA.
@wuguo13842 commented on GitHub (Feb 19, 2026):
I figured it out—the emulator leverages AMD's proprietary “VK_AMD_shader_image_load_store_lod” API for hardware acceleration.
The emulator doesn't include VK API support code for Nvidia cards.
NVIDIA 驱动不支持 VK_AMD_shader_image_load_store_lod ,我们确实不应该再纠结于修改着色器代码去“模拟”显式 LOD 写入,而是应该利用 NVIDIA 硬件原生支持的标准 Vulkan 功能来实现同样的目标:为纹理生成完整的 mip 链。
以下是三种完全基于 NVIDIA 硬件支持的替代方案,您可以评估哪个更适合集成到模拟器中
VK_AMD_shader_image_load_store_lod extension. Since your current code tries to use this AMD-specific extension, it fails on NVIDIA hardware, leading to the "画中画" (picture-in-picture) effect. The solution is to stop relying on this unsupported extension and instead use standard Vulkan features that are fully supported on NVIDIA.
Here is a comparison of three alternative solutions that use NVIDIA's native capabilities. Please review them and tell me which one you would like to implement.
@wuguo13842 commented on GitHub (Feb 19, 2026):
### Insufficient capacity to solve problems,It cannot be solved
image.h
bool generated_mip_chain = false;@wuguo13842 commented on GitHub (Feb 20, 2026):
Evaluation Report: Integrating Mip Chain Generation into the Standard Pipeline
Core idea: Automatically detect all images that require mip chain generation before the scheduler submits a command buffer, and insert vkCmdBlitImage commands accordingly.
Foundation:
The texture cache already tracks image states (layout, access masks) and can be extended to record a "needs mip generation" flag.
The scheduler can be extended with a pre-submit hook, allowing the texture cache to inject extra commands just before finalizing the command buffer.
Existing barrier management functions like Image::Transit can safely perform layout transitions.
Key challenge: Ensuring the mip generation happens at the correct time (after writes, before sampling) without disrupting concurrent rendering.
Estimated Workload 📊
Module Changes Complexity
Scheduler Add pre-submit callback list; call before Flush or Submit Low
Image class Add needs_mip_gen and mip_chain_valid flags; implement GenerateMipChain() Medium
Texture Cache Set flags when images are written (e.g., Upload, CopyImage, compute shader writes) Medium-High
Synchronization Ensure correct layout transitions before and after mip generation Medium
Thread safety Protect flags with locks or atomics Low
Total: Approximately 300–500 lines of code across multiple files, but with clear logic and modular implementation.
Potential Benefits 🌟
Permanent fix: Solves the current picture-in-picture issue and prevents similar problems in future games.
Eliminates image copying: The new design shares physical resources for images at the same address, removing the need for CopyImage and thus eliminating device loss risks.
Code robustness: Integrates ad‑hoc patches into a system‑level feature, improving maintainability.
Cross‑vendor compatibility: Automatically generates mip chains for hardware that lacks LOD write support (e.g., NVIDIA) while preserving the native path for AMD.
Performance overhead: Scanning all images and checking flags each frame → can be optimized with lazy marking and generating only once after the first write.
Synchronization errors: The image may be in an incompatible layout during mip generation → use Transit to enforce correct layout, adhering to Vulkan rules.
Data consistency: Multiple views sharing the same physical image may be affected → ensure all writes to any view are completed before generation (using barriers).
Device loss: Incorrect generation commands could crash the driver → add thorough validation and test incrementally.
Phased approach:
Phase 1: Add flags and methods to Image, and implement the pre‑submit hook in the scheduler (test without actual command insertion).
Phase 2: Set needs_mip_gen in the texture cache when an image is written (e.g., Upload, CopyImage, compute shader writes).
Phase 3: In the pre‑submit hook, call Image::GenerateMipChain() and insert the necessary barriers and blits.
Phase 4: Remove the old per‑shader patch code and fully enable the new mechanism.
Testing strategy:
Run the affected game on NVIDIA hardware to verify the picture‑in‑picture disappears and no crashes occur.
Regression test on AMD hardware to ensure performance is unaffected and functionality remains correct.
Use RenderDoc to capture frames and verify that mip chains are generated correctly.
Code reuse: The existing GenerateMipChainForImage function can be moved directly into the Image class with minor adjustments.
Strongly recommended to implement this refactoring. Although it requires a moderate amount of work, it is the most fundamental solution to the current problem and will significantly improve the emulator’s stability and cross‑platform compatibility. Compared to continuously applying ad‑hoc patches, this is a worthwhile technical investment.
@wuguo13842 commented on GitHub (Feb 20, 2026):
🔥 Fundamental Solution: Refactoring the Texture Cache from the Ground Up
After multiple attempts, we have identified the root cause: different GPUs handle image aliasing differently. AMD drivers may automatically handle certain incompatible aliasing cases, while NVIDIA strictly follows the Vulkan specification, causing our copy operations to fail. To solve this permanently, we need to redesign the texture cache architecture so that it no longer relies on copying, but instead leverages Vulkan's image view mechanism and smarter metadata management.
🎯 Core Design Principles
Avoid Copies: Whenever possible, let different image requests share the same vkImage object, providing different views via vkImageView.
On-Demand Mip Chain Generation: When hardware does not support LOD writes, automatically generate the full mip chain the first time the image is sampled.
Precise Usage Tracking: Record each image's use cases (sampling, render target, storage) to decide whether mip generation is needed.
Lazy Binding: The actual Vulkan resources can be created only at first use, avoiding premature allocation.
Metadata-Driven: Decouple image properties (format, size, mip levels, etc.) from the Vulkan resource, allowing one resource to have multiple views.
@LorenzoFerri commented on GitHub (Feb 25, 2026):
This is marked as completed, is it fixed? I'm experiencing the same on an RTX 4080, latest emulator build
@StevenMiller123 commented on GitHub (Feb 25, 2026):
Will be fixed soon, but isn't fixed yet.
Pretty sure this got closed because we blocked the issue author, though we don't generally do that.
@CorpseSlayer commented on GitHub (Feb 26, 2026):
Suddenly Gravity Rush 2 stop loading saves when pressing continue this is in the latest nightly release.
Error:
[Lib.AvPlayer] (BGFiberWorkerSys) avplayer_source.cpp:271 Stop: Could not stop playback: already stopped.
@a857313401 commented on GitHub (Feb 27, 2026):
https://github.com/shadps4-emu/shadPS4/actions/runs/22388110449
你可以用这个分支核心,解决了1/4左上角重影的问题,但是EP3通过第一个试炼后依旧会卡死