Apple Silicon TBDR: O Que os Desenvolvedores de Apps Realmente Recebem

As GPUs do Apple silicon não renderizam da mesma forma que outras GPUs renderizam. A documentação do Metal da Apple descreve a arquitetura pelo nome: “As GPUs no Apple silicon implementam uma técnica de renderização chamada tile-based deferred rendering (TBDR) que otimiza desempenho e eficiência energética.”¹ O formato TBDR é a razão pela qual a API do Metal 4, a stack de ML on-device e o modelo de programação de imageblock-and-tile-shader existem da forma como existem.

As seções abaixo percorrem os quatro recursos documentados pela Apple que o TBDR habilita e o que cada um traz para um app: imageblocks, tile shaders, raster order groups e a implementação aprimorada de multisample antialiasing. O post anterior sobre Metal 4 essentials cobriu a superfície central da API do Metal 4; o foco aqui é o substrato da GPU que essa superfície tem como alvo.

TL;DR

• O TBDR divide o destino de renderização em tiles, executa muitos em paralelo em núcleos separados da GPU e adia o sombreamento até depois que toda a geometria for avaliada para cada tile.¹
• A memória de tile tem largura de banda muitas vezes mais rápida do que a memória do dispositivo, latência muitas vezes menor e custo energético significativamente mais baixo.¹
• As GPUs da Apple A11 e posteriores adicionam imageblocks, tile shading, raster order groups e controle de cobertura de samples de imageblock. Os apps acessam todos eles através do Metal.¹
• Imageblocks permitem que um app defina estruturas de dados customizadas por pixel na memória de tile, persistam dados entre draws e dispatches e misturem trabalho de render com compute em um único pass.¹
• Raster order groups sincronizam threads de fragment que têm o mesmo pixel como alvo, eliminando a race condition de read-modify-write que quebra o blending dependente de ordem.¹

O Que o TBDR Realmente É

A definição da Apple, na íntegra: “A GPU divide o destino de renderização em uma grade de regiões menores, chamadas tiles. Ela processa cada tile com um de seus núcleos da GPU, frequentemente executando muitos ao mesmo tempo. A GPU adia, ou posterga, a fase de renderização para cada tile até depois de avaliar toda a geometria para aquele tile.”¹

O contraste com GPUs de modo imediato (IM) também é da Apple: “Uma GPU IM processa totalmente as primitivas, como linhas e triângulos, independentemente de elas estarem ou não visíveis na renderização.”¹ O TBDR evita esse trabalho ao reunir primeiro toda a geometria de um tile e depois sombrear apenas o que sobrevive à oclusão. A Apple afirma o ganho diretamente: “Uma GPU TBDR evita fazer trabalho desnecessário ao processar toda a geometria de um render pass ao mesmo tempo e sombrear apenas as primitivas visíveis.”¹

A memória de tile é o retorno. A Apple descreve suas vantagens sobre a memória do dispositivo:¹

• “Largura de banda que é muitas vezes mais rápida do que a memória do dispositivo”
• “Latência de acesso que é muitas vezes menor do que a memória do dispositivo”
• “Consumo de energia que é significativamente menor do que acessar a memória do dispositivo”

Dois render passes também podem se sobrepor no hardware. A Apple observa: “Enquanto a GPU executa os estágios finais de um render pass na memória de tile, ela pode iniciar o estágio de vértices de um render pass futuro. A GPU pode usar mais blocos de hardware ao mesmo tempo executando ambos os estágios em paralelo porque eles tendem a usar componentes de compute e memória diferentes.”¹

Esse é o substrato. Tudo abaixo o utiliza.

Imageblocks: Dados Customizados Por Pixel Na Memória De Tile

