[PR #2920] [CLOSED] (Attempted) Fix buffer memory tracking in case of composite buffers #3084

New issue

Closed

opened 2026-02-27 22:02:23 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 22:02:23 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/shadps4-emu/shadPS4/pull/2920
Author: @mikusp
Created: 5/12/2025
Status: ❌ Closed

Base: main ← Head: fix_composite_buffer_memory_tracking

📝 Commits (1)

1316720 Fix buffer memory tracking in case of composite buffers

📊 Changes

1 file changed (+1 additions, -1 deletions)

View changed files

📝 src/video_core/buffer_cache/word_manager.h (+1 -1)

📄 Description

This is not a proper solution

What I've found during testing is a situation that causes the assert of 'Attempted to track non-GPU mapped memory...". Prerequisites are as follow:

there is a pooled area mapped that spans exactly the buffer size
there is a composite buffer used by one of the shaders, bound with varying offsets

As an example, a game maps a pooled area at 0x2052c00000 with size 0x280000. Then a shader uses three V#s pointing into this buffer: one with base 0x2052c00000 and dfmt Format32_32_32, one with base 0x2052c0000c and dfmt Format16_16 and one with base 0x2052c00010 and dfmt Format8_8_8_8. All of them specify stride 0x14 and size 0x280000 (exactly the pooled area).

The problem arises when the size calculation does not take into account the offset and element size, using only stride and num_records. When the time comes to track the buffer's memory, it adds the calculated size to the base address, and aligns the result up to the page boundary. In this case, 0x2052c0000c + 0x280000 will spill over the pooled area and cause the assert trying to protect page outside the mapped memory,

I've tried fixing the size calculation itself but it seemed to work worse, like some logos when Resident Evil 2 boots were not visible 🤔

The same problem can happen with Image resources, but the underlying issue is different. Please test and let me know your thoughts

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/shadps4-emu/shadPS4/pull/2920 **Author:** [@mikusp](https://github.com/mikusp) **Created:** 5/12/2025 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix_composite_buffer_memory_tracking` --- ### 📝 Commits (1) - [`1316720`](https://github.com/shadps4-emu/shadPS4/commit/131672066aeb8ed91036c37611c8b6702d56520e) Fix buffer memory tracking in case of composite buffers ### 📊 Changes **1 file changed** (+1 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `src/video_core/buffer_cache/word_manager.h` (+1 -1) </details> ### 📄 Description This is _not_ a proper solution What I've found during testing is a situation that causes the assert of 'Attempted to track non-GPU mapped memory...". Prerequisites are as follow: - there is a pooled area mapped that spans exactly the buffer size - there is a composite buffer used by one of the shaders, bound with varying offsets As an example, a game maps a pooled area at 0x2052c00000 with size 0x280000. Then a shader uses three V#s pointing into this buffer: one with base 0x2052c00000 and dfmt Format32_32_32, one with base 0x2052c0000c and dfmt Format16_16 and one with base 0x2052c00010 and dfmt Format8_8_8_8. All of them specify stride 0x14 and size 0x280000 (exactly the pooled area). The problem arises when the size calculation does not take into account the offset and element size, using only stride and num_records. When the time comes to track the buffer's memory, it adds the calculated size to the base address, and aligns the result up to the page boundary. In this case, 0x2052c0000c + 0x280000 will spill over the pooled area and cause the assert trying to protect page outside the mapped memory, I've tried fixing the size calculation itself but it seemed to work worse, like some logos when Resident Evil 2 boots were not visible 🤔 The same problem can happen with Image resources, but the underlying issue is different. Please test and let me know your thoughts --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>