Link alla notizia: http://news.hwupgrade.it/11773.html

Adobe sta sviluppando un update per il proprio software After Effects, tale aggiornamento consentirà di sfruttare le teniche di grid-computing

Click sul link per visualizzare la notizia.

Strano, credevo che Premiere (addirittura) ce lo avesse già e che quindi After effects, ben più putente, fosse già dotato di tale caratteristica. COn After Effects Pro ci hanno fatto le esplosioni particellari di Indipendance Day

pensavo di si ....

nessuno fa il rendering con piu' pc con adobe after effcts 6 bundle ?

Se si come si fa ?

Invoco il supremo spirito della Sacra Informatica –Oh! Master C=ommodore!- …Assisti le nostre pene e Assolvere le nostre preghiere.

…Che sia la volta buona che rilasciano anche versioni per Linux?
..visto che il calcolo distribuito è una capacità implementata ormai da + di un decennio! ..a livello di kernel.

Mi sa che la realtà sarà ben + amara…. :
Tanti PC, ognuno col suo SistemoneMonolitico-spreca-risorse (Win o Mac), su cui giace copia completa e completamente-licenziata del sopra citato software.

Mi accontenterei se rendessero disponibile “il solo client” per i singoli “nodi” della render-farm… …ma qui lo dico e qui mi rassegno.
-Neppure con 3D Studio Max esiste questa possibilità- ..supporta il rendering distribuito (anche se in modo stupido: un frame completo per nodo…e se dovessi renderizzare un solo frame gigantesco? –come al solito mi attacco ..se uso Win..-)
Come dicevo, anche la Deescret ti licenzia una piattaforma completa anche se ti serve per far andare solo un nodo di calcolo. ..per fortuna esistono valide soluzioni (pluginS e client) di terze parti …anche Open!
Speriamo che alla Adobe si rendano conto delle reali necessità di chi sfrutterebbe in modo concreto queste BELLE-COSINE.

…anche perché, soprattutto per il fotoritocco, la soluzione è già pronta: The Gimp!
Ottimo prodotto free che lavora egregiamente! ..e per di più carica la stragrande maggioranza dei filtri e plugins fatte per Photoshop. …e che volendo ricompilarlo sfrutta in modo magistrale le capacità (su linux e unix) di distribuire i compitini a una renderfarm ..o ad un cluster ..o IN un cluster!

Avete idea cosa vuol dire poter sfoltire su 5 o 10 nodi un pesante passaggio di filtraggio su una immagine da 250Mb?
Beh… significa VOLARE! ..soprattutto se i PC in questione sono lì solo per quello, e non gli si fa pesare (e pure parecchio) il compito di reggere un’intero O.S. per l’anima del CaxxO.
…poi pensare al risparmio ($ € £) nel demandare il lavoro a Nodi (PC) senza dischi o lettori o Sistemi e software proprietari!!!

-comcludendo : sia mai che vendano anche il solo client? ..e magari pure per Linux…

Ciao. Daniele.

Finalmente! Era ora!
Una soluzione che permette di usare tutte le risorse è sempre la benvenuta. Spero solo che il supporto flash (grafico non di programmazione) di imageready a questo punto venga completato con la prox versione (o magari con un aggiornamento).

Per danidak: hai provato a caricare su gimp (sia sotto win che sotto linux) una immagine della Nasa, tipo da 400mb (jpeg o tiff compressa...)???
Solo Photoshop ce la fa.
Inoltre Gimp ha una disposizione delle palette caotica perchè non è stato dotato di una propria finestra, e si vedono le icone del desktop sotto, e ciò per molti e fuorviante (potresti tranquillamente per sbaglio lanciare un programma...).
Ah, Gimp va spesso in crash...

Per quel che riguarda il porting delle soluzioni Adobe su Linux sono d'accordo con te: speriamo lo facciano al più presto!

Ma 6 sicuro di aver usato il Gimp e non il Paint?
Guarda che se lo usi sotto Linux non ti costa proprio nulla dedicargli un SUO esclusivo desktop! (e pure sotto Win non è difficile), poi se intendi caricare immaginette da 400Mb vedi di dotarti di più RAM. ...a me non si inchioda MAI! ..e arrivo a fargli swappare anche 4-6Gb di dati!
...certo se mi dici che i prodotti Photoshop sono più ottimizzati per ambiente Win del GIMP..beh..è vero!
Ma comunque il rapporto prestazioni/costo non regge proprio il confronto!
...questa sparata del GRID-COMPUTING secondo me è solo una rivendita di abiti usati, chiunque abbia mai provato una configurazione BeoWulf o Mosix "con il gimp, con il COREL9 o perfino con lo Shake" vedrà di cosa è capace un sistema distribuito.
Il resto è solo propaganda publicitaria.
Sono invece d'accordo se mi dite che le interfaccia Adobe sono più evolute... tanto io preferisco i prodotti Corel!
N.B. - Il Gimp non mi ha mai (MAI) krasciato -
Sarà anche solo fortuna..? ..ma è così.
Il Photoshop invece Sì!
Poi è da vedere se sia solo tutta colpa di Win...(ma è da vedere..).

