Resumen Técnico: Renderizado de Gaussianas 3D en un Procesador de Grafos

Planteamiento del Problema

El Splatting de Gaussianas 3D (3DGS) se ha consolidado como un método líder para la síntesis de vistas novedosas en tiempo real, ofreciendo un renderizado fotorealista y una total diferenciabilidad. Sin embargo, las implementaciones actuales están fuertmente optimizadas para arquitecturas de GPU, que dependen de una gran memoria DRAM externa, alto ancho de banda de memoria y un espacio de direccionamiento global. En las GPUs, el renderizado de 3DGS está limitado por la memoria; el costo dominante es el movimiento repetido de los datos de las Gaussianas a través de la jerarquía de memoria (cargando desde la DRAM hacia la memoria compartida) en lugar de la computación aritmética.

Esta dependencia del acceso a la memoria global es ineficiente para las plataformas emergentes con recursos limitados, como las gafas de RA o los robots móviles, donde es deseable un cómputo "en el sensor" que utilice únicamente memoria local. El artículo aborda el desafío de adaptar el 3DGS a una arquitectura libre de DRAM que carece de un espacio de direccionamiento global y de memoria de acceso aleatorio, lo que obliga a que el movimiento de datos sea explícito y local.

Metodología

Los autores implementaron el primer renderizador de 3DGS en la Unidad de Procesamiento de Inteligencia (IPU) de Graphcore, un procesador masivamente paralelo compuesto por 1,472 teselas (tiles) independientes. Cada tesela posee 624 KB de SRAM local, 6 hilos de hardware y ninguna DRAM externa. La arquitectura sigue un modelo de Paralelismo Masivamente Síncrono (BSP) con canales de comunicación definidos explícitamente en tiempo de compilación.

Descripción General del Pipeline

El pipeline de renderizado mapea las cuatro etapas de 3DGS al modelo de ejecución BSP de la IPU, alternando entre computación local y comunicación entre teselas:

1. Proyección (Cómputo Local): Cada tesela proyecta sus Gaussianas almacenadas localmente en el espacio de pantalla 2D, computando medias, cónicas y cajas delimitadoras (bounding boxes).
2. Enrutamiento (Cómputo + Intercambio): Las Gaussianas cuyas medias proyectadas caen fuera de la región de pantalla local de una tesela son desalojadas. Se enrutan hacia su "tesela ancla" (la tesela que posee la región de pantalla que contiene la media de la Gaussiana) mediante saltos de distancia Manhattan en una cuadrícula Norte-Este-Oeste-Sur (NEWS). Este proceso se repite a lo largo de múltiples superpasos BSP hasta que todas las Gaussianas alcanzan sus teselas ancla.
3. Bloom (Cómputo + Intercambio): Una vez que una Gaussiana alcanza su tesela ancla, se propaga a las teselas vecinas cuyas regiones de pantalla se solapan con ella. Para evitar la copia cíclica y la saturación de los canales, los autores emplean una propagación de patrón de árbol: la tesela ancla envía copias horizontalmente, y esas teselas reenvían las copias verticalmente.
4. Composición (Cómputo Local): Cada tesela ordena de forma independiente sus Gaussianas locales por profundidad y realiza una composición alfa de frente a atrás sobre su segmento de framebuffer.

Restricciones Arquitectónicas Clave

• Sin Memoria Global: Los datos de la escena nunca salen de la SRAM en el chip. Todo el mapa de Gaussianas 3D se distribuye entre las teselas; ninguna tesela posee la escena completa.
• Movimiento de Datos Explícito: A diferencia de las GPUs donde los hilos pueden cargar direcciones globales arbitrarias, las teselas de la IPU solo pueden enviar/recibir datos definidos en tiempo de compilación. El algoritmo debe gestionar explícitamente la migración de las primitivas.
• Presupuesto de Memoria: Con aproximadamente 1,472 teselas, la memoria agregada es suficiente para escenas moderadas, pero las teselas individuales tienen límites estrictos (aproximadamente 192 KB disponibles para datos de Gaussianas tras contabilizar los buffers).

Principales Contribuciones

