[opensuse-es] [OT] Como construir tu propia granja de renderizado
Saludos Algo peculiar en Ars Technica, Como construir una granja de renderizado. La idea es armar un equipo que se encargaría del trabajo del renderizado mientras el equipo normal de escritorio puede ser utilizado para otras actividades. La descripción es simple mas hay ciertos términos y acciones más familiares para el pingüino melenudo y otras personas familiarizadas en equipos de alto rendimiento (redes rápidas, eficiencia en procesamiento). Mencionan varias opciones, tanto para Hardware como Software... para el OS usan Linux (página 3). La nota está en ingles. Si bien en la lista no hay gente familiarizada con esta labor (diseño en 3D) o se gane el pan de cada día con un trabajo similar, es una interesante lectura. http://arstechnica.com/information-technology/2014/05/how-to-network-lots-of... Y nada más, suerte por allá. -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 13 de mayo de 2014, 10:50, Carlos Ayala
Saludos
Algo peculiar en Ars Technica, Como construir una granja de renderizado. La idea es armar un equipo que se encargaría del trabajo del renderizado mientras el equipo normal de escritorio puede ser utilizado para otras actividades. La descripción es simple mas hay ciertos términos y acciones más familiares para el pingüino melenudo y otras personas familiarizadas en equipos de alto rendimiento (redes rápidas, eficiencia en procesamiento). Mencionan varias opciones, tanto para Hardware como Software... para el OS usan Linux (página 3).
La nota está en ingles. Si bien en la lista no hay gente familiarizada con esta labor (diseño en 3D) o se gane el pan de cada día con un trabajo similar, es una interesante lectura.
http://arstechnica.com/information-technology/2014/05/how-to-network-lots-of...
Parece bastante elitista (aparte de burro) el que escribió el artículo, porque empieza con el hardware mas caro y elitista: In my recent Mac Pro review, I mentioned that a workstation computer (whether from Apple...... Mac setup CPU If you’re going to get a desktop CPU, opt at least for the i7 4930K CPU. Por lo visto, para este sujeto, solamente existe intel.... las pantallas donde dice: "host MacPro" CREO QUE SOLAMENTE UN ENFERMO, QUE NO SABE EN QUE MALGASTAR EL DINERO, ARMARIA ALGO SOBRE ESA BASE! En este otro artículo, por ejemplo, aclara: http://www.tomshardware.com/reviews/render-farm-node,2340.html For the purposes of this article, assume that we're talking about Intel-based render nodes, although they could just as easily center on AMD CPUs. Años atras George Lucas en su granja de renderizado, a la noche le acoplaban las estaciones de trabajo HP basadas en los micros AMD Opteron: http://news.bbc.co.uk/2/hi/technology/6584075.stm Pero, los tiempos, van cambiando: http://www.datacenterknowledge.com/archives/2011/02/28/hollywoods-render-far... Años atrás, Autodesk, proveia una suite completa de cine para Linux (lamentablemente, era solo para RedHat), donde proveía del software Backburner que permite la creación y gestión de render farms. Éstas son un grupo grande de todas las máquinas centradas en las mismas tareas de renderización para hacer frente a archivos de gran tamaño en una fracción del tiempo. Backburner asigna automáticamente los datos a cada máquina de acuerdo a la demanda, al igual que la descarga de las piezas de un archivo torrent de varios usuarios simultáneamente. En el nivel básico, Backburner maneja las tareas de procesamiento y compilación ejecutadas desde el interior de uno o más de los productos compatibles con Autodesk. Los bloques de datos de las aplicaciones individuales se envían a muchos nodos de render en las mismas máquinas o diferentes a la vez. Esto permite tiempos más rápidos de renderizado y libera espacio en el procesador para otras tareas. La salida podría venir de las aportaciones de múltiples aplicaciones simultáneamente, como video renderizado a través de Flame y luego enviado a Cleaner para la masterización y codificación. La mayoría de las suites de software de Autodesk utilizan Backburner de alguna manera. Las aplicaciones compatibles con ella son Smoke, Burn, Inferno, Flame, Flare, Flint, Maya, Lustre, 3DStudioMax, Cleaner, WiretapCentral y Backdraft Conform. Debido a que muchos de estos programas trabajan en conjunto con otros, Backburner puede ejecutar tareas de varias aplicaciones al mismo tiempo. Un ejemplo de una granja de renderizado de alquiler en España, que ofrece: Potencia de cálculo de EGM 960 cores AMD Opteron Magny Course 160 cores Intel Xeon serie Westmere 2240 Ghz de procesamiento 1000 GB de memoria RAM 50 TeraByte de almacenamiento RAID http://renderfarm.egm.es/es-es/renderfarm/renderfarm.aspx Otros artículos muy interesantes: http://www.likelyanswer.com/18703415/Build-My-Render-Machine-hd-Video,-3d http://www.tomshardware.com/answers/id-1852934/amd-8320-small-render-farm.ht... -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola :)
2014-05-14 3:03 GMT+02:00 Pinguino Patagonico
El día 13 de mayo de 2014, 10:50, Carlos Ayala
escribió: Saludos
Algo peculiar en Ars Technica, Como construir una granja de renderizado. La idea es armar un equipo que se encargaría del trabajo del renderizado mientras el equipo normal de escritorio puede ser utilizado para otras actividades. La descripción es simple mas hay ciertos términos y acciones más familiares para el pingüino melenudo y otras personas familiarizadas en equipos de alto rendimiento (redes rápidas, eficiencia en procesamiento). Mencionan varias opciones, tanto para Hardware como Software... para el OS usan Linux (página 3).
La nota está en ingles. Si bien en la lista no hay gente familiarizada con esta labor (diseño en 3D) o se gane el pan de cada día con un trabajo similar, es una interesante lectura.
http://arstechnica.com/information-technology/2014/05/how-to-network-lots-of...
Interesante :) Hay una cosa con la que no estoy de acuerdo, dice: "For my network, I’m not using link aggregation since that requires special routers and switches." Esto no es cierto, en Linux puedes hacer channel bonding aunque el switch no lo soporte (o no quieras configurar el switch). En la parte de Linux tampoco estoy de acuerdo con: "A tendency to break with updates." Algunas cosas sí y otras no ... y con otros OS ocurre lo mismo o, incluso, no hay updates porque el hardware es obsoleto (cuando en realidad no lo es tanto). [...]
Pero, los tiempos, van cambiando: http://www.datacenterknowledge.com/archives/2011/02/28/hollywoods-render-far...
Por mucho que digan ... el cloud está bien si puedes mandar una pila de discos duros. Una película ocupa muchísimo espacio y subirlo por Inet es bastante complicado. Eso lo primero. Lo segundo es ver si el servicio de Cloud tienen todo lo que necesitas y el precio: algunas incluyen el precio de las licencias, otras no, ... No es que esté en contra, sólo digo que hay que tener cuidado y, MHO, dudo que "las grandes" utilicen este tipo de servicios *de verdad* por el volumen de datos que manejan y la velocidad de desarrollo que ellos mismo tienen (sus plicaciones están muy^H^H^H excesivamente personalizadas). De hecho, en el link pone: "[...] proof of concept demonstration [...]"
Años atrás, Autodesk, proveia una suite completa de cine para Linux (lamentablemente, era solo para RedHat), donde proveía del software Backburner que permite la creación y gestión de render farms. Éstas
[...] Backburner sigue existiendo para Linux, el problema es que 3DS Max no ... pero sí Maya. http://knowledge.autodesk.com/support/maya/learn-explore/caas/mne-help/globa... Concretamente, hay un apartado: "Setting up Backburner for use with Maya on Linux" Puedes descargarlo desde: http://knowledge.autodesk.com/support/maya/downloads/caas/downloads/content/... AFAIK, backburner es gratuito. Hay mucho software para montar una granja de render en Linux, sobre todo SW cerrado. Alternativas FLOSS - DrQueue - DrQueueIPython - CGRU Pero, lo importante no es sólo el gestor de colas (o como lo quieras llamar), lo importante es: - si el motor de render corre en Linux - si el gestor de colas soporta el motor de render en Linux Por ejemplo, puedes estar usando 3DS Max en Windows y usar Arnold como motor de render (que sí corre en Linux). Yo he trabajado con Dr Queue y Blender y es sencillísmo de montar. El proyecto (AFAIK) está parado y han migrado a DrQueueIPython (en mi TODO list). Probé CGRU, pero me pareció excesivamente complejo de configurar para lo que yo quería ... así que ha bajado de prioridad en el TODO list :( Eso sí, CGRU es muuuuuucho más potente (AFAIK ... me puedo equivocar). [...]
Un ejemplo de una granja de renderizado de alquiler en España, que ofrece:
[...] AFAIK, la más famosa en España es SUMMUS, aunque hay más. He estado en su CPD y está realmente muy bien montado. Respecto a usar las estaciones de trabajo como nodos de render, mi recomendación es que se use el mismo procesador (por lo menos, lo más parecido). Esto es bastante importante en varios mercados (financiero me viene a la mente) ya que puede haber variaciones en la coma flotante o bugs por lo que los cálculos de uno y otro varían. En el mundo de render "no pasa nada" ya que si el destello de luz cambia un pelín de un fotograma a otro lo vuelves a renderizar ... pero en entonos financieros ... ;) Lo de que "no pasa nada" es un decir, la gente que yo conozco te detecta el más mínimo cambio (y son muy perfeccionistas) y vuelven a repetir mucho render. En algunos casos es poco tiempo, pero en las pelis de hoy en día (4K, por ejemplo) ... los tiempos de render por frame se pueden disparar. La red puede ser otro cuello de botella. En lo que monté con V-Ray hace un año, la red Gigabit Ethernet era un cuello de botella enorme ... y eso que eran sólo 6 nodos !!! Una recomendación: si la granja mezcla Windows y Linux (lo más normal: WS con Windows y granja con Linux), tened cuidado con las rutas porque suele dar problemas. De hecho la documentación de los gestores de colas que he visto recomiendan todos lo mismo: hay que tener cuidado con las rutas en entornos mixtos ... Rafa -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2014-05-14 20:39, Rafa Griman wrote:
Por mucho que digan ... el cloud está bien si puedes mandar una pila de discos duros. Una película ocupa muchísimo espacio y subirlo por Inet es bastante complicado. Eso lo primero. Lo segundo es ver si el servicio de Cloud tienen todo lo que necesitas y el precio: algunas incluyen el precio de las licencias, otras no, ..
En un artículo que leí hace poco del IEEE spectrum comentaban que un máster de película digital ocupa varios petabytes, con lo que sólo copiarlo de disco a disco "local" tarda lo suyo (y no es un único disco, claro). Las películas se guardan por triplicado, y actualmente se estima que hay que cambiar de disco a los cinco años - o sea, igual que con los papiros, que había que transcribirlos periódicamente porque se deshacían. En cambio las películas de triacetato está comprobado que se pueden guardar sin problemas grandes unos 100 años, con sólo tenerlas en un almacén adecuado sin tocarlas mucho en todo ese tiempo. Así que los grandes estudios guardan esas grandes producciones digitales en cinta fotográfica de toda la vida, en triacetato. Con una diferencia: son cintas en blanco y negro, y usan una cinta para cada color, o sea, tres. Como guardan tres copias por separado, hacen un total de nueve cintas - y os puedo asegurar que pesan lo suyo, porque he trabajado de operador de cabina y sé lo que pesan. Y sale mucho más barato, entre diez y cien veces, quizás mil, que guardar las copias digitales un tiempo similar. Hay que fastidiarse... - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlNz1pIACgkQja8UbcUWM1xWJwD/RJ29xD2XbWcclwKNzvxwM/OK zTRjNMSDkzJg4KiiXCIA/31L9FoOpTjn1u8yrfIIyIsCF5iJIcdQZLz9foKkQw4Y =T7Ey -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 14 de mayo de 2014, 15:39, Rafa Griman
Hola :)
2014-05-14 3:03 GMT+02:00 Pinguino Patagonico
: El día 13 de mayo de 2014, 10:50, Carlos Ayala
escribió: Saludos
Algo peculiar en Ars Technica, Como construir una granja de renderizado. La idea es armar un equipo que se encargaría del trabajo del renderizado mientras el equipo normal de escritorio puede ser utilizado para otras actividades. La descripción es simple mas hay ciertos términos y acciones más familiares para el pingüino melenudo y otras personas familiarizadas en equipos de alto rendimiento (redes rápidas, eficiencia en procesamiento). Mencionan varias opciones, tanto para Hardware como Software... para el OS usan Linux (página 3).
La nota está en ingles. Si bien en la lista no hay gente familiarizada con esta labor (diseño en 3D) o se gane el pan de cada día con un trabajo similar, es una interesante lectura.
http://arstechnica.com/information-technology/2014/05/how-to-network-lots-of...
Interesante :) Hay una cosa con la que no estoy de acuerdo, dice:
"For my network, I’m not using link aggregation since that requires special routers and switches."
Esto no es cierto, en Linux puedes hacer channel bonding aunque el switch no lo soporte (o no quieras configurar el switch).
Pero el imbécil, no usa Linux, sino Macshit
En la parte de Linux tampoco estoy de acuerdo con:
"A tendency to break with updates."
Algunas cosas sí y otras no ... y con otros OS ocurre lo mismo o, incluso, no hay updates porque el hardware es obsoleto (cuando en realidad no lo es tanto).
[...]
Pero, los tiempos, van cambiando: http://www.datacenterknowledge.com/archives/2011/02/28/hollywoods-render-far...
Por mucho que digan ... el cloud está bien si puedes mandar una pila de discos duros. Una película ocupa muchísimo espacio y subirlo por Inet es bastante complicado. Eso lo primero. Lo segundo es ver si el servicio de Cloud tienen todo lo que necesitas y el precio: algunas incluyen el precio de las licencias, otras no, ...
No es que esté en contra, sólo digo que hay que tener cuidado y, MHO, dudo que "las grandes" utilicen este tipo de servicios *de verdad* por el volumen de datos que manejan y la velocidad de desarrollo que ellos mismo tienen (sus plicaciones están muy^H^H^H excesivamente personalizadas). De hecho, en el link pone: "[...] proof of concept demonstration [...]"
Años atrás, Autodesk, proveia una suite completa de cine para Linux (lamentablemente, era solo para RedHat), donde proveía del software Backburner que permite la creación y gestión de render farms. Éstas
[...]
Backburner sigue existiendo para Linux, el problema es que 3DS Max no ... pero sí Maya.
http://knowledge.autodesk.com/support/maya/learn-explore/caas/mne-help/globa...
Concretamente, hay un apartado: "Setting up Backburner for use with Maya on Linux"
Puedes descargarlo desde: http://knowledge.autodesk.com/support/maya/downloads/caas/downloads/content/...
AFAIK, backburner es gratuito.
Hay mucho software para montar una granja de render en Linux, sobre todo SW cerrado. Alternativas FLOSS - DrQueue - DrQueueIPython - CGRU
Pero, lo importante no es sólo el gestor de colas (o como lo quieras llamar), lo importante es: - si el motor de render corre en Linux - si el gestor de colas soporta el motor de render en Linux
Por ejemplo, puedes estar usando 3DS Max en Windows y usar Arnold como motor de render (que sí corre en Linux).
Yo he trabajado con Dr Queue y Blender y es sencillísmo de montar. El proyecto (AFAIK) está parado y han migrado a DrQueueIPython (en mi TODO list). Probé CGRU, pero me pareció excesivamente complejo de configurar para lo que yo quería ... así que ha bajado de prioridad en el TODO list :( Eso sí, CGRU es muuuuuucho más potente (AFAIK ... me puedo equivocar).
[...]
Un ejemplo de una granja de renderizado de alquiler en España, que ofrece:
[...]
AFAIK, la más famosa en España es SUMMUS, aunque hay más. He estado en su CPD y está realmente muy bien montado.
Respecto a usar las estaciones de trabajo como nodos de render, mi recomendación es que se use el mismo procesador (por lo menos, lo más parecido).
Sin embargo, en esa granja usan: 960 cores AMD Opteron Magny Course 160 cores Intel Xeon serie Westmere Con respecto al duelo intel - AMD: http://ideaconsultores.blogspot.com.ar/2013/09/intel-i7-vs-amd-a10-6800k-bla... Es cierto que no están comparando el APU mas moderno y potente de AMD, que es el Kavery (A13). Ponen el siguiente video comparativo de renderizado: https://www.youtube.com/watch?v=VNHBVS8tKSw Y despues los 2 trabajando juntos: https://www.youtube.com/watch?v=EeSd2xYtYbM Pero no usan Linux... Realmente, de mucho no sirve... Otro punto importante, que en vez de hacer el renderizado mediante CPU, se puede hacer por GPU, o combinado... -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (4)
-
Carlos Ayala
-
Carlos E. R.
-
Pinguino Patagonico
-
Rafa Griman