Scusa, ma cosa offre il kernel di Linux per supportare attivamente il calcolo distribuito?
Secondo me ben poco, altrimenti buona parte delle applicazioni intensive lo utilizzerebbero nativamente e semplicemente.
In realtà già sviluppare applicazioni multi-threaded, in modo da suddividere parte del carico computazionale su eventuali altre CPU, richiede già uno sforzo non indifferente, perché si deve pensare di sviluppare il codice diversamente rispetto ai canoni tradizionali.
Se pensiamo al software distribuito, i problemi diventano anche maggiori.
Io sviluppo applicazioni che fanno parte del calcolo distribuito su varie macchine, e utilizzo TPC/IP o UDP/IP quale protocolli per lo scambio d'informazioni fra i nodi, con un minimo di routine che provvedono al locking delle informazioni critiche e altre per lo scambio d'informazioni, e francamente questo mi basta per realizzare questi progetti.
Non vedo cosa potrebbe offrire in più un s.o. per gestire la distribuzione del lavoro su più macchine collegate in rete: comunque l'applicazione deve prevedere questo tipo di elaborazioni, altrimenti non c'è s.o. "distribuito" che tenga...

Allora, …vantaggi?...
Credo di non rubare tempo inutilmente a nessuno indicando queste letture.

http://openmosix.sourceforge.net/
http://www.beowulf.org
http://www.lam-mpi.org
http://www.ram.org/computing/linux/linux_cluster.html

…tanto per citarne alcune delle più famose..e dirette.

I vantaggi sono PALESI (dopo una veloce lettura delle fonti indicate lo saranno sicuramente).
In pratica è sufficiente programmare in modo “decente” strutture threadDABILI e il resto lo farà il sistema!!! ..è il kernel (ovviamente patchiato a dovere) a fare tutto il lavoro di distribuzione/migrazione dei processi!
L’applicativo (anche qualunque applicativo si possa trovare in distribuzione!) potrà anche non essere assolutamente ottimizzato per “forkare” ad ogni opportunità, ma addirittura potrebbe esse del tutto mono-thread! ..il sistema (in questo caso sfigato.. ma non remoto) demanderà “in piena autonomia” lo svolgimento del suddetto ad un solo nodo “dedicandoglielo”, così da non appesantire per nulla lo svolgimento degli altri processi –compresi quelli del sys. stesso- ..che ingombreranno altri nodi!
-…soprattutto ciò lascia la workstation sempre libera e responsiva!!!-
Esiste poi la possibilità (abbastanza semplice) di poter ricompilare con compilatori-dedicati (e open!) che ottimizzeranno per l’esecuzione distribuita.

In pratica l’orgasmo sta nel dover installare un solo sistema, a cui poi si “iscrivono i nodi” (sui quali non c’è nulla! ..se volete manco l’hdd!) …
..una volta installati gli applicativi (come si farebbe su un normalissimo sistema liunx!)..
….e si utilizza (da una sessione aperta sul nodo del Cluster –che è un PC virtuale-) come si farebbe da un normale PC…
COME PER MAGIA CI SI ACCORGERà CHE TUTTO “VOLA”!
…ovviamente si accuseranno le latenze dovute al collo di bottiglia della rete attraverso cui chiacchierano i nodi!
Ma PER L’UTENTE è TUTTO TRASPARETE!

Le preoccupazioni che citava Cidimauro sono quindi vane! …per fortuna! ..altrimenti, il tutto, sarebbe veramente inapplicabile! (si dovrebbe riscrivere ogni applicativo…e tutto il sistema!)

Purtroppo, per questo genere di applicazioni (sistema-distribuito e non greed-comuting), la situazione è veramente tragica in casa M$!!!
..in quanto le patch al sistema “non esistono” e mai esisteranno ..perché non è nelle Loro convenienze produrre strumenti che non prevedano di piazzare sistemi in rapporto 1 a 1 ai PC installati! (leggi licenze).
La cosa è comprensibile, ma grazie a Dio (per chi ci crede) esiste un’alternativa/scappatoia: -LINUX-

UN PARADOSSO:
Se fate girare un applicativo per Windows (o addirittura tutto il sistema) su un cluster-linux ..pure questi godranno dell’esecuzione distribuita! ..ovvio che è da verificare l’efficienza…ma è fattibile! (e Win non se ne renderebbe neppure conto!).

Nota:
Saranno almeno 3 o 4 anni che i moduli MPI e PVM vengono regolarmente inclusi nei kernel pre-compliati per la distribuzione di massa. …è di quest’ anno l’aggiunta la “quasi puntuale” del fantastico “OpenMOSIX”.

Saluti, Daniele.

Di quei link quello di OpenMOSIX è molto interessante. In effetti l'idea di calcolo distribuito implementato in siffatta maniera è certamente elegante e funzionale: realizzare applicazioni distribuite è molto semplice.
Come hai detto, bisogna sviluppare applicazioni multithreaded, è questo è comunque un prerequisito per chi vuol "parallelizzare" il calcolo, sia esso in locale che su più macchine.
Unico difetto, ma è questo è ovvio, è che c'è un overhead e la resa complessiva del sistema non è paragonabile a quella di una soluzione custom. Ma questo è ovvio, come ho già detto. Le applicazioni che scrivo infatti, hanno un overhead minimo e una resa massima, proprio per questo motivo.
E' chiaro che Windows non può essere pensato per realizzare cluster-computing paragonabile a OpenMOSIX, quanto a semplicità e duttilità: bisognerebbe riadattare il s.o. in accordo, ma non essendoci i sorgenti (insomma :D) ed essendo MS l'unica a portelo fare, sarà difficile vedere realizzata qualcosa di simile.
Ciò non toglie che sia possibile comunque implementare l'elaborazione distribuita. Tra l'altro non è che neppure difficile da realizzare, anche se certamente richiede un po' di lavoro in più (alcune routine di sincronizzazione/locking e un protocollo di comunicazione). Niente di particolamente complicato, dal mio punto di vista.