Skip to content

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

Draft
NotRexed wants to merge 1 commit into
mainfrom
perf/astc-opaque-bc1
Draft

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

Conversation

@NotRexed

Copy link
Copy Markdown
Owner

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

Big ASTC textures are decoded on the GPU and re-encoded as BC3 (a byte a texel). One whose every block decodes
opaque now gets a BC1 image instead (half a byte a texel): the encoder writes the colour half alone, the same
four-colour blocks BC3 holds, so its texels are the same. Told from the blocks' headers (gpu/vk/astc_opaque.h):
a colour endpoint mode without alpha, or an LDR void extent with alpha 0xFF; partitions of different modes, alpha
modes and HDR void extents keep BC3. A texture's first whole upload with texels in it decides (zeros, storage not yet
written, decide nothing); its BC3 image is made again as BC1 (the old image and views let go when their work is done,
as the compaction's move). An upload with alpha into a BC1 image makes it BC3 again and uploads it whole.
RX_VK_ASTC_BC1=0: all BC3. tests/test_astc_opaque.py.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@Waryxxful

Copy link
Copy Markdown
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants