PDA

Visualizza Versione Completa : Screamernet: un frame con più nodi



Orsobubu
12-11-09, 11:47
Buongiorno a tutti,
solo una breve descrizione della configurazione e poi la domandona:
-pc1: dual xeon quad core con installato lw, configurato come nodo 1
-pc2: singolo xeon quad core su win64 che funge da nodo 2
-screamernet configurato (apparentemente) in modo corretto, su disco di rete visto da entrambe le macchine etc

Quando inizializzo screamernet i nodi vengono visti, la scena renderizzata e salvata, solo che nel calcolo viene sfruttato un solo nodo.
Allego un'immagine di riferimento: scena 1, frame 0 to 0, per cui un frame.
Come potete notare la scena viene correttamente caricata e calcolata sul nodo 1, mentre sul nodo 2 rimane NONE, se carico invece una seconda scena nella coda viene renderizzata utilizzato il nodo 2.

Domanda: il render distribuito non permette il calcolo sfruttando tutte le macchine su una sola scena con un solo frame? Ditemi che non è così, e che è solo un problema di settaggio, vi prego :confused:

Wotan3d
12-11-09, 12:49
Mai saputo che si potessero suddividere i singoli frames su più computer, almeno in LW.
Però potrei scoprire ora una cosa mai saputa (e chissà quante ce ne sono che non conosco di lw).

Pertanto l'unica soluzione che ti posso proporre è creare due scene con un limited region: una scena con la metà destra (o sinistra, o sopra, o sotto) settata con il limited region, e l'altra scena con l'altra metà. Poi in fotoschioppo le appiccichi. Certo è che se non bilanci bene le due "metà" con il limited dando ad entrambe più o meno la medesima area occupata dagli oggetti, è possibile che un nodo finisca dopo 10 secondi e l'altro impieghi un'ora, dipende dalla tua immagine.

"Ocio" a fare questa cosa però! a volte (vedi motion blur) ci possono essere delle piccole differenze fra le due parti, succede persino quando si calcolano i segmenti. Per non parlare poi di un frame con il radiosity interpolato (dovresti prima calcolare la cache dentro LW e salvare le due scene con il riferimento a quella cache).

samalex
12-11-09, 13:57
Ciao a tutti,

Screamernet non può suddividere il calcolo di un singolo frame su più nodi, può solo suddividere il calcolo dei vari frames su più macchine (nodi) ma li calcola come immagini complete, spero di essermi spiegato bene :)
Per calcolare una singola immagine suddivisa su più macchine puoi provare Amleto, di cui esiste una versione di prova con alcune limitazioni.
Se cerchi nel forum se ne era già parlato tempo fa.
Spero di essere stato di aiuto.

A presto
Luciano

Orsobubu
12-11-09, 14:21
Intanto grazie per le risposte, mi stavo giusto informando proprio perchè qui dove lavoro c'è l'intenzione di prendere una serie di macchine dedicate per il rendering e facendo alcune prove mi è venuto il dubbio.
La soluzione di wotand3d mi pare macchinosa ma percorribile, oggi farò qualche prova.

Il problema comunque rimane in questione: l'ideale per me sarebbe di poter sfruttare la potenza di calcolo anche solo per le preview ad alta, la vedo come una cosa estremamente produttiva, considerando inoltre l'utilizzo costante della batteria di computer che altrimenti andrebbero attivati solo per i render finali. Stavo già facendo qualche ricerca su sw di terze parti, tipo butterfly net render, harpoon. Amleto ben venga ora ci do un occhio.
Altri software interessanti per il network rendering ne conoscete?

Bruscolì
12-11-09, 15:32
Già, lo screamer net non supporta lo split di un singolo frame.
Io ho utilizzato butter fly net render per il calcolo di un singolo frame con più computer.
Non so con gli altri, ma con BNR c'è il problema che se attivi la GI, devi per forza fare un primo rendering salvando la radiosity cache su disco e successivamente, condividendo il file della radiosity con i vari nodi, puoi far calcolare il rendering finale.
Se non salvi prima la radiosity cache, nell'immagine finale sono evidenti le varie strisce calcolate da nodi differenti ... cioè l'immagine è inutilizzabile.

Fulvio

Orsobubu
12-11-09, 17:41
Eccomi, un aggiornamento: sto provando amleto in versione trial.
Il setup è rapido ed indolore, roba da 5 minuti davvero.

Ho dovuto constatare mio malgrado che comunque il calcolo di un frame con più nodi purtroppo non sempre è effettivamente più veloce, o meglio, il calcolo viene semplicemente ripartito utilizzando il "metodo wotan3d", mi spiego meglio: ho usato 3 nodi
1 dual xeon quad core 2.5ghz
1 core duo quad core 2.7ghz
1 mono xeon quad core 2.13ghz

Amleto ripartisce il calcolo secondo un numero di Slice (porzioni di render), in questo caso ho impostato 3, come i nodi, per cui 1/3 1/3 1/3 di frame su ogni macchina, e monta l'immagine finale unendo i 3 pezzi calcolati da ogni nodo (è possibile scegliere una % di overlap per evitare che si veda il merge nei punti di contatto).
Tutto molto bello, la GI non va precalcolata e se la gestiscono i nodi, ma la soluzione presenta 2 grossi problemi di ottimizzazione:
1- i pc più veloci quando hanno finito si fermano e aspettano il più lento
2- anche con pc tutti uguali, se l'immagine da calcolare è disomogenea, e ad esempio 1/3 di immagine è più impegnativo da calcolare degli altri 2/3, i processori che finiscono si fermano (come sopra) e aspettano lasciando il calcolo al solo nodo rimanente.