A definição de imageblock pela Apple: “Imageblocks são tiles de dados de imagem estruturados armazenados em memória local, permitindo que você descreva dados de imagem na memória de tile que as GPUs da Apple podem manipular de forma eficiente.”¹ São estruturas de dados 2D com largura, altura e profundidade de pixel, e “cada pixel em um imageblock pode consistir de múltiplos componentes, e você pode endereçar cada componente como sua própria fatia de imagem.”¹ O exemplo da Apple: um imageblock que contém três fatias de imagem para componentes albedo, specular e normal.

O formato que a Apple documenta:¹

• Disponível tanto para funções kernel quanto para funções fragment.
• Persistem durante o tempo de vida de um tile, entre draws e dispatches.
• Código de render existente cria automaticamente imageblocks que correspondem aos formatos dos render attachments.
• Os apps podem definir imageblocks customizados em shaders com canais adicionais, arrays e estruturas aninhadas.
• Um fragment shader vê apenas os dados do imageblock na posição daquele fragment; uma thread de função compute pode acessar o imageblock inteiro.

A persistência entre draws e dispatches é a parte operacionalmente interessante. A formulação da Apple: “A persistência de imageblock significa que você pode misturar operações de render e compute em um único rendering pass com tile shaders, onde ambos podem acessar a mesma memória local. Você pode criar algoritmos sofisticados que permanecem na memória local da GPU mantendo múltiplas operações dentro de um tile.”¹

Para um app que entrega um pipeline de renderização multiestágio (deferred shading, efeitos screen-space, blending customizado), manter resultados intermediários na memória de tile em vez de fazer round-trip pela memória do dispositivo é o orçamento por frame que o TBDR devolve.

Tile Shaders: Render E Compute, No Mesmo Pass

A formulação da Apple sobre tile shaders: “Tile shaders são funções compute ou fragment que executam como parte de um render pass. Eles permitem que seu app compute e salve dados na memória de tile que é persistente na GPU entre render passes.”¹

O modelo tradicional de GPU é o que os tile shaders contornam. Nas palavras da Apple: “GPUs tradicionais separam comandos de renderização e compute em passes distintos. Esses passes tipicamente não podem se comunicar diretamente entre si. Os apps contornam essa limitação salvando os resultados de um pass na memória do dispositivo e depois carregando esses dados de volta para o próximo pass. Em alguns cenários, como em um algoritmo de renderização multifásico, os apps podem copiar dados intermediários para a memória do dispositivo muitas vezes.”¹

Os tile shaders movem esses dados intermediários para a memória de tile. O retorno documentado pela Apple: “Apps que usam tile shaders podem evitar armazenar resultados intermediários na memória do dispositivo e economizar tempo armazenando dados na memória de tile mais rápida.”¹

Para apps Metal 4, os tile shaders se combinam com o design unificado do MTL4ComputeCommandEncoder coberto no post Metal 4 essentials. A unificação do encoder e o modelo de programação de tile shader são a mesma decisão arquitetural lida em duas camadas: colapsar fronteiras render-vs-compute que existem em GPUs tradicionais porque o hardware da GPU Apple não precisa delas.

Raster Order Groups: Ordenando Threads De Fragment Concorrentes

O problema que os raster order groups resolvem, nas palavras da Apple: “O Metal garante que a GPU faça blending na ordem das draw calls, dando a ilusão de que a GPU renderiza a cena sequencialmente. … Os fragment shaders para cada triângulo executam concorrentemente em sua própria thread. O fragment shader para o triângulo de trás pode não executar antes do fragment shader para o triângulo da frente, o que pode ser um problema para um shader que precisa dos resultados do shader de outro triângulo para sua função de blending customizada. Por causa da concorrência, essa sequência de read-modify-write pode criar uma race condition.”¹

O mecanismo: “Raster order groups superam esse conflito de acesso sincronizando threads que têm como alvo as mesmas coordenadas de pixel e sample (se você ativar sombreamento por sample).”¹

A superfície de implementação: “Para implementar raster order groups, anote ponteiros para a memória com um qualificador de atributo. Shaders que acessam pixels através desses ponteiros vão na ordem de submissão por pixel. O hardware espera que quaisquer threads de fragment shader mais antigas que se sobreponham à thread atual terminem antes que a thread atual prossiga.”¹

