Houdini Karma XPU su una Cloud Render Farm: Guida Tecnica 2026

Introduzione

Karma XPU è il renderer su cui un numero crescente di studi Houdini si sta standardizzando, e con buone ragioni: è il renderer di produzione nativo di SideFX, vive nativamente all'interno di Solaris e USD, e la sua esecuzione ibrida CPU+GPU rende lo sviluppo del look quasi interattivo. Su una singola workstation è un piacere da usare. I problemi iniziano quando si porta una scena Karma XPU dalla propria workstation e si tenta di eseguire alcune centinaia di frame su una render farm.

Su scala di render farm, Karma XPU smette di comportarsi come una versione più veloce di Karma CPU e inizia a comportarsi come una bestia diversa. La VRAM diventa un limite rigido piuttosto che un suggerimento. Le simulazioni che funzionavano bene in modo interattivo non possono essere distribuite finché non vengono memorizzate nella cache. Il renderer può silenziosamente eseguire il fallback alla CPU su un frame pesante, lasciando incomprensibile il motivo per cui uno shot ha impiegato sei volte più tempo di quello accanto. Nessuno di questi è un bug — è l'architettura che si manifesta sotto carico.

Negli anni, Super Renders Farm ha eseguito il rendering distribuito per lavori Houdini, e Karma XPU è uno dei motori disponibili sulla nostra Houdini cloud render farm insieme a Redshift, Mantra, Arnold, V-Ray for Houdini e Octane. Questa guida è l'approfondimento tecnico: cos'è effettivamente Karma XPU, come differisce da Karma CPU e Mantra, cosa cambia quando lo si esegue headless su una render farm, come deve funzionare il caching delle simulazioni e come decidere tra Karma XPU e Redshift per un determinato shot. Se si preferisce invece una checklist passo-passo per la preparazione della scena, la nostra guida alla configurazione di Houdini copre quel terreno; questo articolo presuppone già familiarità con Solaris.

Perché Karma XPU è Più Difficile da Scalare di Quanto Sembri

La cosa fondamentale da capire su Karma XPU è che "XPU" non è un renderer — è una modalità di esecuzione. Karma è un unico delegato di rendering USD, e XPU è il percorso che distribuisce il lavoro ai core CPU e alla GPU NVIDIA contemporaneamente, con entrambi i dispositivi che contribuiscono campioni alla stessa immagine. Karma CPU è lo stesso delegato con la GPU disattivata. Questa progettazione è elegante su una workstation e scomoda su una render farm, per quattro motivi.

In primo luogo, il percorso GPU funziona su OptiX, il che significa che carica geometria, texture e strutture di accelerazione nella VRAM della GPU. Quando una scena si adatta alla VRAM, si ottiene la piena accelerazione ibrida. Quando non si adatta, Karma XPU tende a passare verso l'esecuzione CPU piuttosto che trasferire i dati in streaming come fanno alcuni renderer GPU. Il rendering viene comunque completato, ma a una frazione della velocità prevista — e nulla nel log di un normale job lo evidenzia.

In secondo luogo, XPU è più giovane dei motori con cui compete. Houdini 20.0 è stato il suo primo traguardo di stabilità in produzione e il 20.5 ha ampliato considerevolmente la copertura delle funzionalità, ma alcune funzionalità favoriscono ancora Karma CPU. Se uno shot ne usa una, parte del rendering può silenziosamente passare al percorso CPU.

In terzo luogo, il blocco della versione conta più di quanto ci si aspetti. Una scena creata in una release point di Houdini dovrebbe essere renderizzata su nodi farm che eseguono la stessa release; la superficie di Karma si è modificata abbastanza tra le versioni 20.0, 20.5 e la linea 21 da non dare per scontati i rendering cross-version.

In quarto luogo — e questo mette in difficoltà tutti la prima volta — le simulazioni non sono frame. Non è possibile semplicemente inviare una configurazione Pyro o FLIP a una render farm e aspettarsi che si distribuisca. Questo merita una sezione dedicata, e ne ha una di seguito.

Karma XPU vs Karma CPU vs Mantra

Con Houdini vengono forniti tre renderer, e la scelta tra di essi è la prima decisione reale per qualsiasi job su render farm. Non sono intercambiabili.

