[soltros]

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

Source: NotRexed/Hookshot#1332
Original contributor: BiasedMonkey.
Original head: 03c951e0565e4a8338ca34959f0c720d1fbcda69.
Exact source tree: 76ac6cff991203442696d64354eab41dca3cc69f.
Import parent: 7dbdcdc00889ccf038ad95c7481ad6e10397f8a5 (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

What: OoT draws into and clears a 16-layer BC4 texture array through an RGBA16UI view of its blocks (one 8-byte block = one RGBA16UI texel). Compressed images were never created with COLOR_ATTACHMENT, so make_view() returned null for those views and the draws and clears were silently left out. This is the view of texture 0x1133ccb000 (vk 139) as vk 95 type 1 levels 0+1 layers N+1 not made line found in the AMD haze reports (NotRexed/Hookshot#914, NotRexed/Hookshot#1101), 16 times, one per layer.

Changes (gpu/vk/vk_texture.cpp, vk_draw.cpp, vk_xfer.cpp):

• BC images get COLOR_ATTACHMENT when the raw block format can be a color attachment and vkGetPhysicalDeviceImageFormatProperties accepts it. This is asked separately from STORAGE, so a refusal does not cost the raw storage views (the amdvlk note there).
• If image creation fails, it is retried without COLOR_ATTACHMENT first, then without STORAGE (as before).
• The render area of a block view (render targets in targets(), region clears in clear_tex()) is computed in blocks (view_texels()), not in the image's texels. The clear rect is clamped to it.
• On by default with Mesa RADV only. NVIDIA, amdvlk and the others are unchanged. RX_VK_BC_TARGETS=1 / 0 turns it on / off on any driver.
• Diagnostics: the "not made" line now says why (usage … not in the image's …, or the vkCreateImageView result), and compressed images log when one of their block-view usages is refused.

How it was found:

1. A standalone Vulkan repro (BC4 image with MUTABLE_FORMAT | BLOCK_TEXEL_VIEW_COMPATIBLE | EXTENDED_USAGE, plus a storage view as RGBA16UI / R32G32UI) passes on RADV with the Khronos validation layer and no message. So the driver was not refusing it.
2. With the diagnostic build, the line read not made: usage 0x10 not in the image's 0xf. The image had STORAGE; the game wanted COLOR_ATTACHMENT.
3. A second repro created the BC4 image with COLOR_ATTACHMENT, cleared one layer through an RGBA16UI view with dynamic rendering, and read it back: all 16384 blocks held the clear value, with no validation message, on an RX 7700S (NAVI33) and a 780M (PHOENIX), Mesa 26.2.6.

Tested: v2.0.11 + this commit (rebased here onto main, builds), RX 7700S, CachyOS, Mesa 26.2.6. Only hookshot_vk.so was rebuilt (RX_VK_ONLY=1).

Log before (v2.0.11):

[hos Presentation Thread] vk: view of texture 0x1133ccb000 (vk 139) as vk 95 type 1 levels 0+1 layers 0+1 not made
[hos Presentation Thread] vk: view of texture 0x1133ccb000 (vk 139) as vk 95 type 1 levels 0+1 layers 1+1 not made
… (16 lines, layers 0 to 15)

Diagnostic build:

vk: view of texture 0x1133ccb000 (vk 139) as vk 95 type 1 levels 0+1 layers 0+1 not made: usage 0x10 not in the image's 0xf

After:

[hos Presentation Thread] vk: draws and clears into compressed textures on (RX_VK_BC_TARGETS, on with RADV)
(no "not made" line, gameplay up to 1560 presents)

Not tested: NVIDIA, amdvlk, Intel (unchanged by default; RX_VK_BC_TARGETS=1 to try). No visible change on this machine: the white haze over outdoor scenes (NotRexed/Hookshot#1004) is still there with this commit, so it has another cause. This PR only stops the draws and clears into that texture from being skipped.

(Update: on this machine the washed-out picture turned out to be NotRexed/Hookshot#1042, the swapchain's colour space on KDE Wayland: with NotRexed/Hookshot#1086's change applied to v2.0.11 the picture is right again, so NotRexed/Hookshot#1086 is confirmed on an RX 7700S, RADV, Mesa 26.2.6. This PR is independent of it.)

AI-assisted (Claude Code) on behalf of the author: diagnosis, repros, patch and write-up; built and run on the machine above.

🤖 Generated with Claude Code