GPUs recentes da Apple estendem o mecanismo. Nas palavras da Apple: “O Metal em GPUs recentes da Apple estende raster order groups com capacidades adicionais. Eles permitem que você sincronize canais individuais de um imageblock e memória threadgroup. Você também pode criar múltiplos order groups, que dão sincronização mais granular e minimizam a frequência com que suas threads esperam por acesso.”¹

O exemplo trabalhado pela Apple é deferred shading. A abordagem tradicional de duas fases escreve um g-buffer de múltiplas texturas na memória do dispositivo e depois as lê de volta para a fase de iluminação. A formulação da Apple: “Você pode eliminar a necessidade das texturas intermediárias usando múltiplos order groups para mesclar ambas as fases de render em uma. Para fazer isso, mantenha o geometry buffer em pedaços do tamanho de tiles para que possam permanecer na memória local de imageblock.”¹

A divisão que a Apple recomenda:¹

• Primeiro order group: os três campos do g-buffer (albedo, normal, profundidade).
• Segundo order group: o resultado de iluminação acumulado.
• “As GPUs da Apple podem ordenar os dois grupos separadamente para que escritas pendentes no segundo grupo não impeçam as leituras do primeiro grupo.”¹

Duas threads ainda sincronizam no final da execução para acumular as luzes. O ganho é que as leituras não conflitantes executam concorrentemente em vez de serialmente.

MSAA Que Rastreia Samples Únicos Por Pixel

A implementação documentada de MSAA pela Apple em GPUs A11+ difere da descrição dos livros-texto. A formulação da Apple: “O hardware rastreia se cada pixel contém a borda de uma primitiva para que execute o blending por sample apenas quando necessário. Se outra primitiva cobre os samples dentro de um pixel, a GPU faz blending apenas uma vez para o pixel inteiro.”¹

O exemplo da Apple percorre a otimização. Um pixel coberto por duas bordas de triângulo sobrepostas tem três cores únicas em quatro posições de sample. Nas palavras da Apple: “GPUs da Apple anteriores ao A11 fazem blending de cada um dos três samples cobertos do pixel. A partir do A11, as GPUs da Apple fazem blending apenas duas vezes porque dois samples compartilham a mesma cor.”¹

A redução de cores vai mais além. Apple: “As GPUs da Apple podem reduzir o número de cores únicas em um pixel. Por exemplo, se a GPU renderiza um triângulo opaco em cima dos triângulos anteriores, ela representa o pixel por uma única cor.”¹

Os apps podem estender a implementação com tile shaders. O caso de uso documentado pela Apple: “Você pode implementar um algoritmo de resolve customizado modificando os dados de cobertura de sample nos tile shaders. Por exemplo, considere uma cena complexa que contém fases de render separadas para geometria opaca e translúcida. Você pode adicionar um tile shader que resolve os dados de sample para a geometria opaca antes de fazer blending da geometria translúcida.”¹

O tile shader executa em dados na memória local e pode fazer parte da fase de geometria opaca, mantendo o resolve na memória de tile em vez de passar por um pass separado.

O Que Isso Significa Para A Arquitetura De Apps

Três conclusões que decorrem da superfície documentada pela Apple.

1. A memória de tile é o orçamento. Os quatro recursos acima (imageblocks, tile shaders, raster order groups, cobertura de sample) existem todos para manter o trabalho na memória de tile e fora da memória do dispositivo. Os números documentados pela Apple: largura de banda muitas vezes mais rápida do que a memória do dispositivo, latência muitas vezes menor, energia significativamente menor.¹ Uma arquitetura de app que respeita esse orçamento executa mais rápido e mais frio do que uma que não respeita.

2. Render e compute não são mundos diferentes. A GPU da Apple não divide render e compute em passes distintos da forma como GPUs tradicionais fazem. A persistência de imageblock e os tile shaders permitem que um app execute algoritmos multifásicos dentro de um único render pass. O encoder de compute unificado do Metal 4 é a expressão em nível de API do mesmo fato arquitetural.

