Resumo Técnico: Renderização de Gaussianas 3D em um Processador de Grafos

Declaração do Problema

O 3D Gaussian Splatting (3DGS) estabeleceu-se como um método líder para síntese de visão novel em tempo real, oferecendo renderização fotorrealista e total diferenciabilidade. No entanto, as implementações atuais são fortemente otimizadas para arquiteturas de GPU, que dependem de um grande DRAM off-chip, alta largura de banda de memória e um espaço de endereçamento global. Em GPUs, a renderização de 3DGS é limitada pela memória (memory-bound); o custo dominante é o movimento repetido de dados Gaussianos através da hierarquia de memória (carregamento de DRAM para memória compartilhada) em vez da computação aritmética.

Essa dependência de acesso à memória global é ineficiente para plataformas emergentes com recursos limitados, como óculos de RA e robôs móveis, onde o computação "no sensor" (on-sensor) com apenas memória local é desejável. O artigo aborda o desafio de adaptar o 3DGS para uma arquitetura livre de DRAM que carece de um espaço de endereçamento global e memória de acesso aleatório, forçando o movimento de dados a ser explícito e local.

Metodologia

Os autores implementaram o primeiro renderizador de 3DGS na Unidade de Processamento de Inteligência (IPU) da Graphcore, um processador massivamente paralelo composto por 1.472 tiles independentes. Cada tile possui 624 KB de SRAM local, 6 threads de hardware e nenhum DRAM externo. A arquitetura segue um modelo de Processamento Paralelo de Grande Passo (BSP - Bulk Synchronous Parallel) com canais de comunicação explícitos e definidos em tempo de compilação.

Visão Geral do Pipeline

O pipeline de renderização mapeia os quatro estágios do 3DGS no modelo de execução BSP da IPU, alternando entre computação local e comunicação entre tiles:

1. Projeção (Computação Local): Cada tile projeta suas Gaussianas 3D armazenadas localmente em um espaço de tela 2D, computando médias, cônicos e caixas delimitadoras (bounding boxes).
2. Roteamento (Computação + Troca): Gaussianas cujas médias projetadas caem fora da região de tela local de um tile são expulsas. Elas são roteadas em direção ao seu "anchor tile" (o tile que detém a região de tela contendo a média da Gaussiana) via saltos de distância de Manhattan em uma grade Norte-Leste-Oeste-Sul (NEWS). Este processo se repete ao longo de múltiplos superpassos BSP até que todas as Gaussianas alcancem seus anchor tiles.
3. Bloom (Computação + Troca): Uma vez que uma Gaussiana alcança seu anchor tile, ela é propagada para os tiles vizinhos cujas regiões de tela ela sobrepõe. Para evitar cópias cíclicas e saturação de canais, os autores utilizam uma propagação de padrão de árvore: o anchor tile envia cópias horizontalmente, e esses tiles encaminham as cópias verticalmente.
4. Composição (Computação Local): Cada tile ordena independentemente suas Gaussianas locais por profundidade e realiza a composição alfa de frente para trás (front-to-back) em sua fatia de framebuffer.

Restrições Arquiteturais Chave

• Sem Memória Global: Os dados da cena nunca deixam a SRAM on-chip. Todo o mapa de Gaussianas 3D é distribuído entre os tiles; nenhum tile único detém a cena completa.
• Movimentação Explícita de Dados: Diferente das GPUs, onde as threads podem carregar endereços globais arbitrários, os tiles da IPU só podem enviar/receber dados definidos em tempo de compilação. O algoritmo deve gerenciar explicitamente a migração das primitivas.
• Orçamento de Memória: Com aproximadamente 1.472 tiles, a memória agregada é suficiente para cenas moderadas, mas os tiles individuais possuem limites estritos (aproximadamente 192 KB disponíveis para dados Gaussianos após considerar os buffers).

Principais Contribuições

