Jump to content

Recommended Posts

salve a tutti, mi sto interessando di render fatto con l'aiuto della gpu. Ho trovato due motori di render che utilizzano questa tecnologia, gelato per nvida, e rtsquare, tutti e due per max.

Però la qualità non raggiunge quella ottenuta con vray. Qualcuno usa questi motori, o da consigliarme altri?

Sopratutto, vray si può impostare perchè usi la gpu, o sarà possibile in futuro?

Share this post


Link to post
Share on other sites

ciao, da quello che so io per ora non ci sono motori in grado di utilizzare la potenza delle GPU e che siano contemporaneamente in grado di offrire la stessa qualità di mr, v-ray etc..sarà interessante tenere d'occhiio l'argomento perchè a mio avviso in futuro si punterà molto sul calcolo GPGPU e molto probabilmente anche i motori di rendering più famosi troveranno terreno fertile nell'uso delle GPU.

Share this post


Link to post
Share on other sites

di commerciale non so....in prossima uscita dovrebbe esserci lightwave 10 o lwcore, che a quanto ho capito dalle news che trapelano da sito madre, dovrebbe implementare l'uso della gpgpu....

poi, per quanto riguarda il freeware o opensource ci dovrebbe essere parthenon render, lo trovi a questo link

ciao!!!

Share this post


Link to post
Share on other sites

È un bel po' che nVidia ha preso mental ray, se noti in Max è già stato integrato Mental Mill e lo stesso mental mill è supportato in fx composer e l'ultima versione di cgFX.

E come è facile aspettarsi nVidia sta investendo molto e si sta spianando la strada.

Comunque non penso che il futuro del render su GPU sia così roseo e prevedibile come può sembrare, o almeno io ho qualche perplessità.

Vi spiego, attualmente le GPU hanno uno scarso supporto per i numeri floating point a 64 bit, fondamentali se si vuole mantenere la stessa qualità del render software.

I registri della maggior parte delle schede video sono a 128 bit, e vengono organizzati così

vettori da 4 a 32 bit (RGBA o XYZW)

vettori da 2 a 64 bit.