1. Primera Implementación de 3DGS Solo con SRAM: El artículo presenta el primer renderizado de Gaussianas 3D en una arquitectura de procesador MIMD (Múltiple Instrucción, Múltiples Datos) que depende exclusivamente de la SRAM en el chip, eliminando el acceso a la DRAM externa para los datos de la escena.
2. Esquema de Enrutamiento en Tiempo de Compilación: Un mecanismo novedoso para distribuir las primitivas de Gaussianas entre las teselas basándose en la propiedad del espacio de pantalla, operando dentro de las restricciones de canales de comunicación fijos definidos en tiempo de compilación.
3. Análisis de Rendimiento y Cuellos de Botella: Una evaluación detallada del rendimiento del sistema, identificando cuellos de botella específicos inherentes al renderizado sin DRAM:
   • Saturación del Ancho de Banda Entre Teselas: En regiones densas, los canales de salida pueden llenarse antes de que se propaguen todas las copias de las Gaussianas, lo que provoca "artefactos de teselado" (huecos rectangulares) en la imagen renderizada.
   • Presión de SRAM por Tesela: Una alta densidad de Gaussianas en regiones de pantalla específicas puede exceder la capacidad del buffer de una sola tesela, causando pérdida de datos.
   • Desequilibrio de Carga de Trabajo: La densidad no uniforme de las Gaussianas causa que algunas teselas sean significativamente más lentas que otras, deteniendo toda la barrera BSP.
4. Perspectivas para Futuras Arquitecturas: El trabajo sugiere que la comunicación explícita entre SM (Unidades de Procesamiento de Flujo) en las GPUs podría reducir el acceso a la DRAM, y que las representaciones 3D podrían diseñarse para explotar mejor la localidad espacial y temporal.

Resultados

• Calidad Visual: Para escenas de densidad moderada (por ejemplo, 25k–90k Gaussianas), el renderizado de la IPU es visualmente casi idéntico al de la línea base de la GPU, preservando detalles finos como texto y estructuras delgadas.
• Rendimiento (Throughput): El sistema logra tasas de fotogramas interactivas (aprox. 20 FPS) en una sola IPU para escenas pequeñas a medianas. Sin embargo, el rendimiento se degrada con escenas muy densas (por ejemplo, 273k Gaussianas) debido a los cuellos de botella mencionados anteriormente.
• Eficiencia Energética: Aunque el rendimiento bruto (FPS) de la IPU es menor que el de las GPUs de gama alta (GTX 1080, RTX 4090), su consumo de energía es significativamente menor (~27W frente a ~75–90W). La arquitectura demuestra que el 3DGS puede ejecutarse enteramente en el chip, siendo la comunicación con el host solo el 1.6% del tiempo de ejecución.
• Localidad de Datos: El sistema explota la localidad temporal de manera efectiva. Para movimientos de cámara incrementales (típicos en SLAM/RA), la "tasa de rotación" (fracción de Gaussianas que requieren re-enrutamiento) es muy baja (<12%), mientras que los teletransportes aleatorios requieren casi el 100% de re-enrutamiento.

Significado y Reivindicaciones

El artículo no pretende que la IPU sea un motor de renderizado de propósito general superior a las GPUs. En su lugar, utiliza la IPU como una plataforma experimental para demostrar que el 3DGS no requiere fundamentalmente de la DRAM.

Los autores argumentan que, al eliminar el espacio de direccionamiento global, la necesidad de un movimiento de datos explícito se hace evidente. Esto revela que:

1. La Localidad es Clave: El renderizado es más eficiente cuando se minimiza el movimiento de datos. El diseño de la IPU obliga al algoritmo a explotar el hecho de que, en escenarios de visualización incremental (robótica, RA), la mayoría de las primitivas permanecen cerca de sus ubicaciones previas en el espacio de pantalla.
2. Implicaciones Algorítmicas: Los cuellos de botella observados (ancho de banda, capacidad, desequilibrio) resaltan compromisos que podrían informar futuros diseños de kernels de GPU. Específicamente, los autores sugieren que la comunicación directa entre SM en las GPUs, en lugar de enrutar todos los datos entre bloques a través de la DRAM, podría reducir los costos de memoria dominantes de 3DGS.
3. Direcciones Futuras: El trabajo motiva el desarrollo de arquitecturas "en el sensor" y de borde para el renderizado diferenciable, sugiriendo que las futuras representaciones 3D y el hardware deben co-diseñarse para aprovechar la coherencia espacial y temporal, reduando potencialmente la potencia y la latencia al evitar el acceso a la memoria global.