GPUs baseadas em tiles: escolha com critério as operações de load e store dos attachments

Trate um attachment como um dado com ciclo de vida

Uma GPU baseada em tiles processa pequenas regiões do framebuffer usando armazenamento local. Restaurar o conteúdo antigo de um attachment ou exportar resultados intermediários pode gerar tráfego de memória externa. As escolhas de load e store dos attachments informam à implementação quais conteúdos importam nas fronteiras da renderização. A explicação da Arm para desenvolvedores mostra por que essas escolhas podem afetar de forma significativa a largura de banda em GPUs móveis. [1]

Para cada attachment de cor, profundidade e stencil, identifique quem produz seu conteúdo inicial e quem precisa do resultado final. Um buffer de profundidade usado apenas durante um único intervalo de renderização tem requisitos diferentes de uma profundidade que é amostrada por efeitos posteriores.

Escolha o estado inicial com base nas leituras reais

Use LOAD quando o conteúdo anterior precisa ser preservado. Use CLEAR quando for necessário um valor inicial uniforme e definido. Use DONT_CARE somente quando o conteúdo anterior for desnecessário e todo valor lido depois estiver inicializado de forma adequada. O Vulkan define o conteúdo inicial descartado como indefinido dentro da área de renderização. [2]

Um draw que parece cobrir a tela inteira não prova que tudo foi sobrescrito: rejeição por profundidade, scissors, write masks ou blending podem manter dependências do conteúdo anterior. Em hardware de tiles adequado, limpar por meio da operação do attachment pode inicializar o armazenamento local do tile sem restaurar a imagem anterior. [1]

Exemplo prático: estimar a escala da transferência

Um attachment ilustrativo de 1920 por 1080 com 4 bytes por pixel contém 1920 * 1080 * 4 = 8294400 bytes. Um load completo mais um store completo transferem 16588800 bytes em um modelo de contabilização sem compressão.

A 60 quadros por segundo, isso dá 16588800 * 60 = 995328000 bytes por segundo, aproximadamente 0,995 GB/s. Esse valor não é largura de banda medida nem economia garantida: compressão, caches, áreas de renderização parciais e escolhas da implementação alteram o tráfego real. O cálculo mostra por que uma ida e volta desnecessária de um attachment merece investigação.

Preserve o conteúdo final apenas onde for necessário

Faça store dos resultados necessários para a apresentação, para renderizações posteriores ou para leitura de volta (readback). Se o conteúdo de um attachment não for mais necessário, uma operação de store com descarte pode evitar que ele seja preservado. O store DONT_CARE do Vulkan torna esse conteúdo indefinido. A operação NONE tem semântica distinta e não deve ser tratada como forma de preservar dados recém-escritos para um pass posterior. [3]

Para attachments temporários adequados, investigue o uso transient e a alocação lazy, quando houver suporte. Mantenha juntos os trabalhos compatíveis quando isso permitir reutilização local, mas verifique a execução real em vez de presumir que todo pass lógico seja fundido. A leitura de pixels vizinhos pode exigir um caminho de memória diferente. [1]

Verifique a correção antes de interpretar contadores

Teste cobertura parcial, overlays, consumidores de profundidade e tamanhos de saída alternativos depois de alterar as operações dos attachments. Inspecione a imagem final e quaisquer dados intermediários que passes posteriores consumam. Em seguida, compare leituras e escritas externas junto com o tempo de GPU no dispositivo-alvo. Menos tráfego é uma evidência valiosa, mas geometria, shading ou sincronização ainda podem dominar o frame. Mantenha as decisões sobre ciclo de vida documentadas, para que um novo consumidor não passe a depender silenciosamente de conteúdo descartado.

Fontes

• [1] Picking the Most Efficient Load/Store Operations — Attilio Provenzano, Arm.
• [2] VkAttachmentLoadOp — Khronos Group, Vulkan specification.
• [3] VkAttachmentStoreOp — Khronos Group, Vulkan specification.