GPU vs CPU: Migliorare le Prestazioni di Cinema 4D con CUDA

[abe3d]

Vorrei condividere i risultati sperimentali ottenuti forzando l'utilizzo dell'accelerazione CUDA per gestire calcoli computazionali intensivi, solitamente affidati alla CPU. Va premesso che integrare librerie Python di terze parti in Cinema 4D non è affatto semplice, soprattutto quando non si utilizza il package installer Pip.

In questo video https://www.youtube.com/watch?v=B7aenQ3W0CU dimostro come Cinema 4D migliora le proprie prestazioni affidando alla GPU i calcoli iterativi, e quali vantaggi si ottengono con una tale integrazione. Devo dire che alla Maxon, negli ultimi tempi, si stanno dando davvero da fare in questa direzione promuovendo questo tipo di soluzione in modo compartimentato, spero che col tempo questo discorso venga ampliato a tutto il comparto computazionale.

Alcuni dati significativi sulla scena:
- La "superficie del liquido" è una mesh composta da 40.400 punti, senza facce né segmenti.
- Il cucchiaio interagisce con la superficie attraverso una selezione di 87 vertici (ma potrebbero esserne arbitrariamente molti di più senza
gravare eccessivamente sulle prestazioni).
- La VertexMap è generata solo per un riscontro visivo; il calcolo vero e proprio è gestito internamente dal codice.

Il codice è eseguito in tempo reale da un Python Generator e si occupa di gestire l'interazione tra i due oggetti, calcolare l'effetto delle onde nel fluido, calcolare la posizionare dei punti.

È evidente che non c'è confronto con i calcoli su CPU, facendo due rapidi conticini si ottiene facilmente il numero di iterazioni per frame per le tre computazioni principali e C4D si pianterebbe miseramente. Infatti, eseguendo i calcoli sulla GPU si mantengono stabilmente 22-25 fotogrammi al secondo. Tuttavia, quando i risultati tornano alla CPU, nonostante i calcoli siano stati già eseguiti dalla GPU, quindi, soltanto per posizionare fisicamente i punti, si perde in media il 40% degli FPS, attivando poi il mesher si arriva addirittura al 65% di perdita di prestazioni.

vlcsnap-2024-07-30-15h02m35s383.png (312.34 KiB) Visto 1814 volte

vlcsnap-2024-07-30-15h01m38s706.png (541.01 KiB) Visto 1814 volte

Questo dimostra quanto sia vantaggioso utilizzare la GPU per gestire operazioni complesse in Cinema 4D, migliorando significativamente la fluidità e l'efficienza delle simulazioni.

OS: Microsoft Windows 11 Pro for Workstations
Processore: Intel(R) Core(TM) i7-10700KF CPU @ 3.80GHz, 3792 Mhz, 8 core, 16 processori logici
Memoria fisica installata (RAM) 32,0 GB
Archiviazione: 2 NVME
Scheda Video: NVIDIA GeForce RTX 2070 SUPER

[masterzone]

molto molto interessante...domanda: ma quando il calcolo viene demandato alla CPU, vengono usati tutti e otto i Core e i 16 processori, oppure e' mono core? perche' penso sia fondamentale anche questo nel test, in quanto la peculiarità della GPU e' quella di avere un multi processing praticamente per tutto, a differenza del processore CPU che e' difficile che spesso i calcoli siano multi thread...

[abe3d]

Ciao Ale, domanda lecita che richiede una più approfondita analisi per sviscerare la questione (un pò tecnica ma di facile comprensione):

Il Multithreading in python è notoriamente fuori discussione (e ti assicuro che ci ho provato in tutti i modi, ma il GIL non te lo permette proprio e in cinema ancora meno che in soluzioni puramente python dove in alcuni casi e con qualche escamotage si riesce comunque ad aggirare il problema), per questo motivo mi sono spinto ad affrontare il problema utilizzando il Cuda toolkit installato da Conda utilizzando Array numpy invece che i vettori integrati (per i più smanettoni, sto cercando di migliorare il processo integrando CuPy per sostituire numpy) su una specifica versione di cinema (quindi non a livello di sistema). Questo chiarisce che tutto quello che esce da python è single thread, indistintamente.

Premetto che tutto sto casino ha senso solo in presenza di grandi quantità di dati da processare per singolo frame, non avrebbe nessuna funzionalità per spostare quattro oggetti, detto questo, Il processo di attuazione del codice è eseguito in questo modo:

CPU - Si inizializzano variabili, costanti e quant'altro e dove necessario (per esempio una lista di c4d.Vector(x,y,z)) si "scompattano" in array numpy, gli array vanno passati (letteralmente copiati tramite specifiche istruzioni) alla funzione decorata per il calcolo GPU (già questa parte influisce non poco sulle pure prestazioni raggiungibili).

GPU - Qui tutto è parallelizzato e calcolato in un tempo ridicolmente breve per qualsiasi dimensione dei dati da processare, anzi, più ne sono è meglio è, a patto di rispettare regole è imposizioni del codice Cuda.

CPU - i risultati ottenuti ritornano all'host (CPU), vengono cioè assegnati a nuove variabili richiamandoli direttamente dalla funzione Cuda una volta terminata l'elaborazione. Si ricostruiscono le strutture dati originarie (si riassegnano quindi i valori nel formato accettato da cinema, es. c4d.Vector), non si può fare diversamente e questo rallenta ulteriormente l'esecuzione.