1. Primeira Implementação de 3DGS Apenas com SRAM: O artigo apresenta a primeira renderização de Gaussianas 3D em uma arquitetura de processador MIMD (Multiple Instruction, Multiple Data) que depende exclusivamente de SRAM on-chip, eliminando o acesso ao DRAM externo para os dados da cena.
2. Esquema de Roteamento em Tempo de Compilação: Um mecanismo inovador para distribuir primitivas Gaussianas entre os tiles com base na propriedade do espaço de tela, operando dentro das restrições de canais de comunicação fixos e definidos em tempo de compilação.
3. Análise de Desempenho e Gargalos: Uma avaliação detalhada do desempenho do sistema, identificando gargalos específicos inerentes à renderização sem DRAM:
   • Saturação de Largura de Banda Inter-tile: Em regiões densas, os canais de saída podem encher antes que todas as cópias das Gaussianas sejam propagadas, levando a "artefatos de tiling" (buracos retangulares) na imagem renderizada.
   • Pressão de SRAM por Tile: A alta densidade de Gaussianas em regiões específicas da tela pode exceder a capacidade do buffer de um único tile, causando perda de dados.
   • Desequilíbrio de Carga: A densidade não uniforme de Gaussianas faz com que alguns tiles sejam significativamente mais lentos que outros, travando a barreira BSP inteira.
4. Insights para Arquiteturas Futuras: O trabalho sugere que a comunicação explícita entre SMs (Streaming Multiprocessors) em GPUs poderia reduzir o acesso ao DRAM, e que representações 3D poderiam ser projetadas para explorar melhor a localidade espacial e temporal.

Resultados

• Qualidade Visual: Para cenas de densidade moderada (ex: 25k–90k Gaussianas), a renderização na IPU é visualmente quase idêntica à linha de base da GPU, preservando detalhes finos como texto e estruturas finas.
• Vazão (Throughput): O sistema atinge taxas de quadros interativas (aprox. 20 FPS) em uma única IPU para cenas pequenas a médias. No entanto, o desempenho degrada com cenas muito densas (ex: 273k Gaussianas) devido aos gargalos mencionados anteriormente.
• Eficiência Energética: Embora a vazão bruta (FPS) da IPU seja inferior às GPUs de alto desempenho (GTX 1080, RTX 4090), seu consumo de energia é significativamente menor (~27W vs ~75–90W). A arquitetura demonstra que o 3DGS pode rodar inteiramente on-chip, com a comunicação com o host representando apenas 1,6% do tempo de execução.
• Localidade de Dados: O sistema explora a localidade temporal de forma eficaz. Para movimentos de câmera incrementais (típicos de SLAM/RA), a "taxa de churn" (fração de Gaussianas que requerem novo roteamento) é muito baixa (<12%), enquanto teletransportes aleatórios exigem quase 100% de novo roteamento.

Significância e Alegações

O artigo não alega que a IPU é um motor de renderização de propósito geral superior às GPUs. Em vez disso, utiliza a IPU como uma plataforma experimental para demonstrar que o 3DGS não requer fundamentalmente DRAM.

Os autores argumentam que, ao remover o espaço de endereçamento global, a necessidade de movimentação explícita de dados torna-se evidente. Isso revela que:

1. Localidade é a Chave: A renderização é mais eficiente quando o movimento de dados é minimizado. O design da IPU força o algoritmo a explorar o fato de que, em cenários de visualização incremental (robótica, RA), a maioria das primitivas permanece próxima de suas localizações anteriores no espaço de tela.
2. Implicações Algorítmicas: Os gargalos observados (largura de banda, capacidade, desequilíbrio) destacam compensações que poderiam informar futuros designs de kernels de GPU. Especificamente, os autores sugerem que a comunicação direta entre SMs em GPUs, em vez de rotear todos os dados entre blocos através do DRAM, poderia reduzir os custos de memória dominantes do 3DGS.
3. Direções Futuras: O trabalho motiva o desenvolvimento de arquiteturas "no sensor" e de borda para renderização diferenciável, sugerindo que futuras representações 3D e hardware devem ser co-projetados para aproveitar a coerência espacial e temporal, potencialmente reduzindo o consumo de energia e a latência ao evitar o acesso à memória global.