[soltros]

Longshot is preserving this upstream proposal for review. This draft is not an adopted or functionally verified fix.

Source: NotRexed/Hookshot#1132
Original contributor: wrocketdev.
Original head: e2ec9b84d0b176603a896652d955e2f4412aef01.
Exact source tree: f243a070d13d7bf178c6e1a822589e92ce939752.
Import parent: d224dc0680ad418b1ab111555c7d19cc483dcfdc (common ancestor with the migration base).

The source-tree checksum matches exactly. Original commits after the common ancestor are represented by one reconstructed import commit; source links and authorship are recorded. This snapshot can contain prerequisites beyond our migration base. Review its complete diff and overlapping proposals before merging.

Validation here: copying fidelity only. Platform builds, gameplay, functional behavior and the upstream author's claims have not been independently verified. Keep draft until reviewed, rebased and tested.

Original proposal

Draft, not tried in game. It is opt-in (RX_VK_MEMORY_PRIORITY=1), so nothing changes unless a player turns it on.
I am looking for players on 6-8 GB cards (NotRexed/Hookshot#993, NotRexed/Hookshot#995) to try it before it goes further.

Problem

On 8 GB cards the process sits at the driver's VRAM limit in Hyrule Field, Castle Town and Kakariko (NotRexed/Hookshot#993, NotRexed/Hookshot#995):
the logs show VRAM: ... used of ... allowed over the allowance. The driver then pages VRAM to system memory, and
nothing tells it which allocations matter: a terrain array of an area left behind and the textures the scene draws
are the same to it.

Change

Everything below is behind RX_VK_MEMORY_PRIORITY=1. Unset, the device is created with the same extensions as
before, and the renderer behaves as it does now.

• vk_main.cpp: asks for VK_EXT_memory_priority and, with it, VK_EXT_pageable_device_local_memory, each only
  with its feature. One log line says which: vk: memory priorities: on, pageable device-local memory ...,
  on, without pageable device-local memory ..., not supported, or off (RX_VK_MEMORY_PRIORITY=1: on).
• vk_vma.cpp: VMA_ALLOCATOR_CREATE_EXT_MEMORY_PRIORITY_BIT. Every VmaAllocationCreateInfo and both image
  pools' VmaPoolCreateInfo (the textures' and, since vk: render targets' images in VMA blocks of their own; dead targets swept every 10 presents (follow-up to #1416) NotRexed/Hookshot#1436, the render targets') now set priority = 0.5. With that flag on, VMA passes the create-info's value as
  given, and a create-info left at {} is 0, the lowest: without this, every dedicated allocation and both image
  pools would be the first paged out. (The field is ignored while the flag is off.) set_allocation_priority()
  changes a dedicated allocation's priority, never a shared block's.
• vk_texture.cpp: texture_priorities(), every 60 presents when the pageable extension is on. A texture unused for
  RX_VK_PRIORITY_IDLE presents (600, about 10 s) drops to 0.1, and goes back to 0.5 once used. Only memory a
  texture owns changes: dedicated allocations (the big ones, past the 128 MB image blocks) and sparse chunks.
  Textures inside pool blocks keep the block's 0.5. Every 600 presents it logs
  vk: memory priority: N textures (X MB) at the idle priority.
• memory_priority.h: the rule and the switches, tested without a GPU by tests/test_memory_priority.py. The test
  also fails if a VMA create-info is added later without a priority.
• Docs: the README switch section and gpu/vk/VULKAN.md.

Testing

• Game-free: tests/test_memory_priority.py (C++ rule test plus source checks). The three changed renderer files
  pass a syntax-only compile against the pinned Vulkan-Headers v1.4.345 and VMA v3.3.0.
• In game: not tried. I have no PC to run it on right now; that is why it is a draft and opt-in.

How to try it: add RX_VK_MEMORY_PRIORITY=1 to hookshot_env.txt, play the same route with and without it (for
example Kokiri Forest → Hyrule Field → Kakariko → Castle Town market and back), and compare the fps, the worst freezes,
and these lines of hookshot_log.txt: vk: memory priorities:, vk: memory priority: and
VRAM: ... used of ... allowed.

Windows already pages video memory on its own, so the gain there may be small. It is aimed at the stalls when VRAM is
full, not at the garbled textures of NotRexed/Hookshot#993.

Not in this PR

• Priorities by role (render targets higher). Since vk: render targets' images in VMA blocks of their own; dead targets swept every 10 presents (follow-up to #1416) NotRexed/Hookshot#1436 the render targets have a pool of their own, so this is now
  one line (pi.priority in target_images_pool()); left at 0.5 here to keep this PR to the mechanism.
• A higher priority for the GPU mirrors.

Related: NotRexed/Hookshot#993, NotRexed/Hookshot#995.

Written with AI assistance (Claude Opus 5.5); the commit carries the Assisted-by: and Co-Authored-By: trailers.

🤖 Generated with Claude Code