3. Concorrência é o padrão; ordenação é o opt-in. Raster order groups são como um app diz “esta sequência de read-modify-write depende de ordem”. O padrão é concorrência não ordenada, que é a forma natural da GPU. Apps que precisam de acesso ordenado para blending, transparência ou escritas no g-buffer anotam os ponteiros específicos e deixam o hardware sequenciar as threads.

O cluster completo do Apple Ecosystem: a API central do Metal 4 para a superfície paralela de API que tem como alvo este hardware; a LLM on-device do Foundation Models para o framework que executa ML no mesmo silicon; Core ML on-device inference para a stack de ML mais ampla. O hub está na Apple Ecosystem Series.

FAQ

O TBDR é específico do Metal 4?

Não. As GPUs do Apple silicon implementaram TBDR ao longo de muitas gerações de GPU; o Metal 4 é a nova superfície central de API que as tem como alvo. Os recursos de TBDR documentados aqui (imageblocks, tile shaders, raster order groups, controle de cobertura de sample do A11+) funcionam através do Metal tanto na API original com prefixo MTL quanto nos tipos com prefixo MTL4 do Metal 4.¹

Qual é a diferença entre um imageblock e memória threadgroup?

A distinção documentada pela Apple: “Memória threadgroup é adequada para dados não estruturados, mas um imageblock é mais adequado para dados de imagem.”¹ Imageblocks carregam uma estrutura 2D com largura, altura, profundidade de pixel e componentes nomeados por pixel; memória threadgroup é uma alocação plana. Apps que precisam de dados de imagem estruturados com fatias endereçáveis usam imageblocks; apps que precisam de buffers de scratch para kernels compute usam memória threadgroup.

Por que existem raster order groups se o Metal já garante blending na ordem das draw calls?

O Metal garante a aparência de blending sequencial, mas a GPU executa fragment shaders concorrentemente. A formulação da Apple: um shader que faz seu próprio blending customizado contra os resultados de outro triângulo encontra uma race condition porque as duas threads não são realmente sequenciais. Raster order groups são o mecanismo que sincroniza apenas as threads que têm como alvo o mesmo pixel, deixando o resto concorrente.¹

Quando devo escrever meu próprio algoritmo de resolve de MSAA?

A Apple documenta um caso concreto: uma cena com fases separadas para geometria opaca e translúcida, onde o resolve executa após a fase opaca, mas antes do blending translúcido.¹ Para a maioria dos apps, a implementação de MSAA embutida no hardware lida com o trabalho; resolves customizados são uma ferramenta para os casos extremos específicos que os documentos da Apple descrevem.

Como a otimização de MSAA da Apple economiza trabalho?

O hardware da Apple rastreia o número de samples únicos por pixel à medida que renderiza novas primitivas. O exemplo da Apple: um pixel coberto por duas bordas de triângulo tem três cores únicas em quatro posições de sample; GPUs A11+ fazem blending duas vezes em vez de três vezes porque dois samples compartilham uma cor, e um triângulo opaco posterior reduz o pixel de volta a uma única cor.¹ A otimização executa em nível de hardware; os apps a recebem sem mudanças na API.

A arquitetura da GPU da Apple está documentada em algum lugar além da página de TBDR?

O tópico “Apple silicon” da Apple na documentação do Metal aponta para a página de TBDR que sustenta este post. As sessões da WWDC da Apple sobre Metal também cobrem detalhes da arquitetura da GPU, e a Metal Shading Language Specification cobre a superfície em nível de shader. A Apple não publicou os detalhes subjacentes em nível de silicon (contagens de cluster, larguras de ALU, especificidades do raster engine) para uma determinada geração de GPU Apple na documentação para desenvolvedores; trate qualquer número desse tipo encontrado fora de developer.apple.com como não verificado.

Referências