Unity Burst y Jobs: diseñar las dependencias en torno a datos nativos compartidos

Separar la compilación de la planificación

Burst admite un subconjunto restringido de C# apto para compilación nativa; el Job System planifica el trabajo y sus dependencias. Añadir [BurstCompile] no define el orden en que jobs distintos pueden acceder a datos compartidos. Conviene diseñar primero el flujo de datos y después adaptar el cálculo a los tipos que Burst admite. Este artículo se basa en los contratos descritos en la documentación citada de Unity 6.0 y Burst 1.8. [1][3]

Declarar el acceso a la memoria reservada

Un NativeArray<T> da acceso a memoria nativa. Las copias de este valor de contenedor apuntan a la misma reserva de memoria subyacente, de modo que pasar el contenedor a varios jobs no da a cada uno un búfer de resultados independiente. [2][3]

Marca un campo del job con [ReadOnly] cuando ese job solo lo lee. Así varios lectores pueden compartir la entrada sin declarar por error acceso de escritura. Un productor que escribe un array y un consumidor que lo lee necesitan una dependencia explícita. El hilo principal también debe respetar los accesos pendientes: no está exento de las reglas de seguridad del contenedor. [2]

Un cálculo ilustrativo con boyas

Supongamos que una escena tiene 256 boyas. Se preparan sus posiciones como datos de entrada. Un job de muestreo de oleaje escribe un array de alturas, mientras que un job independiente de muestreo de viento escribe un array de viento. Ambos pueden leer el array de posiciones; ninguno de los dos productores debe sobrescribir la salida del otro.

Combina sus handles con JobHandle.CombineDependencies y pasa el handle combinado al planificar un job de cálculo de fuerzas que lee ambos resultados. La combinación hace que el consumidor espere a los dos productores. No obliga a que los productores se ejecuten a la vez, y el orden en que se planifiquen no bastaría por sí solo para establecer la dependencia necesaria. Estos nombres y el número de boyas describen un diseño de proyecto propuesto. [3]

Elegir cómo se entrega el resultado al hilo principal

Conserva el handle del último job. Llama a Complete antes de que el hilo principal lea su búfer de resultados y aplica después, desde el hilo principal, los cambios resultantes en la escena. Completar ese job dependiente también completa las dependencias que necesita su resultado. [3]

Sitúa este traspaso donde el resultado se necesite realmente. Completar de inmediato cada productor elimina oportunidades de solapar trabajo útil. Mantén también claro quién es el propietario del contenedor durante una cancelación o el desmontaje de la escena: termina los accesos pendientes antes de liberar la memoria con Dispose. Elige un allocator cuyo tiempo de vida documentado se ajuste al tiempo que el búfer seguirá en uso. [2][3]

Comprobar el límite y medir la carga de trabajo

Los grafos habituales de objetos gestionados quedan fuera del modelo de datos que admite Burst. Prepara datos de valor adecuados y contenedores nativos en lugar de pasar referencias a objetos de la escena al núcleo numérico. Consulta la referencia de tipos para ver las excepciones y restricciones concretas; el soporte es más preciso que la afirmación general de que cualquier construcción de C# funciona. [1]

Revisa la canalización de las boyas en busca de dependencias que falten, escrituras accidentales, completados prematuros y reservas de memoria repetidas. Mide en el dispositivo de destino la sobrecarga de planificación, el cálculo y la espera del hilo principal. Un grafo de dependencias válido garantiza un orden seguro; no promete una aceleración en cargas de trabajo pequeñas.

Fuentes

1. C# type support — Burst 1.8 — Unity Technologies.
2. Introduction to NativeContainer — Unity Technologies.
3. Job dependencies — Unity Technologies.