GPU basadas en tiles: elegir con criterio las operaciones de carga y almacenamiento de los attachments

Tratar un attachment como un dato con ciclo de vida

Una GPU basada en tiles procesa pequeñas regiones del framebuffer usando almacenamiento local. Restaurar el contenido anterior de un attachment o exportar resultados intermedios puede generar tráfico hacia la memoria externa. Las operaciones de carga y almacenamiento (load/store) de un attachment indican a la implementación qué contenido importa en los límites del renderizado. La explicación para desarrolladores de Arm muestra por qué estas decisiones pueden afectar de forma considerable al ancho de banda en las GPU móviles. [1]

Para cada attachment de color, profundidad y stencil, hay que identificar quién produce su contenido inicial y quién necesita el resultado final. Un buffer de profundidad que se usa solo durante un intervalo de renderizado tiene requisitos distintos de los de una profundidad que muestrean efectos posteriores.

Elegir el estado inicial según las lecturas reales

Usa LOAD cuando haya que conservar el contenido previo. Usa CLEAR cuando se necesite un valor inicial uniforme y definido. Usa DONT_CARE solo cuando el contenido previo no haga falta y todos los valores que se lean después estén inicializados correctamente. Vulkan define el contenido inicial descartado como indefinido dentro del área de renderizado. [2]

Que un draw parezca cubrir toda la pantalla no basta para asegurar que se haya sobrescrito todo: el rechazo por profundidad, los scissors, las máscaras de escritura o el blending pueden mantener dependencias con el contenido anterior. En hardware de tiles adecuado, limpiar mediante la operación del attachment puede inicializar el almacenamiento local del tile sin restaurar la imagen previa. [1]

Ejemplo práctico: estimar la magnitud de la transferencia

Un attachment ilustrativo de 1920 por 1080 con 4 bytes por píxel ocupa 1920 * 1080 * 4 = 8294400 bytes. Una carga completa más un almacenamiento completo transfieren 16588800 bytes en un modelo de cálculo sin compresión.

A 60 fotogramas por segundo, esto da 16588800 * 60 = 995328000 bytes por segundo, aproximadamente 0.995 GB/s. Esta cifra no es ancho de banda medido ni un ahorro garantizado: la compresión, las cachés, las áreas de renderizado parciales y las decisiones de la implementación modifican el tráfico real. El cálculo sirve para ver por qué conviene investigar un viaje de ida y vuelta innecesario de un attachment.

Conservar el contenido final solo donde haga falta

Almacena los resultados que necesiten la presentación, un renderizado posterior o una lectura de vuelta (readback). Si ya no se necesita el contenido de un attachment, una operación de almacenamiento con descarte permite evitar conservarlo. El almacenamiento DONT_CARE de Vulkan deja ese contenido indefinido. Su operación NONE tiene una semántica distinta y no debe tratarse como una forma de conservar datos recién escritos para un pase posterior. [3]

Para attachments temporales adecuados, conviene investigar el uso transient y la asignación diferida (lazy allocation) si el dispositivo la admite. Mantén juntas las tareas compatibles cuando eso permita reutilizar el almacenamiento local, pero verifica la ejecución real en lugar de suponer que todos los pases lógicos se fusionan. Las lecturas de píxeles vecinos pueden requerir una ruta de memoria distinta. [1]

Verificar la corrección antes de interpretar los contadores

Prueba la cobertura parcial, los overlays, los consumidores de profundidad y los tamaños de salida alternativos después de cambiar las operaciones de los attachments. Inspecciona la imagen final y cualquier dato intermedio que consuman los pases posteriores. Después, compara las lecturas y escrituras externas junto con el tiempo de GPU en el dispositivo de destino. Un menor tráfico es una evidencia valiosa, pero la geometría, el sombreado o la sincronización pueden seguir dominando el coste del frame. Deja documentadas las decisiones sobre el ciclo de vida para que un consumidor añadido más adelante no dependa sin querer de contenido descartado.

Fuentes

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