Atlas de textura frente a textura de matriz: ¿qué tan diferentes son manejados por la CPU y la GPU y cómo eso afecta el rendimiento?

Unity 5.4 (actualmente en versión beta), traerá una característica muy esperada (desde 2013) que es texturas de matriz, en el mismo vano que ArrayTexture de OpenGL . Sin embargo, después de leer un poco sobre las matrices-texturas y los atlas de texturas, todavía no puedo entender las diferencias técnicas en su uso por parte de las CPU y GPU.

Por lo tanto, para ser más específicos, me gustaría pedir una explicación sobre las principales diferencias entre cómo la CPU y la GPU tratan el atlas de textura y las matrices de textura y, lo que es más importante, cómo estas diferencias pueden afectar el rendimiento y el manejo de la memoria (p. Ej. cómo las matrices de texturas pueden tener más rendimiento que los atlas de texturas, etc.

Si faltan detalles técnicos sobre la implementación de Unity debido a su desafortunada fuente cerrada, estaría muy contento con una respuesta con respecto a OpenGL.s ArrayTexture.

textures rendering texture-atlas

— ASteer
fuente

No me sorprende que no haya encontrado una comparación técnica, ya que ambos dependen de la implementación (más para las matrices).

— wondra

Va a tener dificultades para obtener información sobre cómo funcionan las partes internas del motor de Unity, ya que es un cuadro negro de fuente cerrada. Lo único que puede hacer es perfilar cada caso y obtener una comparación del uso de CPU y GPU. Para comprender cómo funciona, se requeriría que un ingeniero de Unity intervenga o que se abra o filtre su código fuente.

— jgallant

@Jon Justo lo suficiente, pero en realidad estaba más interesado en una respuesta independiente del motor. Si varía tanto, puedo actualizar la pregunta para hablar, por ejemplo, de ArrayTexture de OpenGL: opengl.org/wiki/Array_Texture

— ASteer

Como se señaló en los comentarios anteriores, el rendimiento dependerá de la implementación, su hardware en particular y lo que está tratando de hacer con las texturas, por lo que la única respuesta confiable allí es perfilar cada alternativa.

Sin embargo, existen algunas diferencias en términos de cómo usa cada opción, que se aplicarán de manera consistente:

Una gran diferencia es que, para las texturas de matriz, cada textura se trata por separado para fines como envolver coordenadas de textura o mipmapping.

Esto evita problemas comunes con los atlas de texturas donde necesitamos agregar relleno entre muestras de texturas adyacentes para evitar que las muestras en sus bordes se desangren juntas, especialmente en niveles de mip más profundos.

Esto también significa que si desea que sus texturas se mezclen, puede usar el hardware de muestreo de textura para hacerlo al igual que con una textura de vainilla. Con los atlas, generalmente tenemos que hacer los cálculos de mosaico en nuestro sombreador de fragmentos, ya que el muestreador solo envuelve / refleja / sujeta / coordina las coordenadas de textura sobre todo el atlas, no los mosaicos individuales dentro de él.

La principal restricción con las texturas de matriz es que requieren que todas sus texturas constituyentes tengan la misma resolución y número de niveles de mip. Si está tratando de agrupar texturas con necesidades de resolución muy diferentes (por ejemplo, almacenar mosaicos de terreno cuyo LoD se cae con la distancia en una textura virtual ), entonces puede que desee la flexibilidad de un atlas.

— DMGregory
fuente

Gracias, eso fue exactamente lo que estaba buscando. Quiero decir, no es una respuesta precisa sobre cuál es más rápido y requiere menos memoria, ya que, por supuesto, esto depende de la implementación. Aún así, estaba seguro de que algunos consejos sobre el funcionamiento de cada caso podrían ser útiles para comprender sus escenarios habituales de mejor y peor ajuste. Su respuesta me ha ayudado en eso.

— ASteer

Otra desventaja de las texturas de matriz: están limitadas por GL_MAX_ARRAY_TEXTURE_LAYERS. En mi GPU semi-moderna, esto es 2048, así que si quieres toneladas de texturas pequeñas, este límite podría ser demasiado bajo.

— jwd