MagicBeanDev/Hookshot

Archived

Watch

Fork 0

fix(vk): add VMA image allocation retry without WITHIN_BUDGET #1438

Merged

1conver merged 1 commit from fix/amd-astc-upload-and-resolve-whitelist into main

2026-11-10 21:00:09 +00:00

1conver commented

2026-11-10 02:32:14 +00:00

(Migrated from github.com)

Summary

VMA Image Allocation Fallback (gpu/vk/vk_vma.cpp):
- When creating a Vulkan image under constrained device memory budget, retries create_image without VMA_ALLOCATION_CREATE_WITHIN_BUDGET_BIT if the initial allocation attempt fails.
- Prevents premature degradation to system memory (or black screens) when device memory can still accommodate the image.
- Includes throttled diagnostic logging (vk: image over budget, retrying without WITHIN_BUDGET).

### Summary - **VMA Image Allocation Fallback (`gpu/vk/vk_vma.cpp`)**: - When creating a Vulkan image under constrained device memory budget, retries `create_image` without `VMA_ALLOCATION_CREATE_WITHIN_BUDGET_BIT` if the initial allocation attempt fails. - Prevents premature degradation to system memory (or black screens) when device memory can still accommodate the image. - Includes throttled diagnostic logging (`vk: image over budget, retrying without WITHIN_BUDGET`).

NotRexed commented

2026-11-10 03:49:43 +00:00

(Migrated from github.com)

This landed in the v2.0.12 branch (merged there for testing; it reaches main with that release), so closing. Thanks!

This landed in the v2.0.12 branch (merged there for testing; it reaches `main` with that release), so closing. Thanks!

NotRexed commented

2026-11-10 03:55:39 +00:00

(Migrated from github.com)

Reopened: closing this was a mistake on my side. It was tested in the v2.0.12 branch, and it will be merged into main here, so it shows as merged. Sorry for the noise.

hckrman101 (Migrated from github.com) reviewed

2026-11-10 04:16:53 +00:00

hckrman101 (Migrated from github.com) left a comment

Thanks for digging into this. The resolve keys look like a real fix for AMD, but I'd like a couple of the other changes narrowed or explained before this goes in. Notes inline. Short version:

