perf(vk): opaque ASTC textures kept as BC1, half the video memory of BC3 #2554

Open

NotRexed wants to merge 1 commit from perf/astc-opaque-bc1 into main

NotRexed commented

2026-11-11 23:07:52 +00:00

(Migrated from github.com)

Why. On cards up to 8 GB, the big ASTC textures (terrain, buildings) are decoded on the GPU and re-encoded as BC3, a byte per texel. A large share of the game's textures have no transparency at all, and BC1 stores them in half the space with the same colours. This targets the 8 GB "fps fades over time" reports (#993): less VRAM for the same picture.

How

The choice (gpu/vk/astc_opaque.h). A block counts as opaque only when its header says so:
- its colour endpoint mode has no alpha (0–3, 6–9, 11, 14, 15), or
- it is an LDR void extent whose alpha high byte is 0xFF.
Everything uncertain counts as alpha and keeps BC3: alpha modes (4, 5, 10, 12, 13), partitions of different modes, and HDR void extents. Blocks of zeros (storage the game hasn't written yet) decide nothing.
When (upload_astc_gpu). A texture's first whole upload decides, if every block with data in it is opaque and those blocks are most of the storage. Its BC3 image is then made again as BC1 (bc_reformat). The old image and views are released once the work that used them is done, the same way the compaction moves images. Views are made again on demand, and destroy_gen is bumped.
Switching back. An upload into a BC1 image that has alpha in it turns the image back into BC3 and uploads it whole.
Encoding. bc_encode_into runs the existing encoder in its BC1 mode (bc3 = 0). Without texels under half alpha, it writes the same four-colour blocks as BC3's colour half. A BC1 image's views are BC1_RGBA (UNORM / SRGB).
Off switch. RX_VK_ASTC_BC1=0 keeps everything BC3. The log says how many textures went BC1, how many went back, and the MB saved.

Tests: tests/test_astc_opaque.py builds blocks bit by bit (every endpoint mode, shared and mixed partitions, void extents, zeros) and checks the scan and the whole-upload rule. All tests that read vk_texture.cpp pass, and the file compiles. The narrowing error at line 1485 with plain clang flags is already on main.

Not yet verified in-game: VRAM in Hyrule Field with and without it, plus the flash check. The PC is in use for the owner's 2.2.0 test.

🤖 Generated with Claude Code

**Why.** On cards up to 8 GB, the big ASTC textures (terrain, buildings) are decoded on the GPU and re-encoded as BC3, a byte per texel. A large share of the game's textures have no transparency at all, and BC1 stores them in half the space with the same colours. This targets the 8 GB "fps fades over time" reports (#993): less VRAM for the same picture. **How** - **The choice** (`gpu/vk/astc_opaque.h`). A block counts as opaque only when its header says so: - its colour endpoint mode has no alpha (0–3, 6–9, 11, 14, 15), or - it is an LDR void extent whose alpha high byte is 0xFF. Everything uncertain counts as alpha and keeps BC3: alpha modes (4, 5, 10, 12, 13), partitions of different modes, and HDR void extents. Blocks of zeros (storage the game hasn't written yet) decide nothing. - **When** (`upload_astc_gpu`). A texture's first whole upload decides, if every block with data in it is opaque and those blocks are most of the storage. Its BC3 image is then made again as BC1 (`bc_reformat`). The old image and views are released once the work that used them is done, the same way the compaction moves images. Views are made again on demand, and `destroy_gen` is bumped. - **Switching back.** An upload into a BC1 image that has alpha in it turns the image back into BC3 and uploads it whole. - **Encoding.** `bc_encode_into` runs the existing encoder in its BC1 mode (`bc3 = 0`). Without texels under half alpha, it writes the same four-colour blocks as BC3's colour half. A BC1 image's views are `BC1_RGBA` (UNORM / SRGB). - **Off switch.** `RX_VK_ASTC_BC1=0` keeps everything BC3. The log says how many textures went BC1, how many went back, and the MB saved. **Tests:** `tests/test_astc_opaque.py` builds blocks bit by bit (every endpoint mode, shared and mixed partitions, void extents, zeros) and checks the scan and the whole-upload rule. All tests that read `vk_texture.cpp` pass, and the file compiles. The narrowing error at line 1485 with plain clang flags is already on main. **Not yet verified in-game:** VRAM in Hyrule Field with and without it, plus the flash check. The PC is in use for the owner's 2.2.0 test. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

github-sync changed title from ~~WIP: perf(vk): opaque ASTC textures kept as BC1, half the video memory of BC3~~ to perf(vk): opaque ASTC textures kept as BC1, half the video memory of BC3

2026-11-12 11:35:58 +00:00

github-sync commented

2026-11-12 11:35:59 +00:00

Owner

@Waryxxful commented on GitHub · 2026-11-12 11:21 UTC · original

Heads-up for the rebase on main: #2226 (RX_VK_ASTC_BC7) landed in the same spots, and I hit the conflict while merging this locally to test it on an RX 5600 XT.

view_format_of. The conflict is one hunk. I resolved it as BC7 when the image is BC7, BC1 when it is BC1, else BC3. That keeps the const bool bc1 = image == VK_FORMAT_BC1_RGBA_UNORM_BLOCK; line that tests/test_astc_opaque.py looks for:

const bool srgb = f == VK_FORMAT_R8G8B8A8_SRGB;
// (hookshot: an opaque texture's image is BC1, astc_opaque.h)
const bool bc1 = image == VK_FORMAT_BC1_RGBA_UNORM_BLOCK;
if (linear_twin(image) == VK_FORMAT_BC7_UNORM_BLOCK)
    f = srgb ? VK_FORMAT_BC7_SRGB_BLOCK : VK_FORMAT_BC7_UNORM_BLOCK;
