Unreal Engine Swarm Agents sobre máquinas virtuales en ESXi 5.5

Fig. 1: máquinas reales vs. máquinas virtuales peleando en un cálculo de lightmassing para una evaluación de un viaducto en fase de diseño para VR. Cada línea es un core, líneas cortas, proceso  terminado antes, líneas largas, proceso de mayor duración o incluso sin acabar.

Con un título tan poco alentador cuelgo esta entrada que hace la número 100 en este blog.

Me suelen decir que mis artículos son demasiado técnicos, muy poco atractivos a la hora de evangelizar a las masas o de darme publicidad, pero sinceramente me da igual, ya hay quien se dedica a esos menesteres. Debo haber tenido algún antepasado luterano y así me va. Quien haya llegado aquí y no por desavisado, tendrá la oportunidad de comprobar como comenzamos la doctrina:

Según avanza el curso de Unreal Engine aplicado a arquitectura que voy haciendo (para corregir vicios y conceptos mal adquiridos) y según la carga de trabajo me permite (tarde, mal y nunca), voy por un lado ensamblando las piezas que compondrán mi flujo de Revit a Unreal Engine (BIM2VR) y por otro divagando con aventuras que creo que acelerarán ese flujo de trabajo hasta hacerlo tan cotidiano como un render de 3DSMax.

La calidad que se obtiene en UE4 responde a muy diversos factores siendo uno de ellos el cálculo de distribución de la luz, como sucede con motores de render como Vray. Si bien con objetos estacionarios o movibles y en exteriores se puede recurrir a iluminación en tiempo real, quienes desarrollamos no hemos de olvidar que el cliente ni tiene, ni tendrá máquinas como las que tenemos nosotros y que por tanto nos arriesgamos a que nuestra aplicación interactiva en tiempo real tan pulida, tan resultona y tan fluida sea un desastre en los ordenadores del cliente.

• Por tanto la primera premisa es: utilizar en lo posible iluminación precalculada, procurando tener un balance equilibrado en el número de mallas estáticas de tal forma que no las haya muy grandes que exijan mapas enormes ergo cálculos muy largos.
• La segunda es tener en cuenta el proceso distribuido, simétrico, paralelo que supone el cálculo de n lightmaps.
• La tercera es que la variable n vendrá dada en función del número de mallas estáticas que tengamos en la escena. Más o menos, y debido a que el algoritmo de lightmass decide por su cuenta o en base a escondidos parámetros guardados en algún .ini agrupar o no algunos lightmaps en atlas más grandes por optimizar recursos de memoria.

Aprovechando ofertas de amistades he dejado provisionalmente mi estudio como un taller de reparación de ordenadores, ya que en poco tiempo han entrado varios servidores (6) de todo pelo, desde «desktop» de los de poner en el suelo a un enrackable como el de la figura 2.

Fig. 2: esperanzador aspecto de la primera pantalla en el boot interminable de este System X

Me hacía especial ilusión que un IBM genuino volviera a entrar en mi vida. Aprendí a programar en los tiempos de los IBM PC y XT con pantallas de fósforo verde y cariñosas impresoras matriciales. Las características de este equipo hacían que aceptara la oferta de probarlo para cálculos que no tienen en principio nada que ver con los que llevaron a crearlo: 4 Xeon relativamente viejos (2010) que suman 16 núcleos y 128 GB de RAM. Puesto que un Windows normal sólo acepta 2 procesadores físicos, había que elegir entre Windows Server, Linux o algo para mí desconocido hasta entonces que es VMware ESXi. Opté por este último porque en su versión 5.5 es de libre disposición, muy contenido en su instalación, muy de pantalla de fósforo verde, es decir, textos y nada de interface gráfica y con un parque instalado suficientemente garantista.

Fig. 3: Interior del bicho

La modularidad de estos aparatos, en los cuales casi todo es intercambiable en caliente, es increíble. El arranque es eterno, debido entre otras cosas al número de tarjetas que traía instaladas y diversos chequeos.

Vaciado de todo lo que no era estrictamente necesario (tarjetas de red convencionales y fibre channel) e instalado el S.O., el arranque es ya más «rápido». En este momento deja de ser necesario monitor y teclado, puesto que todo el proceso de instalación de máquinas virtuales se realiza de forma remota desde VMware vSphere Client. Decidí crear dos, con las características que se puede ver en la figura 1.

Instalados los componentes que requiere Swarm Agent, Ip’s, parámetros varios y reconocidas las máquinas virtuales por Swarm Coordinator los cálculos de luz fluían…. como no esperaba, es decir, muy mal para los Xeones del servidor X. Y es que según las comparativas, estos procesadores son ya muy viejos y con unas características que se han visto superadas de largo por otros Xeon no tan antiguos e I7.

Días después realicé otras pruebas con otros servidores equipados con Xeon más recientes de hasta 16 cores que reafirmaron tan empíricamente la idea de que el x3850M2 ya no es una máquina para realizar cálculos de lightmass tendiendo en cuenta el nivel de ruido que tiene y sobre todo el consumo, más 1400 W de fuente de alimentación (redundante).

Fig. 4: lo que se llama «dar sopas con ondas» en relación a la Fig. 1. Todas son máquinas físicas.

Tanto en la figura 1 como en la 4 se pueden apreciar procesos acabados mientras otros siguen en marcha debido a que son cálculos de mayor envergadura (mallas estáticas más grandes) para los que se ha dedicado un solo core.

No sé en que medida la virtualización de máquinas recorta las prestaciones de unos Xeon de por sí anticuados, sin instalar un Windows Server que me permitiera ejecutar procesos distribuidos en 4 procesadores físicos no puedo más que especular, pero no voy a perder el tiempo, siempre tengo mucho lío y fechas de entrega muy cortas.

Lo que sí es cierto es que en el mercado abundan los servidores «enterprise» de tipo enrackable de características interesantes a unos precios muy contenidos, como este por ejemplo: HP Proliant DL580 G7 Barebone System 4x ten core e7-8867l/64gb memory / 2x 300gb 10k / rails / 4x psu

Este figura es un especialista, trabaja en un Data Center y sabe la tira, para quien quiera ahondar en este mundo.

Intuyo que esta abundancia de servidores sea debido a que se está produciendo una tendencia a evitar tener centros de cálculo «in house», por su coste de mantenimiento, por seguridad, por su coste de renovación y por su consumo, dirigiendo la demanda de proceso de cálculo a soluciones en la nube como Amazon Web Services, donde cada cual se puede alquilar por horas las necesidades de cálculo que requiera e incluso ofrecen máquinas preconfiguradas para procesos específicos.

IBM, HP, etc también llevan tiempo ofreciendo estos servicios. Si por consumo eléctrico fuera podemos utilizar las migajas.

A día de hoy están apareciendo tentativas, experimentos, aventuras de las que he hablado en LinkedIn como Project Nile, porting de Vray a UE4, nVidia VXGI, Light Volume Propagation, etc, todas ellas en fase experimental, y algunas con clara tendencia a Iluminación Global en tiempo real, (Otoy Octane integrado en el futuro Unity 2017 mete presión) sin embargo pienso que siempre será requerido el «cocinado» de luz para agilizar experiencias en equipos de rango medio, bajo o móviles, es decir, el parque de dispositivos más grande al que habitualmente optaremos para el destino de nuestros productos AEC.