Cualquiera que use Unity para desarrollar proyectos sabe que al cambiar de plataforma en Build Settings, la textura se comprimirá de acuerdo con el formato de compresión de la plataforma correspondiente especificado por cada textura. La compresión de texturas es muy lenta y ocupará más de la mitad del tiempo total. ¿Se puede reducir este tiempo? Esta demanda de la empresa se recibió en el otoño de 2018.
Vi a alguien en Internet tratando de resolver este problema antes. Para decirlo sin rodeos, es transferir la presión de la CPU defectuosa (el autor se refiere principalmente a Mac) a la CPU potente (alta frecuencia y más núcleos), ver https: // blog .codingnow.com / 2016/12 / unity3d_remote_pvrtextool.html . Este programa abre al menos una idea esclarecedora.
Sin embargo, el esquema anterior es teóricamente varias veces más rápido como máximo, y la compresión de texturas aún llevará mucho tiempo, porque el rendimiento de las CPU civiles comunes no diferirá mucho.
¿Cómo se puede aumentar mucho la velocidad? Recordé que la compilación conjunta se usa a menudo al desarrollar motores, y me inspiré en esto (Lightmass en UE4 es muy lento para hornear Lightmaps, así que implementé un Swarm, que se puede hornear de manera distribuida. Esta es también la forma) : ¿Por qué no dividir la textura y usar Comprimido de forma distribuida? Una vez completada la compresión, se ensambla una textura completa. Todos sabemos que las CPU de las máquinas de las estaciones de trabajo de la empresa están inactivas la mayor parte del tiempo, y también hay muchos servidores obsoletos dentro de la empresa. Si hace esto, teóricamente puede mejorar en varios órdenes de magnitud. Muy emocionado, ¿qué pasa?
Afortunadamente, la compañía compró el código fuente de Unity y rápidamente descubrió el proceso de compresión de texturas: Unity iniciará diferentes procesos de herramientas de línea de comandos para procesar según el formato de compresión, como PVRTexTool.exe, etccompress.exe; ASTC es más especial Una biblioteca de código abierto comprimida por ASTC se compila directamente en el motor, independientemente de esto, la demostración técnica no maneja esta situación. Una vez finalizado el proceso de la herramienta de compresión, Unity seguirá ejecutándose. Escriba su propio código para compilar la herramienta Proxy. Estas herramientas se denominan PVRTexTool.exe y etccompress.exe, y reemplazan a las de Unity. Estas herramientas de proxy son solo una estación de transferencia, que cargan parámetros de comando y datos de textura sin comprimir al servidor central y al servidor de datos, respectivamente. El servidor divide la textura y entrega los pequeños trozos de textura a diferentes servidores de tareas para su compresión. Una vez completada la compresión, se fusiona en una textura completa y se devuelve al editor de Unity a través de la red. Para el método especial de ASTC, la tecnología Hook se puede utilizar para reenviar parámetros de comando y datos de textura, pero no hay tiempo para intentarlo (de hecho, se recomienda encarecidamente que Unity compile oficialmente esta biblioteca de código abierto en un programa ejecutable que reciba parámetros de la línea de comandos, para que se pueda procesar unificado).
Diagrama de compresión distribuida:
De hecho, no hay ningún problema técnico y la textura del formato PVR se atasca cuando se divide, porque los elementos de textura en el PVR están dispuestos en zigzag. La razón principal es que la proporción de ingeniería es relativamente grande, por lo que hay mucho trabajo fino y necesita ser compatible con Windows, MacOS y Linux, y necesita usar varios idiomas e IDE. Sin embargo, debido a la grave escasez de mano de obra, solo se completaron demostraciones de diversas tecnologías. Todavía queda un largo camino por recorrer desde la demostración técnica hasta la producción, y es necesario resolver varios problemas menores, por lo que se necesita un equipo.
Después de la prueba real, hay una mejora significativa en el rendimiento: después de probar la compresión distribuida en tres computadoras, el rendimiento de la compresión es básicamente proporcional al aumento en el número de servidores.
Por supuesto, este método también tiene desventajas: es problemático dividir texturas, por ejemplo, las texturas tienen muchos formatos, incluidos 2D, 3D, Cubemap y Mipmap. También hay una pérdida significativa de rendimiento, porque la división, la transmisión de red y la fusión llevan tiempo.
Vi un artículo hace dos días, y el funcionario de Unity finalmente tomó medidas para resolver este problema: "Optimización de texturas en Unity 2021.1 beta, hasta 3.1 veces más rápido", consulte https://mp.weixin.qq.com/s/ GEC6zzNVXKySNcU5gHQAcg . El método utilizado es aplicar SIMD u optimización de subprocesos y utilizar la última biblioteca de compresión o la biblioteca de compresión optimizada para la compresión de texturas.
Sin embargo, las personas que a menudo optimizan el rendimiento tienen sentido común: la optimización para el nivel de idioma generalmente solo puede optimizar unas pocas veces la velocidad como máximo (no levante el listón, es normal optimizar el código que es demasiado malo para escribirse cientos de veces la velocidad); y Si elige una arquitectura o algoritmo diferente, la mejora del rendimiento puede alcanzar varios órdenes de magnitud.
¿Existe una forma mejor? Creo que, en teoría, la "compresión asincrónica distribuida" es una solución que se puede considerar. Es decir, no ejecute sincrónicamente al comprimir texturas. Deseche las texturas que deben comprimirse directamente para que se ejecute la máquina de trabajo en red, y Unity continuará realizando otras tareas de conmutación de plataformas. Por supuesto, la elección del método asincrónico requiere un requisito previo: la ejecución de cualquier trabajo no depende de la finalización de la compresión de la textura, a excepción del empaque. Esto ahorra 2/3 del tiempo.
¿Se siente un poco interesante? Si es así, puede ponerse en contacto conmigo y divertirse juntos.