Avendo un vettore da 4 tutto dentro un registro si possono fare operazioni su vettori (prodotto scalare o altro) usando un registro per operando. Su i vettori da due non si può fare quasi niente. :(

Per farlo andare più veloce e aggiungere istruzioni specializzate per vettori a 64 dovrebbero raddoppiare la dimensione dei registri. Notare che registri più grandi vuol dire die più grande che vuol dire GPU più lenta. E a i videogiocatori non gli frega niente delle operazioni a 64 bit. Schede dedicate? Non credo, sviluppare una scheda costa svariate decine di milioni di dollari. quadro per fare i rendering e Geforce per giocare? forse, ma anche le quadro servono per il rendering real-time.

Comunque sarebbe mal di poco, ci sono a disposizione 480 core se va un pelino più piano va ugualmente 20 volte più veloce di un 8 core intel.

MA!! C'è un grande ma. Stanno sempre facendo capolino sul mercato i sistemi super scalari, intel dice che rilascerà larrabee a inizio 2010, AMD con fusion mostra l'intenzione di creare una struttura CPU+GPU sempre più connessa. Sembra che si andrà sempre verso un futuro dove GPU e CPU sono una cosa sola.

L'architattura larrabee ha la cosa buona (e che ha portato sempre tanta fortuna a Intel) di essere compatibile con x86. Quindi mental ray preso così senza nessuna modifica ci funzionerebbe sopra.

Altro problema è che CUDA non gira su ATI, e ATI per adesso non ha avuto molto successo su il GPGPU. Tutti stanno aspettando il rilascio di openCL, le specifiche sono già uscite, nVidia ha già rilasciato dei demo e c'è già una SDK disponibile per gli sviluppatori registrati, ma ancora non c'è nessun programma disponibile al pubblico, ne i driver per supportarlo. Forse stanno aspettando openCL, immagino che sullo sviluppo di mental ray anche autodesk abbia della voce in capitolo (non me lo sviluppi come mi piace a me? Allora metto V-Ray di default su 3d Max. :P ) e immagino che Autodesk voglia che i suoi programmi girino in egual modo su tutte le schede.

Le due cose che mi chiedo io sono:

-i produttori di hardware modificheranno l'architettura delle GPU per supportare al meglio il calcolo a 64bit?

-conviene riscrivere da capo un engine sapendo che il mercato sta tendendo a unificare CPU e GPU? Non so di preciso come funziona mental ray, magari basta riscrivere uno shader per supportare CUDA, forse no.

Lui dice di sì. -> http://sjannuz.com/cuda/cuda_meets_mr.html

Io penso che se fosse così semplice lo avrebbero già fatto, o forse prima di annunciare una cosa abbrocciata vorranno pensarci un attimino. :-\

Per adesso sul sito nVidia invece spuntano come funghi le applicazioni video

http://www.nzone.com/object/nzone_loilo_home.html (dopotutto i 64 bit servono per il raytracing)

Share this post


Link to post
Share on other sites
Notare che registri più grandi vuol dire die più grande che vuol dire GPU più lenta

non necessariamente..

le nuove generazioni di GPU tendono ad aumentare la precisione del calcolo FP come del resto ci si aspetta in ogni passo evolutivo (questo in generale).

Share this post


Link to post
Share on other sites
È un bel po' che nVidia ha preso mental ray, se noti in Max è già stato integrato Mental Mill e lo stesso mental mill è supportato in fx composer e l'ultima versione di cgFX.

E come è facile aspettarsi nVidia sta investendo molto e si sta spianando la strada.

Comunque non penso che il futuro del render su GPU sia così roseo e prevedibile come può sembrare, o almeno io ho qualche perplessità.

Vi spiego, attualmente le GPU hanno uno scarso supporto per i numeri floating point a 64 bit, fondamentali se si vuole mantenere la stessa qualità del render software.

è vero ma non è del tutto giusto

alcuno motori di render già oggi non usano il double precision floating point, ma il single precision

c'è stata una lunga discussione a riguardo su cgtalk, con interventi degli sviluppatori di brazil (un renderer a cui possiamo dire di tutto, ma non che non arrivi a un elevato livello di qualità), cito:

"For the curious, Brazil r/s uses single precision almost everywhere. It's enough if you do the math correctly."

e anche:

"Having spending last 9 years by designing, coding, maintaining one of the few professional renderers on the market, I'm just telling our real-life experience on the subject. Of course like anyone else I can be wrong too. You are free call Brazil "not a professional renderer", or disregard my comments, I can't do anything there"

Altro problema è che CUDA non gira su ATI, e ATI per adesso non ha avuto molto successo su il GPGPU. Tutti stanno aspettando il rilascio di openCL,

negli ultimi tempi nvidia ha cambiato approccio su cuda, il supporto a openCL è sviluppato all'interno di cuda, quindi è molto probabile che puntino ad avere software che girano su openCL (compatibili con ATI/...) e che siano accelerati con cuda solo nelle sue piattaforme

Lui dice di sì. -> http://sjannuz.com/cuda/cuda_meets_mr.html

Io penso che se fosse così semplice lo avrebbero già fatto, o forse prima di annunciare una cosa abbrocciata vorranno pensarci un attimino. :-\

un conto è riscrivere uno shader con il supporto a cuda, un altro è riscrivere tutto un motore di rendering (tenendo presente che mental ray non è esattamente una piattaforma di sviluppo modernissima, buona parte del codice viene ancora dagli anni '90)

Share this post


Link to post
Share on other sites
non necessariamente..

Die più grosso == maggiori capacità apparenti == processore più lento.

È fisica, ci puoi investire tutti i soldi che ti pare ma non la cambi. È per questo che cercano di fare circuiti sempre più piccoli.

Quello che è stato aumentato nelle ultime generazioni è la banda passante tra CPU (della scheda video) e Memoria (sempre sulla scheda). Sulle specifiche nVidia viene chiamato Memory Interface Width, le process unit invece hanno sempre registri a 128 bit.

@dagon: Lavoro con il realtime quindi ti posso garantire che con il floating point a 32 bit si fa tantissima roba. ^_^

Il problema con i floating point è che allontanandosi dallo zero si perde sempre di più di precisione. Per esempio in 32 bit 90.000.001 - 90.000.000 = 0 :-S

I problemi diventano più grossi quando si fanno divisioni per numeri che si avvicinano allo zero, ma come dice appunto la persona che hai citato "facendo la matematica correttamente" questi problemi non ci dovrebbero essere.

Ho dato un occhiata veloce ai file di include di mental ray (quelli che bisogna usare per programmare uno shader) e miScalar è float (32 bit). E colori, matrici e vettori sono fatti tutti da miScalar. Ci sono anche numeri a 64 bit (chiamati GeoScalar, ma vengono usati molti più di rado). Quindi "forse" il problema dei 64 bit non c'è.

negli ultimi tempi nvidia ha cambiato approccio su cuda, il supporto a openCL è sviluppato all'interno di cuda, quindi è molto probabile che puntino ad avere software che girano su openCL (compatibili con ATI/...) e che siano accelerati con cuda solo nelle sue piattaforme

Non ho capito cosa vuoi dire. :-S

Cuda può essere eseguito su qualsiasi computer, se il computer ha i driver per l'accelerazione viene eseguito con l'accelerazione, altrimenti viene eseguito su CPU in multithreading.

Stessa cosa farà openCL, se ha i driver appropriati va in accelerazione HW altrimenti in emulazione, come succede per le librerie grafiche.

È il driver che conta, ATI non vuole supportare CUDA perché non vuole dipendere (e far sviluppare) una tecnologia creata dall'avversario. Per quanto riguarda nVidia le applicazioni openCL e quelle CUDA ovviamente avranno due librerie diverse, ma poi a basso livello faranno capo al solito driver, questo è ovvio.

Il problema è che per adesso openCL non è ancora uscito. Ne l'SDK, ne il driver.

un conto è riscrivere uno shader con il supporto a cuda, un altro è riscrivere tutto un motore di rendering (tenendo presente che mental ray non è esattamente una piattaforma di sviluppo modernissima, buona parte del codice viene ancora dagli anni '90)

Proprio quello che mi stavo chiedendo, sul funzionamento interno sono sicuro che ne sai più te di me.

Può darsi che per avere un accelerazione di alcune parti basti scrivere uno shader, ma per avere un accelerazione completa penso debbano riscrivere molto codice, ergo ci vuole tempo.

Viste le premesse e viste le cose che si possono fare con CUDA penso proprio ne valga la pena, ma non penso vogliano fare una cosa affrettata. :)

Share this post


Link to post
Share on other sites
Non ho capito cosa vuoi dire. :-S

Cuda può essere eseguito su qualsiasi computer, se il computer ha i driver per l'accelerazione viene eseguito con l'accelerazione, altrimenti viene eseguito su CPU in multithreading.

Stessa cosa farà openCL, se ha i driver appropriati va in accelerazione HW altrimenti in emulazione, come succede per le librerie grafiche.

È il driver che conta, ATI non vuole supportare CUDA perché non vuole dipendere (e far sviluppare) una tecnologia creata dall'avversario. Per quanto riguarda nVidia le applicazioni openCL e quelle CUDA ovviamente avranno due librerie diverse, ma poi a basso livello faranno capo al solito driver, questo è ovvio.

Il problema è che per adesso openCL non è ancora uscito. Ne l'SDK, ne il driver.

nvidia sta implementando openCL "sopra" cuda, significa che non ci sono due driver diversi, i driver openCL useranno cuda

nvidia ha da poco rilaciato l'SDK e i drive openCL in beta

Proprio quello che mi stavo chiedendo, sul funzionamento interno sono sicuro che ne sai più te di me.

Può darsi che per avere un accelerazione di alcune parti basti scrivere uno shader, ma per avere un accelerazione completa penso debbano riscrivere molto codice, ergo ci vuole tempo.

Viste le premesse e viste le cose che si possono fare con CUDA penso proprio ne valga la pena, ma non penso vogliano fare una cosa affrettata. :)

infatti ci vorrà tempo, nvidia sta giocando una partita difficile, se vuole sopravvivere deve capitalizzare in qualche modo tutto quello che ha investito in questo campo, se non si gioca bene le sue carte è facile che intel si mangi anche questo mercato

Share this post


Link to post
Share on other sites

ok, stiamo dicendo le stesse cose :D

"nvidia sta implementando openCL "sopra" cuda, significa che non ci sono due driver diversi, i driver openCL useranno cuda" = "le applicazioni openCL e quelle CUDA ovviamente avranno due librerie diverse, ma poi a basso livello faranno capo al solito driver"

"nvidia ha da poco rilaciato l'SDK e i drive openCL in beta" = "c'è già una SDK disponibile per gli sviluppatori registrati"

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...