Vai al contenuto

ilmale

Members
  • Portfolio

    Portfolio
  • Numero messaggi

    1669
  • Registrato

  • Ultima Visita

  • Days Won

    1

ilmale last won the day on July 8 2011

ilmale had the most liked content!

Info su ilmale

  • Rango
    Treddipendente

Informazioni professionali

  • Impiego
    Impiegato (Employee)
  • Sito Web
    http://www.milestone.it

Ospiti che hanno visualizzato il profilo

4783 lo hanno visualizzato
  1. Prima ti devo fare una breve digressione su Fourier. La trasformata di fourier prende un segnale e lo scompone in armoniche (sinusoidi) che se sommate tutte assieme ricostruiscono il segnale originario. Quindi per memorizzare e ricostruire il mio segnale non ho bisogno di memorizzarmi i campioni, ma se mi accontento di un segnale approssimato posso memorizzarmi dei valori delle armoniche di Fourier. Una rappresentazione delle armoniche di Fourier ce l'hai in diversi equalizzatori, che mostrano lo spettro del segnale. Lo spettro non è altro che una rappresentazione grafica della trasformata. Se un segnale è a bassa frequenza (varia poco nel tempo) si approssima molto bene con Fourier e con pochi campioni si riesce a ricostrure una cosa che assomiglia molto al segnale di partenza. Ora le armoniche sferiche, queste rappresentano la trasformata di Fourier di un segnale sferico. Ho detto che Fourier serve per scomporre un segnale e facilitarne la memorizzazione. Detto questo, le armoniche sferiche possono essere usate in due modi. -Le utilizzo per memorizzare l'illuminazione globale (l'irradianza) nello spazio. Così anche se muovo qualche oggetto non devo ricalcolare la global illumination ogni volta. Questa tecnica viene usata nei videogame (dove la scena è più o meno statica) e non posso calcolare la global illumination a run-time -Un altro segnale che ci può interessare è l'occlusione. Tu dirai, ma come, per l'occlusione si usa l'ambient occlusion. Vero, ma l'ambient occlusion è soltanto un numero, non ti dice quale direzione è occlusa. In questa maniera si raggiunge un livello di realismo superiore. Purtroppo l'argomento è un po' complicato da trattare, spero di averti "illuminato" un pochetto.
  2. ilmale

    Texture Da Zbrush A Maya

    Quando connetti una texture che contiene un canale alpha maya connette sia il colore sia l'apha. Nell'attribute editor sul materiale basta che clicchi di destro sull'attributo che vuoi disconnettere e appunto fai break connection. Poi farlo anche dall'hyper graph, in tal caso basta selezionare la connessione e premere canc Per connettere due nodi devi trascinarli con il tasto centrale uno sull'altro. Ciao
  3. ilmale

    Texture Da Zbrush A Maya

    Non basta scollegare la trasparenza dalla texture? Dal materiale vai sullo slot trasparenza clicchi di destro e scegli "break connection".
  4. Non so quanto sia di aiuto ma a me funziona bene, ho fatto diverse prove e tutte hanno dato gli stessi valori. Per curiosita', non e' che per caso hai messo l'asse Z come asse UP? (si imposta dalle preferenze, sotto settings). Quella e' una delle cose piu' buggate in assoluto.
  5. ilmale

    Mr 3.8 E Nvidia Gpu

    A chi interessa Le sdk per usare Optix sono disponibili al pubblico http://developer.nvidia.com/object/optix-home.html Per usarle serve o una quadro o una GPU tesla.
  6. ilmale

    Elaborazioni Gp-gpu

    Dipende da come si evolve, altrimenti si rischia di fare la fine di quelli che a fine anni '80dicevano che AMIGA avrebbe dominato il mercato dei computer. In tutto lo scenario avete trascurato DirectX 11 che include i Compute shader. Da una parte c'è nVidia che investe sul calcolo parallelo su GPU. non bisogna trascurare che nVidia ha dalla sua mental ray, quindi penso che nel ambito del 3D cinematografico sentiremo parlare sempre più di nVidia, CUDA e iRay. Da un altra parte abbiamo Microsoft e DirectX11 e la quasi totalità del mercato dei video giochi (a parte ID software e altri temerari) lo useranno per i prossimi videogame, quindi Compute shader avranno una grossa fetta del mercato. openCL... per adesso abbiamo parlato sempre di 3D e calcoli scientifici, ma l'accelerazione hardware può essere usata anche per molte altre cose. Un campo in cui sembra interessante l'uso delle GPU sono i database, se questa cosa si evolve openCL la farà quasi sicuramente da padrone. La situazione per adesso è ancora troppo caotica per fare previsioni e ho la sfera di cristallo dal meccanico.
  7. ilmale

    Elaborazioni Gp-gpu

    Le istruzioni assembler delle schede video nVidia sono le stesse sia se stai usando CUDA, sia se stai usando openCL. Quando la libreria openCL chiede al driver nVidia di compilare il kernel questo usa un metalinguaggio intermedio e poi converte tutto in assembly. Questo linguaggio intermedio dovrebbe essere comune sia a CUDA che openCL. Se ti interessa il metalinguaggio si chiama LLVM, è usato un po' ovunque, per esempio viene usato da apple per compilare l'object C in codice per l'iPhone. Presumo che il procedimento debba essere grosso modo così: La libreria openCL chiede al driver di compilare il programma, questo viene tradotto in LLVM e il compilatore LLVM integrato nel driver lo traduce in codice macchina. Anche CUDA quando deve tradurre il kernel traduce il programma in LLVM, da li in poi il percorso è comune. Cerca nVidia in questa pagina. http://llvm.org/Users.html
  8. ilmale

    Elaborazioni Gp-gpu

    openCL come ti ho detto ha il suo compilatore interno per compilare il kernel e quello non lo puoi cambiare. Poi per produrre programmi che usano openCL puoi usare qualsiasi compilatore (Visual studio, G++, ecc...). Tra le altre cose ancora prima che uscissero le SDK pubbliche di nVidia erano già stati fatti diversi porting verso altri linguaggi (Java, Phyton, Scala, ecc...). Mi sembra di essere ripetitivo, ma la stessa cosa era stata fatta anche per CUDA.
  9. ilmale

    Diagramma Di Voronoi

    Per tutto quello che riguarda la geometria computazionale guarda qua: http://www.cgal.org/ http://www.cgal.org/Manual/last/doc_html/c...apter_main.html Il diagramma di Voronoi è storicamente un problema complesso (di quelli che non si riescono a risolvere sotto o(N^2)), sicuro di volerlo fare in un linguaggio di script? Potrebbe risultare lentissimo, se ti è possibile proverei a scrivere un plug-in.
  10. ilmale

    Elaborazioni Gp-gpu

    No, no, non fraintendiamo, il compilatore rilasciato assieme a CUDA Toolkit è il compilatore che ti serve per scrivere un programmino C che usa CUDA, è utile se non hai visual studio o non vuoi usare il compilatore GNU (che è molto più grosso e completo). Il programma CUDA vero e proprio (il kernel) viene compilato da un compilatore interno alla libreria, funziona ne più ne meno come si compila una shader in openGL. Carichi il codice del sorgente, lo passi alla funzione della libreria che lo compila e questa ritorna un oggetto che puoi eseguire. Stessa cosa fa openCL. In tutto questo pappiello lunghissimo non ho mai detto di essere un grosso fan di CUDA, e penso pure io che andrà a sparire se non verrà implementato almeno in maniera parziale anche su ATI. L'ho scritto nel messaggio che non hai finto di leggere. Anche se penso sia una possibilità molto remota, lo dimostra questo piccolo evento: La gente scopre che mettendo una ATI per la grafica e una GeForce per la fisica si ottengono cose mirabolanti. nVidia disabilita l'accelerazione HW nel caso sia presente una ATI adducendo motivazioni discutibili. Per il discorso della libreria sì, libreria no. Una libreria è un pezzo di codice messo da qualche parte che il tuo programma usa. Con questa definizione ogni pezzo di codice sul computer è una libreria. Il pezzo di codice che un programma usa per usare openGL risiede principalmente nel driver, per questo openGL non viene inteso come una libreria. Il pezzo di codice che linki non fa altro che da ponte per le openGL vere. Ci sono cascato pure io la prima volta, openGL è una "libreria" molto anomala. Da wikipedia: "OpenGL (Open Graphics Library) è una specifica che definisce una API per più linguaggi e per più piattaforme per scrivere applicazioni che producono computer grafica 2D e 3D." Comunque alla fine è soltanto un tecnicismo, chiamala pure libreria se vuoi, il 99% della gente non troverà niente da ridire. CUDA e openCL sono librerie a tutti gli effetti anche se usano pesantemente il driver, ma il discorso è ben diverso. Da wikipedia: "OpenCL (Open Computing Language) è una libreria basata sul linguaggio di programmazione C99" La confusione che stai facendo tra linguaggio/compilatore/libreria ecc.. è che in realtà openCL è una specifica, cioè se tu che produci delle schede e vuoi dire che supportano openCL allora assieme alla tua scheda devi rilasciare una libreria che supporta un set di istruzioni (per caricare dati, compilare il kernel e bla bla bla) e deve compilare un programma secondo determinare regole. Cioè si deve attenere alle specifiche rilasciate da Khronos. Tra le altre cose si paga 10.000$ se vuoi il certificato di Khronos e se vuoi usare il nome openCL. openCL non è una libreria che scarichi, ma un insieme di regole (se vai sul sito della khronos non ci sono librerie, solo un PDF e degli header). Sì puoi scaricare una libreria che ti permette di fare programmi che usano openCL ma non è quello openCL, di librerie simili ne puoi trovare più di una. CUDA non è una specifica, o meglio ha la sua specifica ma è fatta solo da nVidia e un altro anche volendo non può rilasciare una libreria che prende un kernel scritto in CUDA e lo esegue su HW. Ci sarebbero sia ripercussioni legali e poi se vuoi mantenere la compatibilità il tuo HW sarebbe irrimediabilmente legato alle decisioni di nVidia.
  11. ilmale

    Elaborazioni Gp-gpu

    Qui c'è molta confusione, non so dove hai reperito queste informazioni, ma ne avessi azzeccata una. Se è Hardware upgrade ti consiglio di cambiare spacciatore di informazioni. openGL non è una libreria, se pensi che openGL sia opengl32.dll sei molto lontano. Se hai mai scritto un programma in openGL sotto windows noterai che all'inizio devi fare (o usare una libreria che ti fa) un sacco di wglGetProcAddress() per importare le chiamate di funzioni dal driver.. perché? Perché la libreria che link non è altro che un ponte tra l'implementazione openGL di windows e l'implementazione openGl vera e propria è nel driver, quella di openGL32.dll è un implementazione software fatta da Microsoft e ovviamente è lentissima. Sotto linux/OSX devi linkare GL.s ma ugualmente devi usare glXGetProcAddress per ottenere le funzioni dal driver. Poi sotto windows ogni cosa è una libreria pure il driver, ma di suo openGL non è altro che una specifica che il driver implementa. Se openGL fosse una libreria dovresti avere una dll per ogni versione di opengL supportata. Anche openCL è una specifica (tra cui comprende un linguaggio simil C), e quello che la implementa ti da una libreria (e gli header per usarla) per permetterti di accedere alle sue funzionalità. La libreria è composta da un interfaccia che ti permette di caricare dati su un buffer, permetterti di chiamare il compilatore, eseguire il programma (kernel*) openCL compilato e riprendere dati e un compilatore che prende il tuo kernel e lo lo traduce in codice eseguibile dipendente dalla piattaforma di destinazione. Il compilatore viene chiamato OGNI VOLTA che esegui il programma perché il programma che generi non sa su cosa dovrà essere eseguito il kernel. CUDA bada caso funziona nella stessa identica maniera (poi uno dice che sono simili). Non c'è nessun ambiente di sviluppo chiamato CUDA, quello che chiami ambiente di sviluppo è il Cuda Toolkit che comprende un compilatore C, un linker, un debugger e le librerie di cui sopra (che si trovano anche nell'SDK). Infatti io per fare programmi (va be' chiamiamole schifezze di test, che proprio programmi non sono) con CUDA uso Visual studio. Anche le SDK per Cuda ti danno anche loro la loro bella libreria per interfacciarti con il compilatore. Cambieranno i nomi delle funzioni, ma il modo di operare è il solito. C++ non è un ambiente di sviluppo, nemmeno Fortran, sono linguaggi, nient'altro che un insieme di regole semantiche. Tant'è che se scrivi del codice C++ su un foglio di carta rimane C++. Quello che fa il compilatore, linker, assembler e IDE ti fa l'ambiente di sviluppo. Visual studio è un ambiente di sviluppo, il pacchetto GNU Gpp, G++ ecc.. è un ambiente di sviluppo (senza IDE), QtCreator è un ambiente di sviluppo, KDevelop è un ambiente di sviluppo. PhysX è una libreria e openCL non è un ambiente di sviluppo. Su questo non posso far altro che concordare. Mi sono fermato alle prime 5 righe, se dovevo commentare tutto il resto del post facevo notte. Ora spiegatemi una cosa, è da giugno che scrivete e non sapete nemmeno di cosa state parlando? *per chiarire in questo caso kernel è il programma openCL, non ha niente a vedere con il cuore del sistema operativo.
  12. ilmale

    Elaborazioni Gp-gpu

    Ehm.. anche CUDA è una libreria CPU-GPU, se non trova l'acceleratore nVidia CUDA utilizza la CPU cercando di scalare su più core possibile. E per il resto è proprio quello che ho detto io "A parte che una è proprietaria e l'altra no, per il resto sono uguali", se non ti piace uguali, metti molto simili. Francamente non amo i thread in cui due persone dicono la stessa. Ho citato CGFX perché più o meno si sta sviluppando lo stesso scenario. Anche per gli shader infatti c'è uno standard aperto e multipiattaforma che è GLSL, ma GLSL è venuto fuori quando nVidia aveva già fatto il proprio linguaggio (CGFX) iperottimizzato per nVidia e gira così così su ATI. GLSL si è evoluto con le varie release di openGL (che purtroppo si è evoluto solo in quest'ultimo anno) mentre CGFX è stato al passo con le varie release dei driver nVidia. CGFX è stato fortunato, vuoi perché GLSL non era stato sviluppato proprio benissimo o perché è "multipiattaforma" (con 18 virgolette), ma fatto sta che è ancora li ed è molto più usato di GLSL. Per adesso CUDA non è accelerato su ATI (soprattutto perché le GPU ATI per adesso non davano un interfaccia stabile per il GPU computing), se in futuro CUDA supporterà ATI (anche in maniera parziale) allora sopravviverà, altrimenti sarà delegato solo ad un ambito molto ristretto. I problemi con le architettura attuali non sono tanto di potenza di calcolo ma di banda. Si devono mandare solo grandi quantità di dati tutti assieme per essere efficienti. Si vocifera che la strategia generale per il futuro sia quella di accorpare GPU e CPU. Anche se con visioni molto diverse è proprio quello che i progetti Fusion e Larrabee stanno facendo. Larrabee non è soltanto tante CPU x86 una accanto all'altra, quelle ci sono già da tanto tempo ma sono distribuite su più macchine, questo assolutamente non risolve i problemi di banda che ci sono attualmente (e soprattutto un supercomputer da 256 CPU non ha prezzi che un utente normale si può permettere). Larrabee dovrebbe includere molti core x86 all'interno di un unico processore con un livello di cache comune, in pratica sarebbe un ingigantimento dell'architettura CELL di IBM. Su Fusion ne so poco (molto poco, solo sentito dire), ma dovrebbe togliere il bus tra CPU e GPU e accorpare tutto in un unico chip. Anzi se avete informazioni più precise sarei lieto di capirne qualcosina di più.
  13. ilmale

    Elaborazioni Gp-gpu

    Scusa, mi era sfuggito questo tuo ultimo messaggio anche se non ne capisco il senso, forse è tardi. L'affermazione "E chi l'ha negato..." si intende che non neghi che non c'è differenza tra i due, ma subito dopo dici che è palesemente sbagliato. Comunque hai negato l'uguaglianza quando hai detto che il futuro non è CUDA / ATI, ma OCL. entrambe sono librerie di GPU computing, una di nVidia (e ci mette quello che gli pare a loro, compatibile solo con schede nVidia(per questione di test dicono loro)) l'altro di Khronos sviluppata a braccetto dai "big" della grafica. Se non sbaglio il modello evolutivo di openCL è simile a quello di openGL, quindi non ci vedo tutta questa grande differenza, CGFX docet. Se vogliamo proprio parlare di futuro il punterei su Larrabee(anche se il primo demo è stato proprio deludente) e Fusion. Ripeto, forse è tardi, sono stanco e con le triple negazioni ammetto di avere qualche difficoltà, ma quale sarebbe il problema centrale che mi è sfuggito?
  14. A me su CS4 funziona bene però, ricordate anche che i plug-in nVidia sono a 32 bit, quindi funzionano solo con photoshop a 32 e non con quello a 64.
  15. ilmale

    Mr 3.8 E Nvidia Gpu

    Yep, il reality server adesso viaggia su macchine con la GPU fermi e usa IRay. http://www.nvidia.com/object/io_1256065754359.html Per chi non se lo ricorda il reality server è un servizio di rendering online che permette di visualizzare le immagini renderizzate anche su pc poco potenti, il server ha un modello e da remoto si possono cambiare alcuni parametri (posizione camera, proprietà delle luci, materiali, ecc...) e il tutto viene renderizzato ad alta qualità in poco tempo (secondi). Dagon quel demo su che macchina gira? Quello di nVidia girava su un sistema con 13 schede fermi, va bene tutto ma un alimentatore da 3000W dove lo trovo?
×