Reverts overly restrictive storage buffer validation and size calculation
that was causing rendering issues in The Legend of Zelda: Tears of the
Kingdom, particularly in underground/depth areas. The simplified approach:
- Uses GetMemoryLayoutSize() instead of manual page probing
- Removes unnecessary 4GB memory bounds validation
- Streamlines address translation and alignment handling
This fixes numerous reported cases of missing or corrupted rendering in
TOTK's underground areas where storage buffer operations are heavily used
for depth-related effects.
- In commit b3facaa6bb, the copyright header was
updated to include "Citron Homebrew Project" across multiple files, regardless
of whether any contributions were made.
- This commit removes the incorrect attribution and reverts the copyright header
to its previous state.
- Copyright attribution should only be added when meaningful contributions have
been made to the file.
- This commit ensures proper compliance with copyright standards and maintains
correct attribution to the respective contributors.
- Special thanks to Tachi for pointing out the need for these corrections and
ensuring that proper attribution practices are followed.
Fixes the StorageBufferBinding function to properly handle memory validation
and size detection. Key changes include:
- Fix ReadBlock usage to properly handle void return values
- Implement safer memory validation using byte-level reads
- Improve size detection logic for storage buffers
- Fix NVN buffer size reading
- Add proper bounds checking for device memory addresses
- Add better error logging for invalid conditions
This addresses the "Failed to find storage buffer for cbuf index 0" errors
by implementing more robust memory validation and size detection. The changes
ensure proper handling of invalid memory addresses and prevent crashes from
accessing out-of-bounds memory.
Persistent buffer maps were already used by the texture cache, this extends their usage for the buffer cache.
In my testing, using the memory maps for uploads was slower than the existing "ImmediateUpload" path, so the memory map usage is limited to downloads for the time being.