Insomma, nell'uno e nell'altro caso c'è il rischio che il calcolo gravoso ricada su una sola macchina, non ho risolto molto mi sa...

Per chiudere, un paio numeri: il dual xeon da solo renderizza tutto in 3' e 10", utlizzando il render distribuito fa la sua parte in 1' e 8", si ferma e aspetta gli altri due finiscono rispettivamente in 3' e 5'. La porzione 3/3 tra l'altro è quella più impegnativa della scena, per questo il tempo non è proporzionale al resto.
Quello che cerco è un'architettura in grado di sfruttare il calcolo in modo lineare, tipo somma dei processori o carico distribuito in modo intelligente (magari esagero eh) perchè così ci sarà sempre qualche macchina che sta li a far niente: a parte il problema della GI, butterfly render come si comporta da questo punto di vista?

Bruscolì
12-11-09, 18:07
1- i pc più veloci quando hanno finito si fermano e aspettano il più lento
2- anche con pc tutti uguali, se l'immagine da calcolare è disomogenea, e ad esempio 1/3 di immagine è più impegnativo da calcolare degli altri 2/3, i processori che finiscono si fermano (come sopra) e aspettano lasciando il calcolo al solo nodo rimanente.


... aumenta il numero degli slice per ottimizzare ulteriormente il tempo !!

Fulvio

EDIT: BNR si comporta allo stesso modo, ma appunto come ti dicevo se aumenti il numero di tagli, ottimizzi ancora di più il tempo.

Wotan3d
12-11-09, 18:10
Mi sembra che in butterfly si possano dare il numero di slices, a scelta in modo orizzontale e verticale, pertanto più è alto il numero e più dovresti avere i computer sempre occupati.
(non ho mai provato, ma vedo che si può inserire il numero di slices... qualcuno può fare una prova? in questo momento io non posso testare il render).

Orsobubu
12-11-09, 18:13
Faccio una prova al volo vi aggiorno.

Orsobubu
13-11-09, 11:24
Dunque, ho provato 2 nodi, 10 slice: l'ultilizzo dei nodi è effettivamente più efficiente, ma la procedura rimane comunque più lunga dei 3 minuti del solo pc. Sono punto a capo. Appena i colleghi mi lasciano di nuovo smanettare provo con un render più impegnativo, probabilmente valutare su 3 minuti ha poco senso, che ne dite?

Bruscolì
13-11-09, 11:55
Be si, ti conviene provare con un rendering più impegnativo perchè il tempo necessario per caricare e avviare il rendering di uno slice per ogni singolo nodo, incide molto in un totale di 3 minuti.
Anche fossero 5 secondi a segmento, per 10 slice è quasi un minuto di tempo "morto".

Fulvio

Wotan3d
13-11-09, 11:58
Dunque, ho provato 2 nodi, 10 slice: l'ultilizzo dei nodi è effettivamente più efficiente, ma la procedura rimane comunque più lunga dei 3 minuti del solo pc. Sono punto a capo. Appena i colleghi mi lasciano di nuovo smanettare provo con un render più impegnativo, probabilmente valutare su 3 minuti ha poco senso, che ne dite?


10 slices secondo me sono molto pochi. Più il frame è frazionato e più sarà distribuito sui vari nodi. Tieni però conto di quanti pixel dai di overlap... più segmenti fai e più alta diventa la risoluzione calcolata. Prova magari a non dare overlap, in modo che effettivamente i segmenti calcolati siano esattamente la risoluzione finale... magari non ci sono differenze fra uno slice e l'altro (e normalmente non ce ne dovrebbero essere).

Wotan3d
13-11-09, 12:09
Be si, ti conviene provare con un rendering più impegnativo perchè il tempo necessario per caricare e avviare il rendering di uno slice per ogni singolo nodo, incide molto in un totale di 3 minuti.
Anche fossero 5 secondi a segmento, per 10 slice è quasi un minuto di tempo "morto".

Fulvio


Credo che la scena venga caricata solo la prima volta, poi al passaggio da uno slice all'altro il singolo nodo non la dovrebbe più ricaricare... almeno mi sembra che butterfly faccia così.

Bruscolì
13-11-09, 18:55
Credo che la scena venga caricata solo la prima volta, poi al passaggio da uno slice all'altro il singolo nodo non la dovrebbe più ricaricare... almeno mi sembra che butterfly faccia così.

... forse sbaglio ma ricordo il contrario. Avevo fatto proprio questi test con BNR ... ora ce l'ho disinstallato e non posso provare, comunque mi sembra di aver capito che sta facendo i test con amleto ?!?

Fulvio

Orsobubu
17-11-09, 16:07
Eccomi di nuovo, si sto facendo i test con Amleto, purtroppo in questi giorni non ho avuto tempo di testare in modo approfondito perchè ho le macchine occupate. Ad ogni modo, nell'ultimo test che ho fatto (circa 20 minuti di render) con 40 slice comincia ad avere senso.
Secondo me è comunque un meccanismo non sempre utile, diciamo che l'ideale sarebbe poter sfruttare qualunque processore a disposizione ma nel modo in cui viene fatto dal motore nativo di lw, magari invece che su slice sul singolo pixel, boh.
Comunque grazie a tutti, a breve farò altri test, se vi interessa vi terrò aggiornati, magari con una scena template per avere un riferimento sul guardagno di calcolo...