Renderizado con yafray en grid
Posted on April 5th, 2008 by Diego Mariño
Hace unos días Santiago capturó un video de una de las demos que hemos preparado: renderización de escenas con Yafray. La verdad es que la integración de yafray en nuestro middleware grid no fue en absoluto dolorosa (supongo que alguien del equipo dejará más datos en los comentarios). Ahí va:
Sirva como demostración de que tenemos una plataforma que funciona ;-) La release será para antes de verano. Esta mañana hemos tenido una intensa reunión con nuestro abogado y ya tenemos atados casi todos los flecos. Falta solicitar unas patentes y desarrollar una infraestructura para la comunidad.
Desde este momento, si buscáis “vaporware” en cualquier diccionario, únicamente encontraréis screenshots del Duke Nukem Forever :-P
Me encanta.
En el curro me dicen que soy un “pesado” con el Grid, porque me paso el día quejándome de que tengamos 200 máquinas potentísimas encendidas, pero casi sin utilizar. Parece mentira que usemos el marenostrum pero nadie haya montado aún un grid o un sistema de colas en las workstations
Tal como lo adelantas, no fue nada dolorosa. En el caso de esta demo utilizamos un servicio programado en Java para repartir las tareas y unir los resultados.
El usuario que programa estos servicios poco debe preocuparse por los detalles de la implementación del grid, que era uno de nuestros objetivos.
Ya estamos trabajando en unas pruebas con Blender para componer animaciones complejas aprovechando la potencia de nuestra plataforma.
¡Saludos!
#Topopardo
Es que la herramienta mágica que facilita eso, no ha salido a la luz. Entiéndelos ;-) Creo que en gridear yafray (ojo, sin optimizacion) se han utilizado 0.075 hombres/mes
#Santiago
Lo de blender (con la comunidad que hay detrás) puede triunfar como la coca-cola :-D
Hola, interesante lo del servicio dispatcher… peeero…. como empaquetais el codigo ejecutable en los nodos para su ejecucion?, es decir, proporcionais paquete de datos mas paquete ejecutable o de alguna manera simplemente los datos+codigo ejecutable en alguna clase de maquina virtual?
#manolo
El recurso de máquina virtual no lo tenemos finalizado todavía.
Igual viene algún “techie” a matarme por simplificar/errar la descripción, pero básicamente definimos e instalamos el recurso “yafray” en cada máquina, y el servidor envía/recibe/junta los datos.
Decía lo de sin optimización, porque para una escena de yafray no tiene sentido cargar capa de agentes de IA. Dado que en este caso el cuello de botella es la CPU, sería más eficiente dividir la tarea en un número mayor de bloques (en vez de los 16 del ejemplo).
Ale, Diego me jodió el post de la semana :)
A ver, a la pregunta de Manolo. Si un nodo tiene capacidad de ejecutar yafray de forma natural en local, queda automáticamente virtualizado usando nuestro middleware.
Luego es questión que cualquier usuario coja el *.XML que quiera renderizar, se lo pase a todas las máquinas y de instrucciones de que trozo renderiza cada máquina, para ello el servicio yafray, usando nuestra api, y hablando ahora en pseudocódigo y sin dar detalles de procesos internos que hace nuestra plataforma y por lo tanto el usuario no hace falta que conozca, el servicio hace eso:
1º Busca todos los nodos libres o que pueden ejecutar Yafray.
2º A cada uno de los nodos le manda el XML
3º A medida que cada nodo vaya acabando recógeme la imagen generada y ves juntandomelo en un único archivo.
Y ya está, con nuestra API son 10 lineas. La plataforma ya se encarga de protejer el servicio frente a fallos, optimizar la comunicación, etc.
#Diego, #xfernandez
Ya veo, pero esperaba algo mas elaborado donde el planificador es capaz de proveer implementaciones del servicio yafray (u otro cualquiera definido tanto en forma, interfaz, como en fondo, codigo ejecutable) a los nodos para que sean capaces de aceptar paquetes de trabajo…
#manolo
Mucho esperas de este pseudohelloworld ;-)
Ya dije más arriba que no había optimización de ningún tipo. Y para este caso concreto (una única escena) además sería contraproducente.
En todo caso, si lo que preguntas es: ¿vuestra plataforma es capaz de proveer implementaciones de un servicio on-demand si un middleware lo soporta? La respuesta es sí :-)
Quizás simplifiqué demasiado…
No acabo de entender muy bien a que te refieres, quizás con un ejemplo me lo aclares… Pero precisamente, la parte “transparente” al programador.
Tu decides que necesitas en cada nodo y si lo tiene en local lo utiliza, sinó, mediante el servicio puedes definirle que tiene que desplegar en el nodo (Si es por aquí donde vas).
Y ahora te digo yafray, pero lo mismo con ffmpeg para transcodificar video, con un “locate” en el bash o lo que te venga en ganas.
En definitiva tu te lo guisas tal y como quieras. Si a lo que te refieres es poder desplegar yafrays por los nodos grid, también se puede hacer sin problema. Tu buscas nodos que tengan yafray en la infraestructura, si no los encuentra, puede lanzar un servicio para enviarle e instalar las librerias necesarias. Además, como la API se ha montado en formato Workflow, tu puedes hacer que vaya ejecutando trabajos en máquinas mientras por ejemplo va creando nuevas instancias de yafray.
Te animo a 2 cosas: 1º Lánzame un ejemplo para saber exactamente cual es tu inquietud. 2º Mándame un email (xfernandez-thinkingrid-com) y lo hablamos ;)
Un saludo
#Diego, #xfernandez
Gracias por el interes!. Imaginemos pues. Tengo una aplicacion de calculo intensivo, quiero aprovechar los recursos (siempre infrautilizados) de mi empresa para acelerar estos calculos teniendo en cuenta que vivo en un ambiente heterogeneo de trabajo, Windows, Linux, Mac, y dispositivos embebidos.
Si utilizo el framework de think in grid, entiendo que solo tendre que definir una unica vez el modulo que realiza el procesamiento, le pasare tanto modulo como paquetes de datos al middleware y el se encarga de ponerse en contacto con sus nodos para configurar un entorno de ejecucion para cada unidad de trabajo. Es asi?, de manera simplificada… ;)
Amplio lo de arriba, lo comentado de fabricar un modulo de proceso y ejecutar en nodos, encaja con la filosofia java “Compile once, run everywhere”, pero no se que estrategia teneis respecto a otros sistemas operativos y/o frameworks… Una solucion viable seria que los nodos del middleware fuesen entornos de ejecucion y planificaciones de maquinas virtuales conteniendo codigo ejecutable…
Perdón por el retraso manolo, pero es que intento leer lo mínimo el blog de Diego :).
A ver, te comento:
– Think in grid y máquinas virtuales… tendrás noticias nuestras al respecto ;). Pero solo comentarte que está en nuestra cartera y estamos trabajando en el laboratorio con ello. Seguirá nuestra filosofía de “light middleware”.
– Compile once, run wverywere. Lógicamente en entornos virtuales solucionas el problema. Pero como no tiene porqué haber una máquina virtual por debajo… nuestra filosofía de “plugin” debe permitir a nivel de programación de “servicios grid” que no debas preocuparte por el típo de nodo que utilizas para hacer la ejecución. En definitiva, el plugin = virtualización de recurso + sistema Operativo o Entorno de ejecución.
Un saludo
PD: Quería saber más de ti porque me gusta encontrar gente que le mole el tema grid… Pero aún espero tu correo ;) Me imagino que la web de globus no es tu blog habitual ;) jeje.