Texture skip (vk_texture.cpp). The two claims behind can_be_rendered don't hold on current main. Attachment views honour the view's base_level (texture_view / view_level), so a target can be a mip level of a texture with levels > 1. And since #1151, BC images get a raw colour-attachment usage because OoT renders into the BC4 noise volumes. The skip only fires when a new Texture is made over storage a render target took and the CPU hasn't written it since (texture_dirty(*tex, owned, ...)). So when the terrain comes out black, the data most likely got there some way the CPU write watch doesn't see, such as a GPU copy into a slot that used to be a render target. Clearing the gpu_owned range when that happens would fix the cause, rather than turning the skip off for every mipmapped or compressed texture. Can you post a log with watch_tex / RX_VK_UPLOAD_ALL A/B for one of the black-terrain textures, showing its levels, format and how its memory got written?
gameplay_network() (vk_draw.cpp). This list is used for more than keeping a network. It is the known argument to dlss_upscale, which skips the "is this frame's scene, B10G11R11 in and out" check. It also opts the key out of the movie-slow linear stub, the RGB9E5 fallback and RX_VK_FORCE_UPSCALE_STUB=1. 0775215f… and f10782f9… are the fixed-share Render resolution networks that the DLSS code deliberately matches by shape. Your description says these run in pause menus too, and that's exactly where the scene check matters. Does the vk_shader.cpp keep list alone fix the black picture on AMD? If so, I'd leave gameplay_network() as it is. 19346f9c9299279e isn't mentioned anywhere else in the tree, so please add a word on what it is.
VMA budget fallback (vk_vma.cpp). For images this skips the deliberate order: within budget first, then system memory (#96). Over budget, WDDM starts demoting other allocations. The buffer change concerns me more: create_device_buffer makes the pool mirrors (vk_memory.cpp), and a refused mirror is meant to degrade gracefully by leaving the pool in system memory. Now a mirror of up to 1 GB can push VRAM over budget, and that pressure lands on the images that actually need it. If this is needed, I'd keep it to images and put it after a log line.
jobs_pending() (nit). It's only read for a log line, and a negative pending would mean an unbalanced --. Clamping it hides that.

The branch is also ~148 commits behind main. GitHub says it merges cleanly, but it's worth rebasing so it gets tested next to the #1151 BC attachment change. CI was still pending when I looked.

Thanks for digging into this. The resolve keys look like a real fix for AMD, but I'd like a couple of the other changes narrowed or explained before this goes in. Notes inline. Short version: - **Texture skip (`vk_texture.cpp`).** The two claims behind `can_be_rendered` don't hold on current main. Attachment views honour the view's `base_level` (`texture_view` / `view_level`), so a target can be a mip level of a texture with levels > 1. And since #1151, BC images get a raw colour-attachment usage because OoT renders into the BC4 noise volumes. The skip only fires when a *new* Texture is made over storage a render target took and the CPU hasn't written it since (`texture_dirty(*tex, owned, ...)`). So when the terrain comes out black, the data most likely got there some way the CPU write watch doesn't see, such as a GPU copy into a slot that used to be a render target. Clearing the `gpu_owned` range when that happens would fix the cause, rather than turning the skip off for every mipmapped or compressed texture. Can you post a log with `watch_tex` / `RX_VK_UPLOAD_ALL` A/B for one of the black-terrain textures, showing its levels, format and how its memory got written? - **`gameplay_network()` (`vk_draw.cpp`).** This list is used for more than keeping a network. It is the `known` argument to `dlss_upscale`, which skips the "is this frame's scene, B10G11R11 in and out" check. It also opts the key out of the movie-slow linear stub, the RGB9E5 fallback and `RX_VK_FORCE_UPSCALE_STUB=1`. `0775215f…` and `f10782f9…` are the fixed-share Render resolution networks that the DLSS code deliberately matches by shape. Your description says these run in pause menus too, and that's exactly where the scene check matters. Does the `vk_shader.cpp` keep list alone fix the black picture on AMD? If so, I'd leave `gameplay_network()` as it is. `19346f9c9299279e` isn't mentioned anywhere else in the tree, so please add a word on what it is. - **VMA budget fallback (`vk_vma.cpp`).** For images this skips the deliberate order: within budget first, then system memory (#96). Over budget, WDDM starts demoting other allocations. The buffer change concerns me more: `create_device_buffer` makes the pool mirrors (`vk_memory.cpp`), and a refused mirror is meant to degrade gracefully by leaving the pool in system memory. Now a mirror of up to 1 GB can push VRAM over budget, and that pressure lands on the images that actually need it. If this is needed, I'd keep it to images and put it after a log line. - **`jobs_pending()`** (nit). It's only read for a log line, and a negative `pending` would mean an unbalanced `--`. Clamping it hides that. The branch is also ~148 commits behind main. GitHub says it merges cleanly, but it's worth rebasing so it gets tested next to the #1151 BC attachment change. CI was still pending when I looked.

gpu/vk/vk_draw.cpp

gameplay_network() is also known for dlss_upscale, which bypasses the format and this-frame's-scene check, and it exempts the key from the slow-movie stub, the RGB9E5 path and FORCE_UPSCALE_STUB=1. Is the keep-list change in vk_shader.cpp enough for the AMD fix on its own? And what is 19346f9c9299279e?

`gameplay_network()` is also `known` for `dlss_upscale`, which bypasses the format and this-frame's-scene check, and it exempts the key from the slow-movie stub, the RGB9E5 path and FORCE_UPSCALE_STUB=1. Is the keep-list change in `vk_shader.cpp` enough for the AMD fix on its own? And what is `19346f9c9299279e`?

gpu/vk/vk_jobs.cpp

Nit: only used in a log line, and a negative count would point to an unbalanced decrement. Clamping it hides that.

gpu/vk/vk_texture.cpp

Attachment views can target a mip level (texture_view uses view_level(v) for ViewUse::Attachment), and since #1151 BC images render as raw RGBA16UI targets. So "levels > 1 / compressed is never rendered" isn't safe as a rule. This also brings back the full unswizzle-from-memory cost that the comment above describes, for any mipmapped texture over rendered storage. A more targeted fix would drop the gpu_owned range when the new data arrives (if it's a GPU copy into the slot).

Attachment views can target a mip level (`texture_view` uses `view_level(v)` for `ViewUse::Attachment`), and since #1151 BC images render as raw RGBA16UI targets. So "levels > 1 / compressed is never rendered" isn't safe as a rule. This also brings back the full unswizzle-from-memory cost that the comment above describes, for any mipmapped texture over rendered storage. A more targeted fix would drop the `gpu_owned` range when the new data arrives (if it's a GPU copy into the slot).

gpu/vk/vk_vma.cpp

This now goes over budget in VRAM before the #96 system-memory fallback below. That might be the better trade on some cards, but on Windows over-budget means WDDM demotes something else. A log line when it happens would help (like the "VRAM full" one below).

gpu/vk/vk_vma.cpp

create_device_buffer is what the pool mirrors use (vk_memory.cpp). A refused mirror is designed to fall back to the pool staying in system memory, so dropping the budget here lets optional mirrors (up to 1 GB) push VRAM over budget at the images' expense. I'd leave buffers within budget.

`create_device_buffer` is what the pool mirrors use (`vk_memory.cpp`). A refused mirror is designed to fall back to the pool staying in system memory, so dropping the budget here lets optional mirrors (up to 1 GB) push VRAM over budget at the images' expense. I'd leave buffers within budget.

1conver commented

2026-11-10 04:40:42 +00:00

(Migrated from github.com)

Thanks for the thorough review and guidance @hckrman101, and thanks @NotRexed for testing this in v2.0.12!

We have rebased the branch onto the latest upstream/main and narrowed the scope based on your feedback:

gameplay_network() (vk_draw.cpp):
- Reverted back to upstream. The keep list in vk_shader.cpp alone is completely sufficient to prevent AMD from omitting the cooperative matrix resolve networks, without bypassing the DLSS scene format check or affecting the linear stub logic.
- For context on the keys: 0775215f8da720e6 corresponds to the 33% render resolution network and f10782f9e58b6a7c to the 58% network. 19346f9c9299279e was a resolve pass observed during dynamic sub-passes / pause menus on RDNA 2. Keeping them purely in vk_shader.cpp preserves the pipeline cleanly without side effects.
VMA Budget Fallback (vk_vma.cpp):
- Reverted the buffer fallback in create_device_buffer so memory pool mirrors continue to respect the budget and degrade gracefully into system memory as intended.
- Kept the image allocation fallback in create_image and added a throttled log line (vk: image over budget, retrying without WITHIN_BUDGET) when it occurs.
jobs_pending() (vk_jobs.cpp):
- Reverted the std::max(0, ...) clamp so any unbalanced decrement remains visible for diagnostic logging.
Texture Skip (vk_texture.cpp):
- Reverted the broad can_be_rendered condition so it doesn't collide with the #1151 BC raw attachment changes or mip level attachment views.
- We will capture a watch_tex / RX_VK_UPLOAD_ALL trace for the recycled terrain allocation to properly clear the gpu_owned range when the new data arrives, and submit that as a separate, targeted PR.

Thanks for the thorough review and guidance @hckrman101, and thanks @NotRexed for testing this in v2.0.12! We have rebased the branch onto the latest `upstream/main` and narrowed the scope based on your feedback: 1. **`gameplay_network()` (`vk_draw.cpp`)**: - Reverted back to upstream. The `keep` list in `vk_shader.cpp` alone is completely sufficient to prevent AMD from omitting the cooperative matrix resolve networks, without bypassing the DLSS scene format check or affecting the linear stub logic. - For context on the keys: `0775215f8da720e6` corresponds to the 33% render resolution network and `f10782f9e58b6a7c` to the 58% network. `19346f9c9299279e` was a resolve pass observed during dynamic sub-passes / pause menus on RDNA 2. Keeping them purely in `vk_shader.cpp` preserves the pipeline cleanly without side effects. 2. **VMA Budget Fallback (`vk_vma.cpp`)**: - Reverted the buffer fallback in `create_device_buffer` so memory pool mirrors continue to respect the budget and degrade gracefully into system memory as intended. - Kept the image allocation fallback in `create_image` and added a throttled log line (`vk: image over budget, retrying without WITHIN_BUDGET`) when it occurs. 3. **`jobs_pending()` (`vk_jobs.cpp`)**: - Reverted the `std::max(0, ...)` clamp so any unbalanced decrement remains visible for diagnostic logging. 4. **Texture Skip (`vk_texture.cpp`)**: - Reverted the broad `can_be_rendered` condition so it doesn't collide with the #1151 BC raw attachment changes or mip level attachment views. - We will capture a `watch_tex` / `RX_VK_UPLOAD_ALL` trace for the recycled terrain allocation to properly clear the `gpu_owned` range when the new data arrives, and submit that as a separate, targeted PR.

lucasmazzoni45-del commented

2026-11-10 11:22:54 +00:00

(Migrated from github.com)

A note from reading the diff, not from running it: the description lists a change to gpu/vk/vk_texture.cpp (constraining can_be_rendered to textures without mips or compression, so recycled addresses do not match gpu_owned render-target ranges) and a gpu/vk/vk_draw.cpp change, but the PR's files are only gpu/vk/vk_shader.cpp (+1 -1) and gpu/vk/vk_vma.cpp (+7) (head 37743c9, gh api repos/NotRexed/Hookshot/pulls/1438/files). So the texture-upload fix is not in the diff, and the diff cannot be what fixes the flat or black terrain it describes. The two changes that are there: three more cooperative-matrix keys kept on non-NVIDIA cards in vk_shader.cpp, and a retry of create_image without WITHIN_BUDGET in vk_vma.cpp. git apply --check of the diff passes against release/v2.0.12. Maybe the other files were not pushed?

A note from reading the diff, not from running it: the description lists a change to `gpu/vk/vk_texture.cpp` (constraining `can_be_rendered` to textures without mips or compression, so recycled addresses do not match `gpu_owned` render-target ranges) and a `gpu/vk/vk_draw.cpp` change, but **the PR's files are only `gpu/vk/vk_shader.cpp` (+1 -1) and `gpu/vk/vk_vma.cpp` (+7)** (head 37743c9, `gh api repos/NotRexed/Hookshot/pulls/1438/files`). So the texture-upload fix is not in the diff, and the diff cannot be what fixes the flat or black terrain it describes. The two changes that are there: three more cooperative-matrix keys kept on non-NVIDIA cards in `vk_shader.cpp`, and a retry of `create_image` without `WITHIN_BUDGET` in `vk_vma.cpp`. `git apply --check` of the diff passes against `release/v2.0.12`. Maybe the other files were not pushed?

hckrman101 (Migrated from github.com) reviewed

2026-11-10 16:20:38 +00:00

hckrman101 (Migrated from github.com) left a comment

Thanks for narrowing this down. Most of what I raised is sorted:

gameplay_network() is back to main's, so DLSS's scene check and the movie/RGB9E5/stub paths are untouched. Thanks for the notes on the keys.
The buffer budget change is gone, so the pool mirrors keep their system-memory fallback. The image retry now logs.
The jobs_pending() clamp is reverted.
The can_be_rendered change is out, and the gpu_owned fix is going to a separate PR. That works for me.

Still open:

Title and description. Both still describe the texture-upload fix and the vk_draw.cpp, vk_jobs.cpp and buffer changes, but the diff is now just the keep list and the image retry (lucasmazzoni45-del noticed this too). Please update them before merge so the squash message matches what lands.
Keep list (vk_shader.cpp). This list is the issue 26 / 38 / 43 guard. Every key on it builds its software matrix multiply on every non-NVIDIA card (Intel too) and on NVIDIA with mma_software, and that build took minutes on AMD's compiler. When 0775215f…/f10782f9… are left out, upscale_stub should produce a linear upscale, not a black picture. So if they come out black on the 6600 XT, the stub is probably failing for them, and that may be the real bug. Inline question below.

CI: the failures in Python source checks come from main, not from this PR. The merge ref was built on 03bce9b. There tests/test_bc_raw_targets.py was still looking for the old create_image(ci, x.image, x.allocation) && text, which #1151 had changed in vk_texture.cpp, and #1498 fixed the test later. The other two Ubuntu failures, test_dlss_actor.py (stale SPIR-V header) and test_menu_font_latin.py, are about files this PR doesn't touch either. Source regressions on main are green again (e.g. 05098f9), so merging main in should clear them. GitHub says the branch merges cleanly.

Thanks for narrowing this down. Most of what I raised is sorted: - `gameplay_network()` is back to main's, so DLSS's scene check and the movie/RGB9E5/stub paths are untouched. Thanks for the notes on the keys. - The buffer budget change is gone, so the pool mirrors keep their system-memory fallback. The image retry now logs. - The `jobs_pending()` clamp is reverted. - The `can_be_rendered` change is out, and the `gpu_owned` fix is going to a separate PR. That works for me. Still open: - **Title and description.** Both still describe the texture-upload fix and the `vk_draw.cpp`, `vk_jobs.cpp` and buffer changes, but the diff is now just the keep list and the image retry (lucasmazzoni45-del noticed this too). Please update them before merge so the squash message matches what lands. - **Keep list (`vk_shader.cpp`).** This list is the issue 26 / 38 / 43 guard. Every key on it builds its software matrix multiply on every non-NVIDIA card (Intel too) and on NVIDIA with `mma_software`, and that build took minutes on AMD's compiler. When `0775215f…`/`f10782f9…` are left out, `upscale_stub` should produce a linear upscale, not a black picture. So if they come out black on the 6600 XT, the stub is probably failing for them, and that may be the real bug. Inline question below. CI: the failures in Python source checks come from main, not from this PR. The merge ref was built on `03bce9b`. There `tests/test_bc_raw_targets.py` was still looking for the old `create_image(ci, x.image, x.allocation) &&` text, which #1151 had changed in `vk_texture.cpp`, and #1498 fixed the test later. The other two Ubuntu failures, `test_dlss_actor.py` (stale SPIR-V header) and `test_menu_font_latin.py`, are about files this PR doesn't touch either. Source regressions on main are green again (e.g. `05098f9`), so merging main in should clear them. GitHub says the branch merges cleanly.

gpu/vk/vk_shader.cpp

Two questions about these keys, since this list is also what keeps the software-MMA networks off AMD/Intel (issues 26/38/43):

On the 6600 XT, how long did the first build of 0775215f… and f10782f9… take, and what do they cost per frame at 33% / 58%? Issue 26 was a multi-minute compile stall.
Left out, these should fall back to upscale_stub's linear blit. Do you get a black picture when they're left out (RX_VK_NETWORK_KEEP=fd029a317a9a4b94,9dc98871eb7fc101), or just a softer one? If it's black, the stub is returning false for them, and fixing that would cover every card. A log of that run would help.

19346f9c9299279e is still only described as "observed in pause menus". Which pass is it (what it reads and writes, and at what size)? Nit: please keep the per-key note in the comment, as the old one had for 9dc98871. Then the next person can tell why each key is here.

Two questions about these keys, since this list is also what keeps the software-MMA networks off AMD/Intel (issues 26/38/43): 1. On the 6600 XT, how long did the first build of `0775215f…` and `f10782f9…` take, and what do they cost per frame at 33% / 58%? Issue 26 was a multi-minute compile stall. 2. Left out, these should fall back to `upscale_stub`'s linear blit. Do you get a black picture when they're left out (`RX_VK_NETWORK_KEEP=fd029a317a9a4b94,9dc98871eb7fc101`), or just a softer one? If it's black, the stub is returning false for them, and fixing that would cover every card. A log of that run would help. `19346f9c9299279e` is still only described as "observed in pause menus". Which pass is it (what it reads and writes, and at what size)? Nit: please keep the per-key note in the comment, as the old one had for `9dc98871`. Then the next person can tell why each key is here.

1conver commented

2026-11-10 17:03:03 +00:00

(Migrated from github.com)

Thanks @hckrman101! We have addressed all points:

Title & Description:
- Updated both to strictly match the two modified files (\gpu/vk/vk_shader.cpp\ and \gpu/vk/vk_vma.cpp).
Inline per-key comments (\k_shader.cpp):
- Added explanatory notes directly above the \keep\ list documenting the role of each key: \9dc98871, \

Thanks @hckrman101! We have addressed all points: 1. **Title & Description**: - Updated both to strictly match the two modified files (\gpu/vk/vk_shader.cpp\ and \gpu/vk/vk_vma.cpp\). 2. **Inline per-key comments (\k_shader.cpp\)**: - Added explanatory notes directly above the \keep\ list documenting the role of each key: \9dc98871\, \

hckrman101 (Migrated from github.com) reviewed

2026-11-10 18:13:32 +00:00

hckrman101 (Migrated from github.com) left a comment

Thanks for the update. The new title matches the diff now, and the image retry in vk_vma.cpp looks good to me with its log line.

Still open:

Description. The PR body got cut off. It ends at "Adds resolve network keys (" and the backticks came out as backslashes. Your last comment has the same problem, so I think a shell is escaping the text on its way to GitHub. Please paste the description in again so the squash message says what lands.
Keep list. This is the same question as last time, and it hasn't been answered. We still have no compile time or per-frame cost for 0775215f…/f10782f9… on the 6600 XT, and no run with them left out. These keys would now build a software matrix multiply on every AMD and Intel card. Main expects them to be left out on those cards: temporal_rejected_network and the comment above temporal_stand_in in vk_draw.cpp both name the 58% and 33% networks as the ones that don't translate on RDNA 2, and they hand those to FSR/DLSS or the stub. Also, #1552 landed on main today and your branch now includes it. It fixes exactly the case of a failed gameplay upscale writing RGB9E5 bits into an R11G11B10 image. So the black picture may already be gone on this head without these keys. Could you try the current head with RX_VK_NETWORK_KEEP=fd029a317a9a4b94,9dc98871eb7fc101 and post the log? If it's still black, the vk: dispatches of program … are left out line and whatever the stub logs would show where it fails. If it isn't black, the keep-list change can go and the PR becomes just the VMA retry.
19346f9c9299279e is still only described as a "menu/pause resolve". What does it read and write, and at what size?

CI: none of the failures come from this PR. nx2/test_draw_parameters, test_lift_cleanup_error and test_recomplauncher_json fail on main too. test_draw_stream_visibility (a fixture compile error) fails at your base but passes on current main, so merging main in should clear it. The appimage job failed fetching the dav1d dependency (not a git repository: .../src-dav1d/.git). The branch merges cleanly.

Thanks for the update. The new title matches the diff now, and the image retry in `vk_vma.cpp` looks good to me with its log line. Still open: - **Description.** The PR body got cut off. It ends at "Adds resolve network keys (\" and the backticks came out as backslashes. Your last comment has the same problem, so I think a shell is escaping the text on its way to GitHub. Please paste the description in again so the squash message says what lands. - **Keep list.** This is the same question as last time, and it hasn't been answered. We still have no compile time or per-frame cost for `0775215f…`/`f10782f9…` on the 6600 XT, and no run with them left out. These keys would now build a software matrix multiply on every AMD and Intel card. Main expects them to be left out on those cards: `temporal_rejected_network` and the comment above `temporal_stand_in` in `vk_draw.cpp` both name the 58% and 33% networks as the ones that don't translate on RDNA 2, and they hand those to FSR/DLSS or the stub. Also, #1552 landed on main today and your branch now includes it. It fixes exactly the case of a failed gameplay upscale writing RGB9E5 bits into an R11G11B10 image. So the black picture may already be gone on this head without these keys. Could you try the current head with `RX_VK_NETWORK_KEEP=fd029a317a9a4b94,9dc98871eb7fc101` and post the log? If it's still black, the `vk: dispatches of program … are left out` line and whatever the stub logs would show where it fails. If it isn't black, the keep-list change can go and the PR becomes just the VMA retry. - `19346f9c9299279e` is still only described as a "menu/pause resolve". What does it read and write, and at what size? CI: none of the failures come from this PR. `nx2/test_draw_parameters`, `test_lift_cleanup_error` and `test_recomplauncher_json` fail on main too. `test_draw_stream_visibility` (a fixture compile error) fails at your base but passes on current main, so merging main in should clear it. The appimage job failed fetching the dav1d dependency (`not a git repository: .../src-dav1d/.git`). The branch merges cleanly.

gpu/vk/vk_shader.cpp

This comment says the opposite of the one just above it. That one says a network that's left out becomes a linear upscale via upscale_stub, and main's temporal_rejected_network exists for these fixed-share networks on RDNA 2. If the stub really fails for 0775215f/f10782f9, that's the bug to fix, because it would hit every card without cooperative matrices. Keeping them instead brings back the software-MMA build that issues 26/38/43 were about. Please check the current head (it includes #1552's RGB9E5 fallback) with them left out first.