Mantra è il motore legacy. Precede USD interamente, opera sulla pipeline di descrizione della scena nativa di Houdini e utilizza shader basati su VEX (CVEX) invece di MaterialX. SideFX non lo ha rimosso e rimane completamente funzionale, ma non riceve nuove funzionalità — la direzione futura è chiaramente Karma. Mantra continua a svolgere il suo ruolo in due contesti: pipeline con librerie profonde di shader VEX che sarebbe costoso ricostruire, e l'occasionale comportamento di micropoligono o displacement che non ha ancora un equivalente Karma appropriato. Se gli shader sono CVEX, non si traducono in Karma, e questo da solo può mantenere uno shot su Mantra.

Karma CPU è il percorso di riferimento. È nativo USD, implementa l'intero set di funzionalità Karma ed è la ground truth quando si deve sapere come dovrebbe apparire un frame. Funziona in multi-threading su core CPU senza coinvolgimento della GPU. Su una render farm con una grande flotta CPU è genuinamente pratico — aggira completamente il limite della VRAM, il che lo rende la scelta sensata per scene troppo pesanti da contenere comodamente nella memoria GPU.

Karma XPU è il percorso accelerato ibrido: CPU più GPU NVIDIA, entrambi che tracciano nello stesso frame, utilizzando shading MaterialX e la stessa base nativa USD di Karma CPU. Abbinando la GPU alla CPU, esegue il rendering dello sviluppo del look interattivo e dei frame finali in-VRAM più velocemente di qualsiasi percorso solo CPU, ed è il default naturale per le nuove pipeline Solaris. La sua limitazione è che è un sottoinsieme delle funzionalità di Karma CPU — la maggior parte delle lacune rimanenti riguarda casi limite di volumi, shading o AOV, e SideFX le sta chiudendo release per release. La regola pratica onesta è di renderizzare un frame di confronto sia su XPU che su CPU prima di impegnare una sequenza su XPU, perché quando XPU e CPU non concordano, CPU è corretto.

Diagramma di Houdini Karma XPU che suddivide il lavoro di rendering tra CPU e GPU contemporaneamente, entrambi contribuendo campioni a un singolo frame.

Esecuzione di Karma XPU in Modalità Headless su una Cloud Render Farm

In modo interattivo, il rendering si avvia premendo il pulsante nel viewport Solaris. Su una render farm, quel pulsante è un programma da riga di comando chiamato husk. È il renderer USD standalone di SideFX — un processo leggero che carica uno stage USD composto e lo renderizza senza avviare una sessione Houdini interattiva completa. Viene fornito con Houdini ed è il modo canonico per eseguire Karma su scala. Un invio appare, in sostanza, così:

husk --renderer Karma \
     --frame 1001 --frame-count 50 \
     --output /project/render/shot_010.$F4.exr \
     /project/usd/shot_010.usd

Ogni nodo della render farm esegue husk sullo stesso stage USD ma per un intervallo di frame diverso, il che è ciò che rende possibile la distribuzione a livello di frame. Lo stage stesso è un file .usd/.usdc completamente composto che fa riferimento a tutta la geometria, le luci, le telecamere e i materiali. Gli AOV non sono flag da riga di comando — sono prim USD Render Var incorporati nello stage dai LOP Render Settings e Render Var, quindi husk li legge senza aver bisogno di una rete Houdini attiva. La beauty, l'alpha, le normali, l'albedo e il resto viaggiano all'interno dell'USD.

Vale la pena conoscere alcune meccaniche specifiche della render farm. Karma supporta il checkpointing, che scrive lo stato di rendering intermedio a intervalli di campione in modo che un frame hero lungo possa riprendere invece di ricominciare da capo se un nodo ha un problema — utile per frame singoli con migliaia di campioni, meno rilevante per animazioni con campioni moderati in cui ogni frame è economico da rifare. Il denoising funziona tramite il denoiser OptiX sulla GPU o OIDN di Intel sulla CPU; su una render farm si propende per OIDN quando la stabilità temporale su molti nodi è importante, perché produce output identico indipendentemente dalla macchina che ha elaborato il frame.

