TBDR de Apple Silicon: lo que realmente obtienen los desarrolladores de apps

Las GPU de Apple silicon no renderizan como lo hacen otras GPU. La documentación de Metal de Apple describe la arquitectura por su nombre: “Las GPU de Apple silicon implementan una técnica de renderizado llamada tile-based deferred rendering (TBDR) que optimiza el rendimiento y la eficiencia energética.”¹ La forma TBDR es la razón por la que la API de Metal 4, el stack de ML en el dispositivo y el modelo de programación de imageblock-and-tile-shader existen tal como existen.

Las secciones siguientes recorren las cuatro funciones documentadas por Apple que TBDR habilita y lo que cada una le aporta a una app: imageblocks, tile shaders, raster order groups y la implementación mejorada de antialiasing por multimuestreo. La publicación anterior sobre lo esencial de Metal 4 cubrió la superficie central de la API de Metal 4; aquí el enfoque está en el sustrato de GPU al que apunta esa superficie.

TL;DR

• TBDR divide el destino de renderizado en tiles, ejecuta muchos en paralelo en distintos núcleos de GPU y aplaza el sombreado hasta después de evaluar toda la geometría de cada tile.¹
• La memoria de tile tiene un ancho de banda muchas veces más rápido que la memoria del dispositivo, una latencia muchas veces menor y un costo energético significativamente menor.¹
• A11 y las GPU posteriores de Apple añaden imageblocks, tile shading, raster order groups y control de cobertura de muestras de imageblock. Las apps acceden a todas estas funciones a través de Metal.¹
• Los imageblocks le permiten a una app definir estructuras de datos personalizadas por píxel en la memoria de tile, persistir datos entre draws y dispatches, y mezclar trabajo de renderizado con trabajo de cómputo en un solo pase.¹
• Los raster order groups sincronizan los hilos de fragmento que apuntan al mismo píxel, eliminando la condición de carrera de read-modify-write que rompe el blending dependiente del orden.¹

Qué es realmente TBDR

La formulación de Apple, textualmente: “La GPU divide el destino de renderizado en una cuadrícula de regiones más pequeñas, llamadas tiles. Procesa cada tile con uno de sus núcleos de GPU, a menudo ejecutando muchos al mismo tiempo. La GPU aplaza, o pospone, la fase de renderizado de cada tile hasta después de evaluar toda la geometría de ese tile.”¹

El contraste con las GPU de modo inmediato (IM) también es de Apple: “Una GPU IM procesa por completo las primitivas, como líneas y triángulos, independientemente de si son visibles o no en el renderizado.”¹ TBDR evita ese trabajo reuniendo primero toda la geometría de un tile y sombreando solo lo que sobrevive a la oclusión. Apple lo enuncia directamente: “Una GPU TBDR evita hacer trabajo innecesario procesando toda la geometría de un pase de renderizado al mismo tiempo y sombreando solo las primitivas visibles.”¹

La memoria de tile es la recompensa. Apple describe sus ventajas frente a la memoria del dispositivo:¹

• “Ancho de banda muchas veces más rápido que la memoria del dispositivo”
• “Latencia de acceso muchas veces menor que la de la memoria del dispositivo”
• “Consumo energético significativamente menor que el acceso a la memoria del dispositivo”

Dos pases de renderizado también pueden solaparse en el hardware. Apple lo explica: “Mientras la GPU ejecuta las etapas finales de un pase de renderizado hacia la memoria de tile, puede empezar la etapa de vértices de un pase de renderizado futuro. La GPU puede usar más bloques de hardware al mismo tiempo ejecutando ambas etapas en paralelo, porque tienden a usar componentes de cómputo y de memoria distintos.”¹

Ese es el sustrato. Todo lo que sigue lo aprovecha.

Imageblocks: datos personalizados por píxel en la memoria de tile

La definición de Apple de un imageblock: “Los imageblocks son tiles de datos de imagen estructurados almacenados en memoria local, que te permiten describir datos de imagen en memoria de tile que las GPU de Apple pueden manipular eficientemente.”¹ Son estructuras de datos 2D con un ancho, una altura y una profundidad de píxel, y “cada píxel de un imageblock puede constar de múltiples componentes, y puedes direccionar cada componente como su propia rebanada de imagen.”¹ El ejemplo de Apple: un imageblock que contiene tres rebanadas de imagen para los componentes albedo, especular y normal.

