Render graphs: declarar dependencias y controlar el ciclo de vida de los recursos

Describir el frame como flujo de datos

Un renderer se vuelve difícil de modificar cuando la propiedad de los recursos es implícita. Un pass de posprocesado puede leer una imagen que otra funcionalidad sobrescribe de forma inesperada, o mantener viva una textura temporal durante todo el frame. Conviene empezar describiendo las entradas, las salidas y los efectos visibles externamente de cada pass. Este contrato permite revisar las dependencias de una funcionalidad nueva antes de que se ejecuten sus comandos.

Separar la declaración de la ejecución

Un render graph registra los passes y el uso de recursos, y a partir de ahí deriva un plan de ejecución. El RDG de Unreal puede descartar trabajo que no se usa, gestionar recursos transitorios y planificar la sincronización. Distingue entre los recursos cuyo ciclo de vida permanece dentro del grafo y los recursos externos, que sobreviven fuera de él. [1] Declarar una lectura o una escritura es una obligación de corrección: un acceso no declarado deja al planificador con una descripción incompleta del frame.

Un ejemplo práctico de aliasing

Tomemos cuatro passes ordenados. El primero escribe una máscara temporal de 8 MiB; el segundo consume su contenido final. Solo después el tercero crea un intermedio de desenfoque de 16 MiB, que consume el cuarto. Si los requisitos de memoria son compatibles y la ejecución impide un uso solapado, los dos recursos temporales pueden compartir, en el caso ideal, una región de 16 MiB en lugar de ocupar regiones separadas que suman 24 MiB.

Este cálculo no incluye la sobrecarga de la asignación ni el resto de los recursos del frame. Si el cuarto pass también lee la máscara original, los ciclos de vida se solapan y la reutilización propuesta deja de ser válida. El orden en que la CPU registra los comandos no basta por sí solo para demostrar que los accesos de la GPU han terminado. Hay que inspeccionar la línea temporal real de los recursos y sus dependencias.

Validar el contrato de recursos

Nombra los recursos según su propósito. Declara con precisión las lecturas, las escrituras y los subrecursos relevantes, y define si una imagen recién asignada debe limpiarse o sobrescribirse por completo. El historial temporal y otros datos persistentes deben quedar bajo una propiedad externa explícita.

Usa la visualización del grafo y la validación de la API mientras activas los efectos de uno en uno. La guía de sincronización de Vulkan describe las barreras de pipeline como un control sobre qué etapas deben esperar a etapas anteriores. [2] En última instancia, el grafo debe generar una sincronización adecuada para la API subyacente. Al diagnosticar corrupción, compara la salida con el aliasing o la planificación asíncrona desactivados; trata esa comparación como evidencia, no como una solución permanente.

Medir el equilibrio de la planificación

El cómputo asíncrono puede solapar trabajo independiente, pero los passes concurrentes pueden competir por la capacidad de ejecución o por el ancho de banda de memoria. Además, el solapamiento de sus ciclos de vida puede reducir las oportunidades de reutilizar memoria. Compara la duración en GPU, el pico de asignación transitoria y el coste de registro en CPU con la carga de trabajo objetivo.

Conserva los historiales de recursos de un frame normal, de un cambio de resolución y de una transición con un efecto desactivado. Un grafo que renderiza correctamente una captura de pantalla aún puede contener una lectura sin inicializar o una ampliación involuntaria de un ciclo de vida en otra ruta. Optimiza solo cuando esas rutas tengan una política clara de propiedad e inicialización.

Fuentes

[1] Render Dependency Graph — Epic Games.

[2] Vulkan synchronization guide — Khronos Group.