Sul tema delle licenze, è bene essere diretti, poiché è una domanda comune. Karma non è un plugin con licenza separata come Redshift, Arnold, V-Ray e Octane — viene fornito in bundle con Houdini stesso. Super Renders Farm esegue Houdini e Karma con utilizzo solo per il rendering dei job; non siamo un partner SideFX e non rivendiamo licenze Houdini. Poiché la nostra render farm è completamente gestita, non è necessario connettersi da remoto a un nodo, installare Houdini autonomamente o fornire una licenza — si carica la scena e i dati memorizzati nella cache, e le licenze lato rendering sui nostri nodi vengono gestite nell'ambito dell'operatività del servizio. Per i motori commerciali nello stack Houdini, le licenze Redshift, Arnold, V-Ray e Octane sono incluse nella tariffa di rendering.

Lo Stack Houdini di Super Renders Farm

Una render farm che esegue un solo motore costringe ogni shot attraverso un unico insieme di compromessi. I lavori Houdini raramente cooperano con questo approccio, quindi la nostra Houdini cloud render farm esegue l'intera gamma: Karma (in modalità XPU e CPU), Mantra, Redshift, Arnold, V-Ray for Houdini e Octane. Il vantaggio dell'ampia scelta è che si può selezionare il motore giusto per shot anziché per studio — Karma XPU per il pass di look-dev nativo USD, Karma CPU per il frame hero pesante che non si adatta alla VRAM, Redshift per la sequenza critica in termini di velocità, Mantra per la configurazione legacy degli shader.

L'hardware sottostante si divide lungo la stessa linea CPU/GPU che contraddistingue il lavoro Houdini. La nostra flotta CPU contribuisce oltre 20.000 core CPU, dove avviene la maggior parte del rendering in produzione — nell'industria e sulla nostra farm, il rendering CPU è ancora la quota maggiore dei job. Quella capacità CPU è ciò che rende Karma CPU e Mantra pratici su scala di sequenza e ciò che supporta Karma XPU quando un frame è troppo pesante per la GPU. Per il lavoro GPU, le nostre macchine GPU dedicate eseguono schede NVIDIA RTX 5090 con 32 GB di VRAM ciascuna. Per Karma XPU specificamente, quei 32 GB sono il numero più importante: la VRAM è il limite effettivo su quanto può essere complessa una scena prima che XPU smetta di accelerare sulla GPU. Un set di texture UDIM 4K, un ambiente denso con istanze o un VDB ad alta risoluzione possono ciascuno consumare rapidamente quel budget, e più grande è la scheda, più si può procedere prima che il rendering passi silenziosamente alla CPU. Per chi sta valutando il lavoro GPU in generale, le nostre note sul rendering GPU con RTX 5090 approfondiscono la scheda, e la pagina GPU render farm copre la flotta.

Diagramma di Karma XPU e VRAM GPU: una scena che si adatta a 32 GB di VRAM viene renderizzata alla velocità ibrida CPU+GPU, mentre una scena che supera la VRAM passa alla CPU.

La fatturazione segue l'hardware: il rendering CPU è misurato per GHz-ora e il rendering GPU per OctaneBench-ora, quindi una sequenza Karma CPU e una sequenza Redshift vengono prezzate sulle unità che descrivono effettivamente il lavoro svolto. Poiché Karma XPU può utilizzare entrambi i dispositivi, il modello mentale più chiaro è che viene fatturato come tempo GPU quando funziona su un nodo GPU e rimane in VRAM, con il contributo CPU incluso — un altro motivo per rispettare il limite della VRAM.

Caching delle Simulazioni: Il Passaggio che Non Si Può Saltare

Ecco il concetto singolo più importante per il rendering di Houdini su qualsiasi render farm, e quello più probabile che faccia perdere una giornata se viene frainteso: i frame sono parallelizzabili in modo imbarazzante, ma le simulazioni non lo sono.

Il frame 1042 di un'animazione renderizzata non necessita che il frame 1041 esista prima — entrambi possono essere renderizzati su macchine separate nello stesso momento. Questa indipendenza è l'intera ragione per cui le render farm funzionano. Una simulazione è il contrario. Il frame 1042 di una simulazione Pyro viene calcolato a partire dallo stato del fumo al frame 1041, che proveniva dal 1040, e così via fino al primo frame. Non è possibile calcolare la parte centrale di una simulazione senza calcolare tutto ciò che precede, nell'ordine, su una sola macchina. Se si invia una simulazione grezza a una render farm, non c'è nulla da distribuire.