La forma que Apple documenta:¹

• Disponible para funciones tanto de kernel como de fragmento.
• Persiste durante la vida útil de un tile, entre draws y dispatches.
• El código de renderizado existente crea automáticamente imageblocks que coinciden con los formatos de los attachments de renderizado.
• Las apps pueden definir imageblocks personalizados en los shaders con canales adicionales, arreglos y estructuras anidadas.
• Un fragment shader solo ve los datos del imageblock en la posición de ese fragmento; un hilo de función de cómputo puede acceder al imageblock completo.

La persistencia entre draws y dispatches es la parte operativamente interesante. La formulación de Apple: “La persistencia de los imageblocks significa que puedes mezclar operaciones de renderizado y de cómputo en un único pase de renderizado con tile shaders, donde ambas pueden acceder a la misma memoria local. Puedes crear algoritmos sofisticados que permanecen en la memoria local de la GPU manteniendo varias operaciones dentro de un tile.”¹

Para una app que lleva un pipeline de renderizado de varias etapas (deferred shading, efectos de espacio de pantalla, blending personalizado), mantener los resultados intermedios en la memoria de tile en lugar de hacer un round-trip por la memoria del dispositivo es el presupuesto por frame que TBDR le devuelve.

Tile shaders: renderizado y cómputo en el mismo pase

La formulación de Apple sobre los tile shaders: “Los tile shaders son funciones de cómputo o de fragmento que se ejecutan como parte de un pase de renderizado. Le permiten a tu app calcular y guardar datos en la memoria de tile que persiste en la GPU entre pases de renderizado.”¹

El modelo tradicional de GPU es lo que los tile shaders sortean. Las palabras de Apple: “Las GPU tradicionales separan los comandos de renderizado y de cómputo en pases distintos. Estos pases normalmente no pueden comunicarse entre sí directamente. Las apps sortean esta limitación guardando los resultados de un pase en la memoria del dispositivo y luego cargando esos datos de vuelta para el siguiente pase. En algunos escenarios, como en un algoritmo de renderizado multifase, las apps pueden copiar datos intermedios a la memoria del dispositivo muchas veces.”¹

Los tile shaders trasladan esos datos intermedios a la memoria de tile. La recompensa documentada por Apple: “Las apps que usan tile shaders pueden evitar almacenar resultados intermedios en la memoria del dispositivo y ahorrar tiempo guardando los datos en la memoria de tile, que es más rápida.”¹

Para las apps de Metal 4, los tile shaders se combinan con el diseño unificado de MTL4ComputeCommandEncoder cubierto en la publicación de lo esencial de Metal 4. La unificación del encoder y el modelo de programación de tile shaders son la misma decisión arquitectónica leída en dos capas: colapsar las fronteras entre renderizado y cómputo que existen en las GPU tradicionales porque el hardware de la GPU de Apple no las necesita.

Raster order groups: ordenar hilos de fragmento concurrentes

El problema que resuelven los raster order groups, en palabras de Apple: “Metal garantiza que la GPU haga el blending en el orden de las llamadas de draw, dando la ilusión de que la GPU renderiza la escena secuencialmente. … Los fragment shaders de cada triángulo se ejecutan concurrentemente en su propio hilo. El fragment shader del triángulo trasero podría no ejecutarse antes que el fragment shader del triángulo delantero, lo cual puede ser un problema para un shader que necesita los resultados del shader de otro triángulo para su función de blending personalizado. Debido a la concurrencia, esta secuencia de read-modify-write puede crear una condición de carrera.”¹

El mecanismo: “Los raster order groups superan este conflicto de acceso sincronizando los hilos que apuntan a las mismas coordenadas de píxel y muestra (si activas el sombreado por muestra).”¹

La superficie de implementación: “Para implementar raster order groups, anota los punteros a memoria con un calificador de atributo. Los shaders que acceden a píxeles a través de esos punteros se ejecutan en el orden de envío por píxel. El hardware espera a que terminen los hilos de fragment shader más antiguos que se solapen con el hilo actual antes de que el hilo actual continúe.”¹