else if (bc1)
    f = srgb ? VK_FORMAT_BC1_RGBA_SRGB_BLOCK : VK_FORMAT_BC1_RGBA_UNORM_BLOCK;
else
    f = srgb ? VK_FORMAT_BC3_SRGB_BLOCK : VK_FORMAT_BC3_UNORM_BLOCK;

bc_encode_into with both switches on. It binds bc7_enabled() ? bc7_pipe : bc_pipe, and only the BC3/BC1 encoder reads the push constant's bc3 flag. With RX_VK_ASTC_BC7=1, a texture that upload_astc_gpu turned into BC1 (!is_bc1 && !tex.bc1 is true for a BC7 image too) would be encoded by the BC7 pipeline into a BC1 image. BC7 is off by default, so the default path is fine. Two possible fixes: bc1_on() returns false when bc7_enabled(), or the reformat goes back to BC7 instead of BC3 and the BC1 encode always takes bc_pipe.
Tests. On the merged tree, tests/test_astc_opaque.py passes.

In the game.

Setup: RX 5600 XT 6 GB (RDNA1, no mesh shaders), Adrenalin 26.10.1, Windows 11, Ryzen 5 5600X, 24 GB, 1920x1080, frame generation off. Every run starts from the same copied save and follows a scripted route through the control bridge (Kokiri Forest and Hyrule Field: settle 15 s, then 60 s standing); fps are the medians of the log's N presents lines. Run-to-run noise on main de866017 (4 runs): Kokiri 31.5-34.6 fps, Hyrule Field 32.1-34.8.

Merged on main de866017 (the #2226 conflict resolved as above). At Kokiri Forest and Hyrule Field:

BC1: 16 opaque textures kept as BC1, 0 back to BC3; 7 MB less than BC3. The textures held ~1,100 MB.
fps: within run-to-run noise (Kokiri 32.6, Hyrule Field 35.5, against a main range of 31.5-34.8).
Flashes: no frame log was taken for this one yet.

So at these spots few of the big ASTC textures pass the whole-upload rule. The saving may be bigger elsewhere (Castle Town, Death Mountain); I can run those if useful.

> [@Waryxxful](https://github.com/Waryxxful) commented on GitHub · 2026-11-12 11:21 UTC · [original](https://github.com/NotRexed/Hookshot/pull/2554#issuecomment-6822204055) Heads-up for the rebase on main: #2226 (`RX_VK_ASTC_BC7`) landed in the same spots, and I hit the conflict while merging this locally to test it on an RX 5600 XT. - **`view_format_of`.** The conflict is one hunk. I resolved it as BC7 when the image is BC7, BC1 when it is BC1, else BC3. That keeps the `const bool bc1 = image == VK_FORMAT_BC1_RGBA_UNORM_BLOCK;` line that `tests/test_astc_opaque.py` looks for: ```cpp const bool srgb = f == VK_FORMAT_R8G8B8A8_SRGB; // (hookshot: an opaque texture's image is BC1, astc_opaque.h) const bool bc1 = image == VK_FORMAT_BC1_RGBA_UNORM_BLOCK; if (linear_twin(image) == VK_FORMAT_BC7_UNORM_BLOCK) f = srgb ? VK_FORMAT_BC7_SRGB_BLOCK : VK_FORMAT_BC7_UNORM_BLOCK; else if (bc1) f = srgb ? VK_FORMAT_BC1_RGBA_SRGB_BLOCK : VK_FORMAT_BC1_RGBA_UNORM_BLOCK; else f = srgb ? VK_FORMAT_BC3_SRGB_BLOCK : VK_FORMAT_BC3_UNORM_BLOCK; ``` - **`bc_encode_into` with both switches on.** It binds `bc7_enabled() ? bc7_pipe : bc_pipe`, and only the BC3/BC1 encoder reads the push constant's `bc3` flag. With `RX_VK_ASTC_BC7=1`, a texture that `upload_astc_gpu` turned into BC1 (`!is_bc1 && !tex.bc1` is true for a BC7 image too) would be encoded by the BC7 pipeline into a BC1 image. BC7 is off by default, so the default path is fine. Two possible fixes: `bc1_on()` returns false when `bc7_enabled()`, or the reformat goes back to BC7 instead of BC3 and the BC1 encode always takes `bc_pipe`. - **Tests.** On the merged tree, `tests/test_astc_opaque.py` passes. **In the game.** **Setup:** RX 5600 XT 6 GB (RDNA1, no mesh shaders), Adrenalin 26.10.1, Windows 11, Ryzen 5 5600X, 24 GB, 1920x1080, frame generation off. Every run starts from the same copied save and follows a scripted route through the control bridge (Kokiri Forest and Hyrule Field: settle 15 s, then 60 s standing); fps are the medians of the log's `N presents` lines. Run-to-run noise on main `de866017` (4 runs): Kokiri 31.5-34.6 fps, Hyrule Field 32.1-34.8. Merged on main `de866017` (the #2226 conflict resolved as above). At Kokiri Forest and Hyrule Field: - **BC1:** `16 opaque textures kept as BC1, 0 back to BC3; 7 MB less than BC3`. The textures held ~1,100 MB. - **fps:** within run-to-run noise (Kokiri 32.6, Hyrule Field 35.5, against a main range of 31.5-34.8). - **Flashes:** no frame log was taken for this one yet. So at these spots few of the big ASTC textures pass the whole-upload rule. The saving may be bigger elsewhere (Castle Town, Death Mountain); I can run those if useful.

Commenting is not possible because the repository is archived.

No reviewers