La soluzione è deterministica e non negoziabile: simulare prima, memorizzare nella cache su disco, poi renderizzare la cache sulla render farm. La simulazione viene eseguita in sequenza su una macchina (o una macchina di simulazione dedicata) e scrive il risultato di ogni frame su disco. Quei file di cache — ora dati statici e indipendenti dai frame — sono ciò che la render farm renderizza. I nodi di rendering non simulano mai di nuovo; leggono geometria e volumi pre-calcolati e tracciano i frame in parallelo come qualsiasi altra animazione.

Diagramma della pipeline: una simulazione viene risolta in sequenza su una macchina, memorizzata nella cache su disco come VDB o bgeo, poi renderizzata frame per frame in parallelo su una render farm.

Cosa si memorizza nella cache dipende dal solver:

Vale la pena sottolineare un dettaglio: c'è una reale differenza tra la simulazione stessa e il lavoro a valle. Il surfacing FLIP — trasformare le particelle memorizzate nella cache in una mesh di rendering — dipende solo dalle particelle di ogni frame, non dal frame precedente, quindi quel passaggio è parallelizzabile e può essere inviato alla render farm come pass separato anche se la simulazione sottostante non lo poteva. Il pattern sempre più comune nelle pipeline Houdini 20+ è di memorizzare la geometria direttamente in USD, in modo che husk la legga nativamente al momento del rendering senza passaggi di traduzione da SOP a USD sul nodo.

È anche qui che PDG/TOPs guadagna il suo posto. PDG è il grafo delle attività con consapevolezza delle dipendenze di Houdini, e modella esattamente la relazione di cui il rendering su render farm ha bisogno: "memorizza nella cache questa simulazione, e solo una volta che la cache esiste, renderizza questi frame da essa." Un File Cache TOP produce la cache della simulazione come dipendenza di output; un'attività di rendering a valle la attende e poi si espande per frame. PDG può guidare sia il caching che il rendering husk attraverso i suoi nodi scheduler, il che è il motivo per cui è diventato la spina dorsale delle pipeline Houdini serie per le render farm.

Una nota pratica dall'esperienza: le cache di tessuti e liquidi ad alta risoluzione possono arrivare a gigabyte per frame, e quando decine di nodi estraggono la stessa sequenza dallo storage condiviso contemporaneamente, il throughput di lettura — non il calcolo — diventa il collo di bottiglia. Super Renders Farm supporta upload senza un limite rigido di dimensioni (si suggerisce di restare sotto i 300 GB per upload, utilizzando SFTP o l'app client al di sopra di tale soglia) e accetta archivi .tar, .tar.gz e .7z — ma non .zip. Reimpacchettare le sequenze di cache pesanti come .tar.gz prima del caricamento. L'output renderizzato rimane disponibile per 45 giorni dopo il completamento di un job, il che è un tempo più che sufficiente per scaricare una sequenza completa.

Invio di un Job Karma XPU, dall'Inizio alla Fine

Mettendo insieme tutti i pezzi, un job Karma XPU pulito su render farm segue un ordine prevedibile:

Workflow in sei passaggi per l'invio di un job Karma XPU a una cloud render farm: memorizzare nella cache le simulazioni, esportare lo stage USD, caricare, scegliere il motore, distribuire i frame, denoising e download.

1. Memorizzare nella cache ogni simulazione. Pyro in VDB, FLIP e Vellum in .bgeo.sc o USD. Verificare che le cache siano complete e continue per frame — un frame mancante nel mezzo si manifesta come un buco nel rendering, non come un errore.
2. Esportare uno stage USD composto con i prim Render Settings e Render Var incorporati, tutti i percorsi delle risorse risolti in modo che siano raggiungibili da un nodo di rendering piuttosto che dai drive locali della workstation.
3. Impacchettare il progetto — scena, cache, texture e qualsiasi configurazione OCIO — e caricarlo. Poiché la render farm è completamente gestita, non c'è nessun nodo in cui accedere e nessuna installazione Houdini da gestire.
4. Scegliere il motore. Karma XPU per i pass di look-dev e finali in-VRAM; passare a Karma CPU per i frame che si sa essere troppo pesanti per 32 GB; ricorrere a Redshift dove la velocità è la priorità.
5. Distribuire i frame. La render farm distribuisce l'intervallo di frame tra i nodi, ognuno eseguendo husk per la propria porzione. Si monitora il progresso invece di gestirlo.
6. Denoising e download. Scaricare i file EXR (con OIDN applicato se configurato) entro la finestra di 45 giorni.