Las GPU recientes de Apple amplían el mecanismo. Las palabras de Apple: “Metal en las GPU recientes de Apple amplía los raster order groups con capacidades adicionales. Te permiten sincronizar canales individuales de un imageblock y memoria de threadgroup. También puedes crear varios order groups, lo que te da una sincronización más granular y minimiza la frecuencia con la que tus hilos esperan acceso.”¹

El ejemplo elaborado de Apple es el deferred shading. El enfoque tradicional de dos fases escribe un g-buffer de varias texturas en la memoria del dispositivo y luego las lee de vuelta para la fase de iluminación. La formulación de Apple: “Puedes eliminar la necesidad de las texturas intermedias usando varios order groups para fusionar ambas fases de renderizado en una. Para hacerlo, mantén el geometry buffer en trozos del tamaño de los tiles para que puedan permanecer en la memoria local de imageblock.”¹

La división que recomienda Apple:¹

• Primer order group: los tres campos del g-buffer (albedo, normal, profundidad).
• Segundo order group: el resultado de la iluminación acumulada.
• “Las GPU de Apple pueden ordenar los dos grupos por separado para que las escrituras pendientes en el segundo grupo no impidan las lecturas del primero.”¹

Dos hilos aún se sincronizan al final de la ejecución para acumular las luces. La ganancia es que las lecturas no conflictivas se ejecutan concurrentemente en lugar de en serie.

MSAA que rastrea muestras únicas por píxel

La implementación de MSAA documentada por Apple en las GPU A11+ difiere de la descripción de manual. La formulación de Apple: “El hardware rastrea si cada píxel contiene el borde de una primitiva, de modo que ejecuta el blending por muestra solo cuando es necesario. Si otra primitiva cubre las muestras dentro de un píxel, la GPU hace blending solo una vez para todo el píxel.”¹

El ejemplo de Apple recorre la optimización. Un píxel cubierto por dos bordes de triángulo solapados tiene tres colores únicos en cuatro posiciones de muestra. Las palabras de Apple: “Las GPU de Apple anteriores a A11 hacen blending de cada una de las tres muestras cubiertas del píxel. A partir de A11, las GPU de Apple hacen blending solo dos veces porque dos muestras comparten el mismo color.”¹

La reducción de colores va más allá. Apple: “Las GPU de Apple pueden reducir el número de colores únicos en un píxel. Por ejemplo, si la GPU renderiza un triángulo opaco encima de los triángulos anteriores, representa el píxel con un único color.”¹

Las apps pueden ampliar la implementación con tile shaders. El caso de uso documentado por Apple: “Puedes implementar un algoritmo de resolución personalizado modificando los datos de cobertura de muestras en los tile shaders. Por ejemplo, considera una escena compleja que contiene fases de renderizado separadas para geometría opaca y traslúcida. Puedes añadir un tile shader que resuelva los datos de muestra de la geometría opaca antes de hacer blending de la geometría traslúcida.”¹

El tile shader se ejecuta sobre los datos en la memoria local y puede formar parte de la fase de geometría opaca, manteniendo la resolución en la memoria de tile en lugar de hacer un rodeo por un pase aparte.

Qué significa esto para la arquitectura de las apps

Tres conclusiones que se desprenden de la superficie documentada por Apple.

1. La memoria de tile es el presupuesto. Las cuatro funciones anteriores (imageblocks, tile shaders, raster order groups, cobertura de muestras) existen para mantener el trabajo en la memoria de tile y fuera de la memoria del dispositivo. Los números documentados por Apple: ancho de banda muchas veces más rápido que la memoria del dispositivo, latencia muchas veces menor, energía significativamente menor.¹ Una arquitectura de app que respete ese presupuesto se ejecuta más rápido y más fría que una que no lo haga.

2. Renderizado y cómputo no son mundos distintos. La GPU de Apple no separa el renderizado y el cómputo en pases distintos como lo hacen las GPU tradicionales. La persistencia de los imageblocks y los tile shaders le permiten a una app ejecutar algoritmos multifase dentro de un único pase de renderizado. El compute encoder unificado de Metal 4 es la expresión a nivel de API del mismo hecho arquitectónico.