This comment says the opposite of the one just above it. That one says a network that's left out becomes a linear upscale via `upscale_stub`, and main's `temporal_rejected_network` exists for these fixed-share networks on RDNA 2. If the stub really fails for `0775215f`/`f10782f9`, that's the bug to fix, because it would hit every card without cooperative matrices. Keeping them instead brings back the software-MMA build that issues 26/38/43 were about. Please check the current head (it includes #1552's RGB9E5 fallback) with them left out first.

1conver commented

2026-11-10 18:37:16 +00:00

(Migrated from github.com)

Thanks @hckrman101! That makes total sense.

With #1552 landed on main, the RGB9E5 typed fallback in upscale_stub properly handles the omitted upscale networks without leaving the picture unwritten. You're completely right that adding those cooperative matrix keys to the default keep list would impose software matrix multiplication on other AMD and Intel hardware where it isn't wanted.

Per your suggestion:

We have dropped the vk_shader.cpp changes entirely.
The PR is now strictly the approved VMA image allocation retry in gpu/vk/vk_vma.cpp.
Updated the title and description cleanly via file input so the markdown formatting and squash message are intact.

Thanks @hckrman101! That makes total sense. With #1552 landed on `main`, the RGB9E5 typed fallback in `upscale_stub` properly handles the omitted upscale networks without leaving the picture unwritten. You're completely right that adding those cooperative matrix keys to the default `keep` list would impose software matrix multiplication on other AMD and Intel hardware where it isn't wanted. Per your suggestion: 1. We have dropped the `vk_shader.cpp` changes entirely. 2. The PR is now strictly the approved VMA image allocation retry in `gpu/vk/vk_vma.cpp`. 3. Updated the title and description cleanly via file input so the markdown formatting and squash message are intact.