Il modo in cui si fallisce ripetutamente in tutto questo è la risoluzione delle risorse. USD risolve i percorsi relativi al layer che li referenzia o come percorsi assoluti, e un percorso assoluto che punta al drive locale della propria workstation produrrà semplicemente texture o geometria mancanti su un nodo di rendering — spesso senza un errore rigido, solo nero dove dovrebbe esserci una risorsa. Risolvere i percorsi rispetto a una radice di progetto condivisa, mantenere la configurazione OCIO coerente tra i job in modo che il colore non cambi, e appiattire le dipendenze HDA personalizzate nell'USD prima dell'esportazione in modo che un nodo non abbia bisogno di un plugin che non è mai stato fornito. Per i fondamentali più ampi su come il cloud rendering distribuisce questo tipo di lavoro, la nostra panoramica della cloud render farm fornisce il contesto.

Quando Scegliere Karma XPU vs Redshift

Sia Karma XPU che Redshift possono renderizzare Houdini su una GPU render farm, e la scelta non riguarda quale sia "migliore" — riguarda ciò di cui lo shot e la pipeline hanno bisogno. Provengono da filosofie diverse. Karma XPU è fisicamente basato, nativo USD, con shading MaterialX e realizzato dallo stesso fornitore di Houdini. Redshift è un renderer GPU prevalentemente biased, maturo, con più di un decennio di storia in produzione, un plugin Houdini e — questa è la sua caratteristica distintiva su render farm — un robusto sistema out-of-core che si riversa elegantemente dalla VRAM alla RAM di sistema e all'NVMe quando una scena diventa troppo grande. Dove Karma XPU tende a passare alla CPU in caso di overflow della VRAM, Redshift continua a renderizzare sulla GPU con una penalizzazione delle prestazioni prevedibile, il che è il motivo per cui una scheda da 32 GB può gestire scene con molti più di 32 GB di texture con Redshift.

Questa differenza guida la maggior parte delle decisioni:

Gli altri motori coprono i margini. Arnold è la scelta per effetti visivi pesanti con subsurface complesso, capelli e volumi, o quando una pipeline dipende già da shader specifici di Arnold — basta bloccare la versione HtoA sui nodi della farm e pre-convertire le texture in .tx. V-Ray for Houdini ha senso per gli studi già standardizzati su V-Ray tra 3ds Max e Maya che vogliono un look coerente tra i DCC; si può approfondire il lato GPU di quel confronto sulla nostra pagina Redshift. Octane è adatto ai team già nel suo ecosistema spettrale basato su nodi e viene fatturato in modo preciso per OctaneBench-ora. Se si desidera un confronto più ampio provider per provider invece che per motore, il nostro confronto tra render farm Houdini copre quella decisione.

Una cautela specifica per Karma XPU su una render farm: poiché una sequenza può contenere sia frame leggeri (accelerati da GPU) che frame pesanti (silenziosamente limitati dalla CPU), i tempi di rendering possono variare notevolmente in quello che sembra un job uniforme. La soluzione è un controllo pre-flight della memoria sul frame più pesante prima di impegnarsi sull'intera gamma — se sta per superare i 32 GB di VRAM, è meglio scegliere deliberatamente tra Karma CPU sulla flotta CPU e il percorso out-of-core di Redshift piuttosto che lasciare che il renderer decida da solo a metà sequenza. Oltre al motore stesso, si applicano ancora i problemi tipici della render farm: bloccare la versione di Houdini, mantenere la configurazione del denoiser esplicita piuttosto che fare affidamento sulle impostazioni predefinite per nodo, e verificare che ogni percorso delle risorse si risolva da un nodo e non solo dalla propria macchina.

Per i dettagli ufficiali sui renderer, SideFX mantiene una documentazione approfondita sia per Karma che per il renderer da riga di comando husk — vale la pena leggerla prima del primo invio di grandi dimensioni.

FAQ

Q: Qual è la differenza tra Karma XPU e Karma CPU? A: Sono lo stesso renderer Karma nativo USD in due modalità di esecuzione. Karma CPU funziona solo su core CPU e implementa il set di funzionalità completo di qualità di riferimento. Karma XPU aggiunge la GPU NVIDIA e renderizza su CPU e GPU insieme per velocità, ma attualmente supporta un sottoinsieme delle funzionalità di Karma CPU ed è limitato dalla VRAM della GPU. L'abitudine pratica è di confermare un frame su Karma CPU quando l'output XPU sembra errato, perché CPU è la ground truth.