3. La concurrencia es el valor por defecto; el orden es el opt-in. Los raster order groups son la manera en que una app dice “esta secuencia de read-modify-write depende del orden”. El valor por defecto es la concurrencia sin orden, que es la forma natural de la GPU. Las apps que necesitan acceso ordenado para blending, transparencia o escrituras al g-buffer anotan los punteros específicos y dejan que el hardware secuencie los hilos.

El cluster completo del Apple Ecosystem: la API central de Metal 4 para la superficie de API paralela que apunta a este hardware; el LLM en el dispositivo de Foundation Models para el framework que ejecuta ML sobre el mismo silicio; inferencia en el dispositivo con Core ML para el stack de ML más amplio. El hub está en la Apple Ecosystem Series.

FAQ

¿TBDR es específico de Metal 4?

No. Las GPU de Apple silicon han implementado TBDR a lo largo de muchas generaciones de GPU; Metal 4 es la nueva superficie central de API que apunta a ellas. Las funciones de TBDR documentadas aquí (imageblocks, tile shaders, raster order groups, control de cobertura de muestras de A11+) funcionan a través de Metal tanto en la API original con prefijo MTL como en los tipos de Metal 4 con prefijo MTL4.¹

¿Cuál es la diferencia entre un imageblock y la memoria de threadgroup?

La distinción documentada por Apple: “La memoria de threadgroup es adecuada para datos no estructurados, pero un imageblock es más adecuado para datos de imagen.”¹ Los imageblocks llevan una estructura 2D con un ancho, una altura, una profundidad de píxel y componentes nombrados por píxel; la memoria de threadgroup es una asignación plana. Las apps que necesitan datos de imagen estructurados con rebanadas direccionables usan imageblocks; las apps que necesitan buffers de scratch para kernels de cómputo usan memoria de threadgroup.

¿Por qué existen los raster order groups si Metal ya garantiza el blending en el orden de las llamadas de draw?

Metal garantiza la apariencia de un blending secuencial, pero la GPU ejecuta los fragment shaders concurrentemente. La formulación de Apple: un shader que hace su propio blending personalizado contra los resultados de otro triángulo se topa con una condición de carrera porque los dos hilos no son realmente secuenciales. Los raster order groups son el mecanismo que sincroniza únicamente los hilos que apuntan al mismo píxel, dejando el resto concurrente.¹

¿Cuándo debería escribir mi propio algoritmo de resolución de MSAA?

Apple documenta un caso concreto: una escena con fases separadas para geometría opaca y traslúcida, donde la resolución se ejecuta después de la fase opaca pero antes del blending de la traslúcida.¹ Para la mayoría de las apps, la implementación de MSAA integrada en el hardware se encarga del trabajo; las resoluciones personalizadas son una herramienta para los casos límite específicos que describen los documentos de Apple.

¿Cómo ahorra trabajo la optimización de MSAA de Apple?

El hardware de Apple rastrea el número de muestras únicas por píxel a medida que renderiza nuevas primitivas. El ejemplo de Apple: un píxel cubierto por dos bordes de triángulo tiene tres colores únicos en cuatro posiciones de muestra; las GPU A11+ hacen blending dos veces en lugar de tres porque dos muestras comparten un color, y un triángulo opaco posterior reduce el píxel a un único color.¹ La optimización se ejecuta a nivel de hardware; las apps la obtienen sin cambios en la API.

¿La arquitectura de la GPU de Apple está documentada en algún sitio aparte de la página de TBDR?

El tema “Apple silicon” en la documentación de Metal de Apple enlaza con la página de TBDR que respalda esta publicación. Las sesiones de la WWDC de Apple sobre Metal también cubren detalles de la arquitectura de la GPU, y la Metal Shading Language Specification cubre la superficie a nivel de shader. Apple no ha publicado los detalles subyacentes a nivel de silicio (cantidad de clusters, anchos de ALU, especificaciones del motor de rasterizado) para una generación dada de GPU de Apple en la documentación para desarrolladores; trata cualquier número de ese tipo que encuentres fuera de developer.apple.com como no verificado.

Referencias