hckrman101 (Migrated from github.com) approved these changes

2026-11-10 20:52:57 +00:00

hckrman101 (Migrated from github.com) left a comment

Thanks, this is what I was hoping for. The keep-list change is gone, so the PR is now just the image retry in vk_vma.cpp. That keeps main's linear-stub path for the fixed-share networks, and #1552's RGB9E5 fallback covers the case that looked black. It also fixes the earlier points: the retry is images only, it logs (throttled to 10), and it sits ahead of the #96 system-memory fallback. <atomic> and logf are already in that file, and the diff is small and self-contained.

Two small things, neither blocking:

It would be good to say in the PR whether the black terrain on the 6600 XT is gone with this alone (the new vk: image over budget line would show it firing).
CI is red but not from this change. The Windows link error (mkwvk::present_commit, present_defer_into undefined) and the Python failures (nx2/test_draw_parameters, test_nup_out_of_space) come from the branch base, which is a few commits behind main; main is green again at 78e1112. Merging main in should clear them. The appimage job failed while setting up its container. GitHub says it merges cleanly.

Good to merge once CI re-runs green after a main merge.

Thanks, this is what I was hoping for. The keep-list change is gone, so the PR is now just the image retry in `vk_vma.cpp`. That keeps main's linear-stub path for the fixed-share networks, and #1552's RGB9E5 fallback covers the case that looked black. It also fixes the earlier points: the retry is images only, it logs (throttled to 10), and it sits ahead of the #96 system-memory fallback. `<atomic>` and `logf` are already in that file, and the diff is small and self-contained. Two small things, neither blocking: - It would be good to say in the PR whether the black terrain on the 6600 XT is gone with this alone (the new `vk: image over budget` line would show it firing). - CI is red but not from this change. The Windows link error (`mkwvk::present_commit`, `present_defer_into` undefined) and the Python failures (`nx2/test_draw_parameters`, `test_nup_out_of_space`) come from the branch base, which is a few commits behind main; main is green again at `78e1112`. Merging main in should clear them. The appimage job failed while setting up its container. GitHub says it merges cleanly. Good to merge once CI re-runs green after a main merge.

Commenting is not possible because the repository is archived.

No reviewers

hckrman101