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: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16921>
This commit is contained in:
Emma Anholt 2022-07-21 15:42:18 -07:00 committed by Marge Bot
parent b8a334b547
commit fcd96ce002
1 changed files with 5 additions and 4 deletions

View File

@ -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];