Q: È necessaria una licenza SideFX o Houdini per renderizzare Karma su una cloud render farm? A: Non è necessaria dalla propria parte, su una render farm completamente gestita. Karma viene fornito in bundle con Houdini piuttosto che essere concesso in licenza separatamente come Redshift o Octane, e Super Renders Farm esegue Houdini con utilizzo solo per il rendering dei job — non siamo un partner SideFX e non rivendiamo licenze Houdini. Si carica la scena e le cache; le licenze lato rendering sui nostri nodi vengono gestite come parte del servizio gestito.

Q: Perché le simulazioni devono essere memorizzate nella cache prima del rendering su una render farm? A: Perché le simulazioni sono sequenziali e i frame non lo sono. Ogni frame di simulazione dipende dallo stato del frame precedente, quindi una simulazione deve essere risolta nell'ordine su una sola macchina. I frame di rendering, al contrario, sono indipendenti e possono essere eseguiti su centinaia di nodi contemporaneamente. Memorizzare nella cache la simulazione completata su disco (VDB per Pyro, .bgeo.sc o USD per FLIP e Vellum) la trasforma in dati statici che la render farm può renderizzare in parallelo senza ri-simulare.

Q: Come gestisce Karma XPU una scena che supera la VRAM della GPU? A: A differenza di Redshift, che trasmette in streaming out-of-core dalla memoria di sistema, Karma XPU tende a passare verso l'esecuzione CPU quando una scena non si adatta alla VRAM. Il rendering viene comunque completato, ma l'accelerazione GPU viene persa e il frame può richiedere tempi notevolmente più lunghi — senza nulla di evidente nel log. Per le scene che si sa essere pesanti, è meglio scegliere deliberatamente Karma CPU sulla flotta CPU o il percorso out-of-core di Redshift piuttosto che lasciare che il fallback avvenga a metà sequenza.

Q: Karma XPU è più veloce di Redshift? A: Dipende dallo shot. Redshift è un renderer GPU altamente ottimizzato, prevalentemente biased ed è spesso più veloce sulle scene di produzione tipiche, specialmente quelle pesanti di VRAM dove il suo sistema out-of-core mantiene il lavoro sulla GPU. Karma XPU è fisicamente basato e completamente nativo USD, il che è più adatto per le pipeline Solaris e lo shading MaterialX anche se richiede più campioni per rumore equivalente. La velocità da sola non decide — l'adattamento alla pipeline e il margine di VRAM di solito lo fanno.

Q: Cos'è husk e occorre utilizzarlo direttamente? A: husk è il renderer USD da riga di comando standalone di SideFX, ed è ciò che renderizza effettivamente Karma su un nodo della render farm — un processo leggero che carica uno stage USD composto senza una sessione Houdini completa. Su una render farm gestita non lo si invoca manualmente; si invia la scena e la render farm esegue husk per frame tra i nodi. Sapere che esiste aiuta a capire perché un'esportazione USD pulita e completamente risolta è così importante.

Q: PDG/TOPs può guidare un rendering Karma sulla render farm? A: Sì. PDG modella la dipendenza tra la memorizzazione nella cache di una simulazione e il rendering da essa, e i suoi nodi scheduler possono distribuire sia il passaggio File Cache che il rendering husk a valle su una render farm. È il modo standard in cui le pipeline Houdini serie esprimono "prima memorizza nella cache, poi distribuisci il rendering per frame", e mantiene automaticamente le parti sequenziali e parallele del job nel giusto ordine.

Q: Quali altri renderer Houdini possono essere utilizzati oltre a Karma XPU? A: Lo stack Houdini di Super Renders Farm esegue Karma in modalità XPU e CPU, più Mantra, Redshift, Arnold, V-Ray for Houdini e Octane. Quella gamma permette di abbinare il motore allo shot — Karma XPU per il look-dev nativo USD, Karma CPU per i frame hero pesanti di VRAM, Redshift per velocità e out-of-core, Mantra per shader VEX legacy, e Arnold, V-Ray o Octane dove una pipeline dipende già da essi.