From fcd96ce00217f5749406091238d88d8928174ea5 Mon Sep 17 00:00:00 2001 From: Emma Anholt Date: Thu, 21 Jul 2022 15:42:18 -0700 Subject: [PATCH] turnip: Use the GMEM CCU space for attachments when the stores won't. Since the CCU only gets used for unaligned attachment stores or resolves with the wrong formats, we can use that space for attachments in many cases. This gets two more of vk-5-normal's main renderpass's attachments to fit in the next gmem_pixels increment, leaving 1 to go. Other renderpasses do get better gmem_pixels, and a few get better tile sizes as a result, but the fps increase from those looks to be <.2% at least. Part-of: --- src/freedreno/vulkan/tu_pass.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/freedreno/vulkan/tu_pass.c b/src/freedreno/vulkan/tu_pass.c index 27af02469ff02..c2cbcca3de54b 100644 --- a/src/freedreno/vulkan/tu_pass.c +++ b/src/freedreno/vulkan/tu_pass.c @@ -599,14 +599,15 @@ tu_render_pass_gmem_config(struct tu_render_pass *pass, continue; } - /* TODO: using ccu_offset_gmem so that BLIT_OP_SCALE resolve path - * doesn't break things. maybe there is a better solution? - * TODO: this algorithm isn't optimal + /* TODO: this algorithm isn't optimal * for example, two attachments with cpp = {1, 4} * result: nblocks = {12, 52}, pixels = 196608 * optimal: nblocks = {13, 51}, pixels = 208896 */ - uint32_t gmem_blocks = phys_dev->ccu_offset_gmem / gmem_align; + uint32_t gmem_size = layout == TU_GMEM_LAYOUT_FULL + ? phys_dev->gmem_size + : phys_dev->ccu_offset_gmem; + uint32_t gmem_blocks = gmem_size / gmem_align; uint32_t offset = 0, pixels = ~0u, i; for (i = 0; i < pass->attachment_count; i++) { struct tu_render_pass_attachment *att = &pass->attachments[i];