CPU (CINEMA 4D Python) - Questa fase è il vero collo di bottiglia, l'assegnazione dei nuovi valori è ridicola, tanto che sembra lo faccia a mano... mi spiego peggio con un qualche tecnicismo...
Per settare la nuova posizione calcolata di ogni singola particella TP, bisogna inevitabilmente passare attraverso un ciclo (esempio di pseudo codice):

Codice: Seleziona tutto

for vettoreXYZ in VettoriXYZ:
    SetPosition (vettoreXYZ)

Questo è uno dei motivi per cui ho abbandonato la sperimentazione con TP a vantaggio dei punti mesh che invece possiede un più veloce

Codice: Seleziona tutto

SetAllPoints(VettoriXYZ)

In conclusione, se il codice non è scritto in C++ (e anche così non è detto a prescindere) non c'è altro modo di accelerare un flusso se non utilizzando questa tecnica, bisogna precisare però che come anticipato, il discorso si riferisce esclusivamente al codice python in esecuzione, nel caso per esempio del mesher (utilizzato anche nel test) se questo fosse multithread, sarebbe accelerato perché applicato successivamente ed esternamente al codice, stesso discorso se a spostare i vertici di una geometria fosse un deformer diplacer (sempre se fosse multithread) leggendo una mappa vertici.
Per intenderci, le prestazioni, anche se falsate, come spiegato nel processo di attuazione, sono riferite esplicitamente alla prima parte del video, quella indicata come "computazione grezza".

Ma andiamo oltre...
La rivoluzione si palesa non solo per la simulazione in viewport, Il vero vantaggio sta nella costruzione della cache (faccio l'esempio con l'esportazione alembic per un successivo riutilizzo), che viene anch'essa calcolata dalla GPU risultando in un vero risparmio di tempo.

Spero di non essere stato troppo pesante e prolisso (rompic.)

[abe3d]

Effetto a velocità reale (1X) di del test
https://www.youtube.com/watch?v=LGMhWVPDTXI
Una delle svariate configurazioni possibili...

[Sirio76]

Sarà che di codici non ne capisco nulla, ma ancora una volta il tuo lavoro mi sembra sorprendente e i tuoi video meriterebbero molta più visibilità:)

[masterzone]

Moooolto figo!

[abe3d]

Sirio grazie come sempre per l'apprezzamento

Il rispondere alla domanda di Alessandro mi ha fatto ragionare su come poter limare i colli e ottenere qualche fotogramma in più (grazie Ale), sono riuscito a portare a 30 gli FPS di media, pur avendo aumentato a 628 i punti del cucchiaio che interagiscono con la superfice, migliorando di parecchio la resa del "liquido" (i risultati nei prossimi aggiornamenti).

Ho deciso di continuare a esporre i vari passaggi, magari riesco a migliorare ancora!

Piccola premessa: Come accennato precedentemente tutti i dati passati alla GPU sono generalmente Array numpy preconfezionati per il codice Cuda e vengono aggiornati alla fine di ogni ciclo-frame, per questo elaborati una sola volta per frame e successivamente letti senza doverli ricalcolare continuamente, per fare un esempio pratico, se avessi bisogno di sapere in che posizione si trova il punto con ID 100 più volte in un frame, non dovrò chiederlo a cinema 4D ma lo leggero dall'array (ovvio ma non scontato).

Come assegno un peso alla superficie a contatto con il cucchiaio:
Banalmente calcolo la distanza euclidea di ogni punto selezionato del cucchiaio, impostato in un point selection tag, rispetto a tutti i punti della superfice (che ricordo sono 40400), assegnando un valore tra -1 e 1 in base alla distanza² (e qualche altra condizione minore). Questo passaggio potrebbe essere alleggerito, ma, elaborando le distanze direttamente nella funzione CUDA, al momento non fa molta differenza.

- Come ottengo l'effetto onda che si propaga (forse la parte più interessante):
Usando due array, una "Base" e un secondo come "Tampone"...

Immagine 2024-07-30 203903.png (15.91 KiB) Visto 1659 volte

Base.valA = ((Tampone.valB + Tampone.valC + Tampone.valD + Tampone.valE)/2) - Base.valA

per tutta la griglia (per i punti al bordo c'è qualche regola diversa).
Ottengo così un array di pesi che assegno alla griglia, successivamente clono l'array ottenuto sul secondo array e ricomincio. Questo genera un flusso continuo che viene smorzato punto per punto da un valore Damping predeterminato...
Semplice no??

-Come sposto i punti della superficie:
Anche se questa tecnica non è totalmente implementata nei test appena postati, fa parte di un complesso sistema per generare movimento trasversale e longitudinale calcolando i dati di propagazione delle onde.
Se ne può vedere l'effetto nel post che sta alla base di questi test (all'epoca ancora non accelerati).
https://www.c4dzone.com/it/forum/viewto ... ilit=fluid
e nel video su youtube al link https://youtu.be/Ca_DQ7NkHfE

[masterzone]

minchia che roba!

[hurricane]

Genius!

[nysn]

Fantastico, sei troppo in gamba porca miseria!