Link alla notizia: http://www.hwupgrade.it/news/software/disponibile-la-versione-10-di-badaboom-transcoder-via-gpu_26979.html

Elemental Technologies ha rilasciato la versione 1.0 di Badaboom, software per il transcoding video che sfrutta le GPU NVIDIA compatibili con CUDA

Click sul link per visualizzare la notizia.

"Il software non funziona con quelle schede video che non implementano supporto alla tecnologia CUDA, quindi con le soluzioni ATI Radeon."

looooooooooooooooooooooooool
CUDA = NV quindi direi che difficilmente potesse funzionare

Faustinho, quando ci sono dei possibili utonti di mezzo è bene specificare tutto :asd:

Ogni giorno Nvidia ci stupisce per la sua capacità di innovazione. Si tratta indubbiamente di uno strumento molto utile, semplice e a quanto pare molto più veloce delle soluzioni tradizionali. Ottimo direi !

Beh aspettiamo un bachmark :P

badaboom.... chacha? :asd:

battutaccia a parte, finalmente si sfruttano le GPU, era ora :D

dopo che ci siamo fatti tutti il quad, ora nn serve più nemmeno per le conversioni video perchè lo fa la vga? :asd: :asd:

ma driver per driver con supporto CUDA cosa intendono?
qualsiasi versione dei Forceware va bene?

... a me da errore e richiede una scheda G94...ed io ho comunque una 8800gtx... :(

...sob...lo voglio anche per il mio radeone :(

io il quad me lo sono fatto per estrarre i file rar di grandi dimensioni ( chi ha detto Reloaded ? ) :)

Io il quad me lo farei anche, ma poi dove la trovo la sabbia? e poi ci vuole il casco, beve...ma no, ma no...lascia stare

minchia... mi toccherà èassare ad Nvidia... iniziano a farsi interessanti questi sviluppi CUDA... Prima Adobe per la sua nuova "suite"(perchè costa quanto un mese di soggiorno in una suite imperiale "Luis Quatrose" a Parigi vista Notre Dame?... forse di più...:ciapet: ), adesso anche la compressione video... FINALEMENTE! 'sti miolioni di transistori utilizzati anche per altre applicazioni oltre per i giochi!

... a me da errore e richiede una scheda G94...ed io ho comunque una 8800gtx... :(

ah!? rinfrescami la memoria... 8800GTX a 512 quindi G92... giusto? strano...

non vedo tutta novita'... con ati uso il tool avivo converter che fa le stesse cose:D

Un Quad per un rar? Va bene che ognuno spende i propri soldi come vuole...

@bull's eye
Mi dai un aiutino?
Come funzia il tool avivo?
per esempio: io uso dvd shrink, mi puo' essere d'aiuto avivo per ridurre i tempi di "ricodifica"?

ah!? rinfrescami la memoria... 8800GTX a 512 quindi G92... giusto? strano...

No, G80.

@gbyte87
dai era una battuta... il quad mi ci è stato nel pc nuovo... e se devo estrarre un file da 5 o + GB ben venga il quad... qualche minuto me lo fa risparmiare... ma siamo OT...

@Shadowlord
Ah ecco :asd:

Chissà con larrabee come renderanno sti programmini :fagiano:

amd deve comprare la licenza per cuda o proporre un antagonista valido prima che sia tardi. offre troppe possibilità interessanti

Un buon inizio.. non ho chiarissimo cos'è H264.. o meglio, che caratteristiche ha..

Ma si sa qualcosa per la codifica da DVD a divx o xvid via GPU??
Software? Codec appositi??? nulla?? :(

h264 è....mpeg4 :)

edit.

esistono driver craccati che permettono l'uso del Cuda anche con sk Ati della famiglia 3XXX e superiori...

L'AVIVO CONVERTER è SOFTWARE, non sfrutta la GPU. Va leggermente più veloce perchè usa settaggi approssimativi, infatti nessuno lo usa.

Stavo per dirlo anche io :D
La storia di Avivo insegna che i codec video non si giudicano dagli "FPS" ma dagli FPS a parità di qualità. ;)
(magari provando ad impostare anche il codec software in modalità "scrausa", e vedere quanto fa)

Una soluzione per le Radeon dovrebbe uscire entro dicembre da Cyberlink mi sembra.

Aspetto con ansia una rece fatta come diocomanda di badaboom... la versione beta recensita da AnandTech era stata un pò deludente: lamentavano la scarsa flessibilità del programma, e sostanzialmente se si ha un quad-core conviene far fare i conti al procio. Il discorso sarà incentrato sul compromesso CPU vs GPU: invece di prendere un quad, potrei decidere di prendere una GPU più potente.

Queste tecnologie mi intrigano parecchio, ma bisognerà aspettare ancora un bel pò perché il fumo si diradi per poter vedere (e mangiare) l'arrosto.

Maledetti! Non l'ho mica capita sta storia, che devono sempre fare compatibilità ristrette. nVidia ha rotto. :muro:

edit.

Guarda che devi prendertela con ATI.
NVIDIA non solo ha proposto ad ATI di utilizzare la libreria CUDA (fornendogli supporto e strumenti, anche più di quanto fa con gli sviluppatori attuali), ma ha addirittura TIRATO FUORI DEI SOLDI (per persone terze) affinchè ciò succedesse.
ATI non vuole.
Quindi ti attacchi.
Sorry.

Io non mi attacco, dato che non me ne frega niente, di programmi di codifica video. :sofico:
Solo non ritenevo giusta la politica di nVidia... Però, se mi dici queste cose, mi fido. :stordita:

h264 è....mpeg4 :)

mi sa che hai le idee confuse!
h264 e mpeg4 sono differenti!
h264 è diciamo il figlio evoluto del divx o mpeg4 condito in salsa hd.
Da vari benchmark trovati in giro h264 ha un rapporto di compressione molto simile al dvix ma garantisce una qualità migliore.
http://www.programmazione.it/index.php?entity=eitem&idItem=40347
Per ora il h264 rimane più pesante da codificare e decodificare per questo motivo è ancora abbastanza ridotto nel p2p oltre che ad una ignoranza sul formato.

Guarda che devi prendertela con ATI.
NVIDIA non solo ha proposto ad ATI di utilizzare la libreria CUDA (fornendogli supporto e strumenti, anche più di quanto fa con gli sviluppatori attuali), ma ha addirittura TIRATO FUORI DEI SOLDI (per persone terze) affinchè ciò succedesse.
E' basta co 'sta storia!!!! Solo un ingenuo può credere che nVidia abbia veramente "offerto" CUDA ad ATI. (veramente nel senso "aspettandosi che ATI potesse veramente usarla" )

Chiedi pure su beyond3d se non ti fidi di me. ;)
(o cerca tra le discussioni fatte)

Se nVidia avesse voluto fare uno standard, avrebbe proposto uno standard.
Fortunatamente lo standard ci sarà e nVidia sarà costretta ad aderirvi (l'OpenCL di Apple in uscita su snow leopard, e le Directx11 di MS).

Anche perché hanno solo un paio d'anni di tempo scarsi prima che il Lupo mangi entrambi.

edit.

Convertito Vob da 730mb in un mp4 320*240 ottimo in 4 minuti e 44 sec con 8800gt..
niente male sto programmino..
ciao

Convertito Vob da 730mb in un mp4 320*240 ottimo in 4 minuti e 44 sec con 8800gt..
niente male sto programmino..
ciao
esiste un'alternativa ATI ?

Si vede l'hanno implementata da qualche versione, chessò, i 175.xx, oppure i 172.xx, te scarica l'ultima, no? Dove è il problema

pensavo ci fossero driver a parte per solo il CUDA, invece i driver che avevo installato andavano bene.

cmq ho provato la versione trial..niente di che.
ha 2 impostazioni in croce, non apre nemmeno i file in mpeg4, non prende il matroska...
però c'è da dire che almeno ha l'interfaccia intuitiva a prova di utonto.

diciamo che i 30euro non li vale per quello che riesce a fare.

esiste un'alternativa ATI ?

per ora, no.

1.
Non mi è necessario reperire informazioni sul forum di Beyond3D (che pullula, come qua, di destristi, sinistristri, e aihmè, pochi centristri).
Ma anche di molti professionisti, e vedrai che su questa storia nessuno di loro discorda, verdi rossi o blu che siano.
Eppoì dai, anche i professionisti possono simpatizzare ma rimangono pur sempre professionisti più che fanboy, e certo vale la pena leggerli.


2.
CUDA, stringi stringi, utilizza C+. Se non è standard questo.

Michelezz, chiedi a qualsiasi programmatore CUDA, come gli sembra il legame tra CUDA e l'hardware. Quale potrebbe essere stata la proposta di nVidia?

"Vi va bene se supportate un API che decidiamo noi quando ci pare e vi diciamo all'ultimo minuto/quando ci pare, per cui voi dovete modificare il vostro hardware per farla andare in maniera decente?"
(come se si potesse modificare l'hardware all'ultimo minuto)

Ma ti pare una cosa minimamente accettabile? Per renderla tale, nVidia avrebbe dovuto costruire un organo di definizione di uno standard indipendente, in grado di decidere collegialmente le API con mesi o anni di anticipo. Proprio come OpenCL, OpenGL, e DirectX, guarda un pò.

(le directx non sono un tipico "standard" e vengono decise in maniera guidata da MS, ma comunque è un organo terzo, sente i produttori di GPU, e dà le specifiche con mesi/anni di anticipo)


3.
Le DirectX11 sono rivolte ai giochi. Accelerare Folding@Home con le DirectX? Forse un giorno, ma non con le 11.

Anche Windows avrà una sua piattaforma standard per il GPGPU. Ora MS sta pubblicizzando i "compute shader" delle Directx11, vedi news riguardanti Windows 7 che sono uscite e usciranno nei prossimi giorni. A detta di MS, i compute shader delle DX11 servono a quello che dici.

Io spero comunque che sbarcherà anche OpenCL su win: non c'è nessun motivo per cui non dovrebbe, fuorché politico da parte di MS o nVidia.


4.
NVIDIA è dentro anche OpenCL.
Vedrai che se Apple ha montato su TUTTI i suoi nuovi MacBook GPU NVIDIA e supporta OpenCL c'è un perchè.

Chi ha detto di no :D ? Ovvio che nVidia è dentro OpenCL, come lo sarà per le Directx11, e lo sarà anche AMD.

Difatti, ecco qui i nostri standard per il GPGPU ;)

Per costare 30€ fa davvero poco a livello di scelta input e output;
potrebbe trarne beneficio chi ha un lettore mp4 di sony o apple da riempire di video e ha fretta, chi parte da un avchd o da HDV deve passare attraverso software di editing.
Chi parlava di dvd shrink sappia che questo software non gli torna utile.

Un buon inizio.. non ho chiarissimo cos'è H264.. o meglio, che caratteristiche ha..

Ma si sa qualcosa per la codifica da DVD a divx o xvid via GPU??
Software? Codec appositi??? nulla?? :(

Ciao,
come detto da altri un codec h264 (o mpeg4) è lo standard che vedremo nei prossimi anni nella compressione dei video (al posto dei vari divx e mpeg2).
Non bisogna confondere il file "container" (che puo' essere AVI, MOV o MP4 per esempio) dal codec utilizzato al suo interno.
Tutti i video "di ultima generazione" sono codificati in H264, dai BD (se non sbaglio) ai video dell'ipod o il cellulare. Anche youTube e' passato recentemente alla compressione h264 perche' a parita' di banda il dettaglio sale notevolmente.
Anche i filmati per iPod e PSP utilizzano questa codifica. L'unico problema e' che in compressione e' difficile superare i 10fps, quindi ci si mette (se va bene) due volte e mezzo la durata del filmato per comprimere il tutto.

Teoricamente questa soluzione abbassa i tempi di attesa, non l'ho ancora provato ma siamo ancora agli inizi, non mi stupirei se il risultato fosse "acerbo". Anche perche' le variabili disponibili con h264 sono centinaia e mettere a punto un'applicazione che le implementi tutte non credo sia cosi' immediato.

si ma spendere 30€ per mettere filmati nei lettori mp4 è assurdo,stante le decine di software free che ci sono

edit.

ma driver per driver con supporto CUDA cosa intendono?
qualsiasi versione dei Forceware va bene?
da questi in poi: v178.24
http://www.nvidia.it/content/forcewithin/it/download.asp
C'è anche la trial di BadaBoom lì

Ogni giorno Nvidia ci stupisce per la sua capacità di innovazione. Si tratta indubbiamente di uno strumento molto utile, semplice e a quanto pare molto più veloce delle soluzioni tradizionali. Ottimo direi !

Falso, nvidia non stupisce, semplicemente l'han programmato in CUDA e non in CAL :O

A parte i vari campanilismi ati-nvidia, io il prog l'ho provato, e sinceramente non lo userei neanche se fosse free :muro:

Scelta dei formati limitata, configurazione del codec e delle opzioni praticamente assente, e dopo tutto questo, aprendo un qualsiasi VOB per provarlo mi crasha senza pietà.... bel tentativo, ma almeno per come funziona sul mio pc, per me questa è poco più che una pre-alpha.

Capisco il tuo punto, ritieni che CUDA verrà eventualmente sopravanzato da OpenCL e DirectX. Probabile. Può anche darsi NVIDIA lo usi solo come scialuppa in attesa del OpenCL.
Il problema è proprio aspettare questi standard, prima che arrivino, poi che acquistino mercato (e vedi te il Wi-Fi n quanto ci sta mettendo per esser ratificato), mentre CUDA è subito disponibile. Per chiunque, e con svariati esempi, in modo da non sentirsi spaesati.
Il vantaggio è semplicemente questo. Poi il futuro, chissà.
Ehi, io stavo solo rispondendo al fatto "AMD ha rifiutato CUDA" dicendo che le cose erano appena più complesse. ;)

Sul resto si avrà certo modo di chiaccherare anche in futuro.

A parte i vari campanilismi ati-nvidia, io il prog l'ho provato, e sinceramente non lo userei neanche se fosse free :muro:

Scelta dei formati limitata, configurazione del codec e delle opzioni praticamente assente, e dopo tutto questo, aprendo un qualsiasi VOB per provarlo mi crasha senza pietà.... bel tentativo, ma almeno per come funziona sul mio pc, per me questa è poco più che una pre-alpha.

Non è che per caso state usando la versione Beta 0.9?

Perché allora fareste meglio ad installare la versione definitiva invece di lamentarvi...

2.
CUDA, stringi stringi, utilizza C+. Se non è standard questo.


il fatto che CUDA utilizzi C non significa che CUDA rappresenti o costituisca uno standard. Allora qualunque interfaccia utilizzi C è ugualmente standard?



3.
Le DirectX11 sono rivolte ai giochi. Accelerare Folding@Home con le DirectX? Forse un giorno, ma non con le 11.


le DX11 prevedono anche il GPGPU




4.
NVIDIA è dentro anche OpenCL.
Vedrai che se Apple ha montato su TUTTI i suoi nuovi MacBook GPU NVIDIA e supporta OpenCL c'è un perchè.



come tanti altri, tra cui AMD



5.
Il Lupo perde il pelo ma non il vizio (?!).
A parte cazzate, il Lupo usa una derivazione x86 basata su approccio MIMD, l'acquisizione di Havok fa intendere che la sua strada sia quella...
In ogni caso è più vicina all'architettura NVIDIA che non a quella ATI (che è una SIMD).
In 2 anni mangia tutti? Sono 9 anni che Intel è dentro il settore GPU, e guarda tu stesso i risultati.

interessanti conclusioni; suffragate da..........................? :D

mmm l'ho provato e come software mi sembra parecchio indietro rispetto ad altre soluzioni già presenti sul mercato

Non passa settimana in cui su hw non compare un articolo ke riguarda CUDA. Devo dire ke nVidia ha perso il vantaggio su Ati per quanto riguarda le prestazioni pure, ma si è assicurata una fetta di mercato anke tra ki non è solo giocatore grazie a CUDA.

io il quad me lo sono fatto per estrarre i file rar di grandi dimensioni ( chi ha detto Reloaded ? ) :)


Mi pare giusto, una spesa oculata prima di tutto! :)

Mi sbaglio o c'era giá una robba del genere sulle ATI x1800 o qualcosa cosi? Se non sbaglio c'era il AVIVO encoder messo a disposizione da ATI che utilizava le GPU per fare l'encoding.

edit.

Per dovere di cronaca vi comunico che prima Folding@home era programmato in DirectX...si, andava sulle directx... le 9 forse... si, roba scientifica elaborata grazie a quelle DX

Non ho detto che il CUDA sia standard. CUDA usa il C+, che è standard (un pregio rispetto al CTM usato da ATI).
E' diverso, non travisare per creare zizzania.


non sono io a travisare, sei tu a non essere informato: ATi usa sia il C (come nVIDIA) con brooks e brooks+, che l'assembly (CAL che è l'evoluzione di CTM).
Tramite CAL hai un controllo di molti parametri della GPU che con un linguaggio ad alto livello non hai. E comunque, il fatto di usare C o C++ non fa automaticamente di un algoritmo o di un tool uno standard.


Le DX11 prevedono i "Compute Shader" che nelle intenzioni di Microsoft sono ideati per eventuali calcoli di fisica e per accelerare post-processing di Bloom e HDR. Altro? Per ulteriori commenti dovremo aspettare anche maggiori informazioni a riguardo.


altro. Ci sono state diverse presentazioni sulle funzionalità dei compute shader, in varie manifestazioni, tra cui il siggraph 2008. Non sono un oggetto misterioso :D
Comunque le dx11 prevedono un'architettura ed un'organizzazione dei registri e delle alu che farà somigliare sempre più le gpu a processori di tipo GP.



Certamente un approccio GPGPU tramite CUDA o similari avrà comunque una flessibilità e un potenziale esprimibile maggiore (lo vediamo anche con il recente CS4, capace di utilizzare OpenGL per l'accelerazione dello zoom delle immagini - non serve aspettare le DirectX11 per usare la GPU per i calcoli tramite API DirectX o OpenGL - mentre per i calcoli più gravosi Adobe ha deciso di appoggiarsi a CUDA).

infatti il gpgpu è nato molto prima di CUDA e ancora prima delle DX11. Tanto che le dx11 e i compute shader promettono, stando a quello che sostiene MS, di costituire una piattaforma utile per approcci standard o proprietari e in grado di lavorare su differenti architetture (sia cpu che gpu). Questo perchè non esiste un solo approccio o un approccio privilegiato al gpgpu. Almeno per ora :D



Architettura dei calcolatori?


ovvero? GT200 è MIMD? RV770 è SIMD? Oppure? E larrabee?

Un'ultima precisazione. Contrariamente a quanto si sostiene, anche havok consente l'eccelerazione tramite gpu e non presenta un approccio cpu only (giusto perchè si è toccato l'argomento gpgpu). Prima che havok fosse acquisito da intel, anche nVIDIA utilizzava le sue librerie per l'accelerazione fisica tramite gpu (ad esempio su G70)

Ciao,
come detto da altri un codec h264 (o mpeg4) è lo standard che vedremo nei prossimi anni nella compressione dei video (al posto dei vari divx e mpeg2).
Non bisogna confondere il file "container" (che puo' essere AVI, MOV o MP4 per esempio) dal codec utilizzato al suo interno.
Tutti i video "di ultima generazione" sono codificati in H264, dai BD (se non sbaglio) ai video dell'ipod o il cellulare. Anche youTube e' passato recentemente alla compressione h264 perche' a parita' di banda il dettaglio sale notevolmente.
Anche i filmati per iPod e PSP utilizzano questa codifica. L'unico problema e' che in compressione e' difficile superare i 10fps, quindi ci si mette (se va bene) due volte e mezzo la durata del filmato per comprimere il tutto.

Teoricamente questa soluzione abbassa i tempi di attesa, non l'ho ancora provato ma siamo ancora agli inizi, non mi stupirei se il risultato fosse "acerbo". Anche perche' le variabili disponibili con h264 sono centinaia e mettere a punto un'applicazione che le implementi tutte non credo sia cosi' immediato.

:eek: Apperò.. ero rimasto un po' indietro in materia... grazie mille per le info!!
Quindi tra un po' cominciare a pensare di codificare i dvd in H264 e abbandonare Divx è una buona idea?
Aspettando magari una maturazione del software e dei codec anche per lo sfruttamento della GPU...

Ma questo codec è Free? Esiste una versione utilizzabile su virtualdub?
..mmm.. devo aggiornarmi!!

per passare all'H264 bisogna poi prendere anche un lettore stand alone compatibile;
di software di conversione x264 c ne sono diversi,molti free
http://forum.doom9.org/forumdisplay.php?f=77

per passare all'H264 bisogna poi prendere anche un lettore stand alone compatibile;
di software di conversione x264 c ne sono diversi,molti free
http://forum.doom9.org/forumdisplay.php?f=77

ma intendi lettore da salotto?
Se si poco male xchè alla tv ci ho attaccato un bel muletto!
Ci pensa lui a fare il media player!! :D

Per il software devo vedere un po' con calma.. ora mi trovo bene con virtualdub perchè mi permette di fare il cropping dell'immagine.. se cambio devo trovare un software che mi consenta di fare altrettanto..

ma intendi lettore da salotto?
Se si poco male xchè alla tv ci ho attaccato un bel muletto!
Ci pensa lui a fare il media player!! :D
beh in questo caso ok

Per dovere di cronaca vi comunico che prima Folding@home era programmato in DirectX...si, andava sulle directx... le 9 forse... si, roba scientifica elaborata grazie a quelle DX
Non è affatto sorprendente: i primi esperimenti di GPGPU, anche accademici con pubblicazioni e tutto, o come F@H, si facevano - e si fanno tuttora - con API grafiche come le OpenGL.

Basta cercare gpgpu opengl su google e si trova un sacco di roba.

Il discorso sta tutto nella semplicità della programmazione e dalla quantità delle possibilità dell'hardware che le API riescono ad esporre: in questo senso CUDA e brook sono passi avanti.

Io non ho la minima idea se le DirectX11 saranno sufficienti come piattaforma di sviluppo completa per il GPGPU su Windows. Ma francamente poco importa: potrebbero essere "complete abbastanza" per la maggior parte delle applicazioni consumer, e in ogni caso su win arriverà anche OpenCL.

edit.

GPGPU COMPUTING

E' davvero come qualcuno afferma, che le attuali GPU AT* vanno meglio, o comunque non peggio, di quelle NVID*A?
Magari imbambolati da quei "800 PROCESSORI" e "1000GFLOPs"?
Temo proprio di no.

A me piace parlare di cose VERE, di cose REALI, di ciò che è TANGIBILE. Non mi piacciono gli sproloqui tecnici, fini a se stessi (certo, a volte sono necessari).
Ovvero, guardiamo il risultato e decidiamo.

Così, un po' per gioco, un po' per fare informazione, ho cercato qualche applicazione che riguardasse questo GPGPU COMPUTING (cioè l'utilizzo della GPU per fare calcoli al posto della CPU), ma che fosse affidabile, super-partes, famosa, multipiattaforma, ed i cui dati fossero ripetibili da chiunque (sì: anche dal fornaio sotto casa!).

Impossibile? No, l'ho trovata in FOLDING@HOME (http://folding.stanford.edu/), un client creato dall'Università di Stanford che permette di sfruttare le risorse della nostra macchina per analizzare la struttura delle proteine, con l'unico scopo di trovare possibili cure per i morbi di Alzheimer, Huntington, Parkinson, e non solo.
Lodevole.
Dal 2000 ha fatto notevoli progressi, prima supportando le AT*, poi la PS3, ed infine le NVID*A.

Il termine di paragone è dato dalle PPD (Points Per Day), cioè la qualità e la quantità di proteine che riescono ad esser analizzate per giorno. Più il sistema è capace, più alto sarà quel valore.


PS3 : 650 ~ 1000
HD2600XT : 900 ~ 1150
HD3850 : 1400 ~ 2200
8600GT : 1700 ~ 2000
HD4850 : 1700 ~ 2300
HD3870 : 1800 ~ 2500
HD4870 : 2000 ~ 2500
Q6600 : 3000 ~ 3100
9600GT : 3700 ~ 4000
8800GT : 4500 ~ 4900
9800GTX : 5600 ~ 6200
GTX260 : 5700 ~ 6600
GTX280 : 6700 ~ 7200


Come si può vedere, il colore VERDE domina la classifica.

Nota: Dato molto dipende dal tipo di proteina, dal sottosistema, e dall'occupazione di risorse, vengono riportati i valori minimi e massimi, per un confronto ancora più accurato.

Se qualcuno vuole approfondire, o anche solo verificare la veridicità, IO (a differenza di altri) fornisco tutte le fonti:
[size=1]Folding@home - NVD (http://foldingforum.org/viewtopic.php?f=43&t=3193)
Folding@home - ATI (http://foldingforum.org/viewtopic.php?f=51&t=4263)
PCGamesHardware (http://www.pcgameshardware.com/aid,648270/Reviews/Folding@Home_on_Nvidia_GPUs_PCGH_benchmarks/)
FahMon (http://www.fahmon.net/)
Overclock.net (http://www.overclock.net/overclock-net-folding-home-team/355545-f-h-amd-intel-ati-nvidia.html)
Anandtech (http://forums.anandtech.com/messageview.aspx?catid=39&threadid=2215500&enterthread=y)

poichè ho fatto un post doppio, lo utilizzo per chiarire, a beneficio di chi leggesse queste pagine, qualcosa riguardo l'architetutra di RV770 e G80/GT200. Lo faccio in un post separato eprchè non si perda nel lungo replay ad un altro post altrettanto lungo quanto inutile perchè non dimostraniente ma, al contrario, genera solo confusione.

G80 non ha un'architettura MIMD e R600 non ha un'architettura SIMD VLIW VECT5.
Partiamo dalla prima
L'architettura di G80/GT200, semplificando al massimo, ha uno schema logico a due livelli: è una MIMD di cluster di alu SIMD. In G80, ogni cluster è formato da due semicluster di 8 alu MADD fp32 ciascuna; su ogni gruppo di 8 alu gira la stessa istruzione ad ogni ciclo. Questo fa si che ogni gruppo di 8 alu abbia un'architettura di tipo SIMD. Le 16 alu di ogni cluster condividono un pool di registri, una global constant cache ed una texture cache. L'accoppiata dispatch processor-scheduler si occupa del bilanciamento dei carichi di lavoro e della parallelizzazione delle operazioni.

R600/RV670/RV770 hanno un'architettura a 3 livelli: è una MIMD con cluster di tipo SIMD e con alu VLIW (il vect5 non esiste, se non nella fantasia di qualcuno).
Il principio di funzionamento non è dissimile da quello di G80, con la differenza che non c'è lo scheduler (le operazioni di scheduling e, quindi, la parallelizzazione, sono affidate al compilatore), ma c'è il thread dispatch processor, che si occupa di bilanciare i carichi di lavoro tra le alu. quindi, il bilanciamento dei carichi di lavoro è fatto in automatico dal chip tra le 160 alu vliw (per comodità mi riferisco a RV770). Il compilatore deve cercare, all'interno dello shader, il maggior numero possibile di istruzioni indipendenti facenti parte dello stesso thread, da inviare ad una singola alu. Le alu sono vliw sono, nel caso dei chip ATi, da 5 minialu (che di fatto sono alu e chiamo mini solo per dofferenziarle) capaci ciascuna di una MADD fp32 (esattamente come ogni singola alu dei chip nVIDIA; quindi gli sproloqui su pizze e pizzette sono del tutto fuori luogo) :D

ci hai messo tutta una giornata per trovare su wikipedia queste 4 nozioni, per altro neppure corrette? :D

Non è corretto verso chi legge cercare di portare ragione dalla propria parte grandemente esagerando la realtà dei fatti; e non preoccuparti che sono sufficientemente informato.
Emblematico è il fatto che, cercando "Brooks ATI" con Google, si viene indirizzati sul tuo reply (non è propriamente una feature chiaccheratissima... diciamo, il meglio del peggio?).


impara a fare le ricerche allora :D

http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=92531&enterthread=y

http://forums.amd.com/forum/messageview.cfm?catid=328&threadid=93635

http://ati.amd.com/technology/streamcomputing/sdkdwnld.html

http://forum.beyond3d.com/archive/index.php/t-41294.html

http://www.gpgpu.org/forums/viewtopic.php?p=21059

questi sono i primi link che si trovano facendo una ricerca con criteri corretti. :D


Il fatto inoltre che ATI abbia utilizzato prima CTM, che poi è andato evolvendosi in CAL (che poi sarebbe semplicemente un CTM v.2), non è esattamente per dare un beneficio ai programmatori, ma per colpa della stessa architettura delle sue schede video - e ne parlerò, per chi interessa, più avanti.


aggiungi pure che CTM e CAL sono antecedenti a CUDA e che CUDA non gira su G70 e precedenti; per completezza di informazione. :D


Questa affermazione è fastidiosa perchè lascia intendere una ironia di fondo assolutamente non necessaria, e perdipiù non corroborata da fatti: fino ad ora a riguardo dei Compute Shaders si è detto ben poco, e solamente in via teorica. Il prossimo appuntamento è a Novembre. Quindi, o sei uno sviluppatore Microsoft, o viaggi nel tempo, o dovremo proprio aspettare per sapere (e dire) di più.


nessuna ironia: anche qui, basta cercare in maniera corretta.



In realtà l'approccio privilegiato esiste. API come le DirectX e OpenGL sono volutamente molto generiche in modo da poter abbracciare il maggior numero di acceleratori video. Soluzioni come il CUDA permettono di operare con un livello di profondità maggiore, spremendo al meglio l'hardware (e, nel caso di NVIDIA, mantenendo anche una ottima compatibilità fra diverse architetture).
Invece, soluzioni come il CTM di ATI, prettamente da un lato prestazionale sarebbero anche meglio, ma hanno pesanti trade-off (che ne hanno limitato fino ad ora l'uso, ed addirittura le stesse prestazioni) quali il fatto necessitino di un buon studio dell'architettura su cui si andrà ad operare, di un linguaggio adeguato ad ogni differente architettura, e, chiaramente, conoscenze di Assembly (tali programmatori sono merce rara), piuttosto che di C.


infatti ATi ha adottato brooks e ha progettato brooks+ come interfaccia tra CAL e le gpu; così i programmatori hanno uno strumento di basso livello che, in caso di buona conoscenza dell'architettura, permette cose che uno di alto livello non potrebbe mai permettere; ed hanno un linguaggio ad alto livello (C come CUDA) per chi non conosce l'architettura o la conosce solo superficialmente.



L'architettura ATI, come a taluni piace sempre ricordare, è una V.L.I.W. S.I.M.D. VEC5, mentre al contrario NVIDIA adotta una TRADIZIONALE M.I.M.D.


Taluni chi? Comunque, questo è già sufficiente! :D ATi adotterebbe una vliw simd vect5? E nVIDIA una mimd? Ora che hai fatto la semplificazione dei pani e la complicazione dei pesci, prova a chiarirti le idee rispondendo a qualche semplice domanda.
Quali sarebbero le alu vect5 di ATi? E le unità vliw? E la componente simd? R600 e derivati, secondo te, sono in grado di autobilanciare i carichi di lavoro? E i chip nVIDIA sono dei semplici mimd? Prova a spiegarcene il funzionamento, partendo dal thread dispatch processor fino ad arrivare alle alu (magari ti rendi conto, parlandone, che hai detto stupidaggini).


VLIW è usata dalle CPU ITANIUM di INTEL (se non ne avete mai sentito parlare, non me ne stupisco);
TRADIZIONALE è quella delle CPU CORE 2 DUO, ATHLON64, OPTERON, eccetera.

La differenza è tutta in questo disegno:

http://img82.imageshack.us/img82/3563/502pxcpuvliwetradizionakd8.png

Ai ai, dove è finito lo Scheduler? :,(


per quanto riguarda Intel, l'architettura di Itanium è IA64 (l'unica nativa a 64 bit, per altro) e sarebbe più corretto definirla EPIC; quella delle altre cpu da te citate è IA32 e derivati
le operazioni di scheduling avvengono in compile time invece che in runtime. E allora? Dov'è il problema? Forse ce lo spieghi dopo................



Inoltre,

SIMD è la filosofia delle estensioni SSE e ALTIVEC delle CPU;
MIMD è la filosofia del MULTICORE delle CPU;
SISD è la struttura delle odierne CPU (adeguatamente modificata).


..............no; qui non c'è ancora niente; forse dopo.............................


Facciamo degli esempi anche per chi non è addetto ai lavori.

(ATI)
Con un’architettura di tipo VLIW uno sviluppatore deve scervellarsi per trovare un modo di infornare le 800 pizze/focaccinette (i Processors) nei 160 forni, e il VEC5 lo costringe all'aggravio di fare attenzione a mettere la pizza in fondo e le focaccinette davanti, pena l'abbrustolimento.
Se un giorno cambiasse pizzeria (GPU), dovrebbe ricalcolare tutto daccapo, secondo la conformazione della nuova cucina e della quantità di pizze/focacce da infornare.

(NVIDIA)
Con un’architettura TRADIZIONALE lo sviluppatore si limita a entrare in pizzeria ed ordinare le pizze dal pizzaiolo (lo Scheduler), che si premunirà anche di infornarle (a differenza di ATI, NVIDIA ha solo le più gustose pizze, niente focaccinette).
Anche cambiando pizzeria (GPU), non dovremo modificare nulla della nostra richiesta, che sarà la stessa "fammi TOT pizze".
C’è solo da stipendiare il pizzaiolo e dotarlo di carta e penna dove scrivere l’ordine (Latency e Transistor Count).


........niente neppure qui
adesso che hai ordinato la cena e non sei a stomaco vuoto, cerca di fare un esempio reale e possibilmente che abbia un minimo di attinenza a cose concrete (hai presente thread, istruzioni, operazioni, alu, registri temporanei e costanti, texture, rop's, MSAA, branching, tutte quelle cose noiose ed inutili quando si va dal pizzicagnolo ma che possono servire quando si progettano o programmano chip) e che non seguano le tue fantasie


Ora non so quanti di voi abbiano esperienza su ITANIUM di INTEL, ma riassumendo moltissimo (scontentando anche qualcuno, che avrà da ridire) potrei dire che è ormai un progetto fallito, che ha ceduto il passo proprio ai MIMD TRADIZIONALI, e proprio in virtù della difficoltà sia per gli sviluppatori di programmare codice ottimizzato, sia per INTEL di fornire uno strumento di lavoro (compilatore) adeguato.

Per questo, se non ci è riuscita INTEL dopo ANNI, non vedo come possa farcela ATI.


1) itanium è un proggetto tutt'altro che fallito
http://news.cnet.com/8301-10784_3-9947093-7.html
2) larrabee avrà 16 o più core, ciascuno con 16 alu scalari e ciascuno in grado di operare su 4 thread per ciclo. Ti dice niente ciò? Da come parli di mimd, simd e vliw non credo. Facciamo un'ulteriore passo:
3) in larrabee il compilatore avrà un'importanza almeno pari di quella che ha in RV770, anzi, con molta probabilità, dovrà sobbarcarsi un carico di lavoro ancora superiore
Continua a non dirti niente? A detta di Intel: TASK SCHEDULING IS PERFORMED ENTIRELY WITH SOFTWARE IN LARRABEE (ops, lo scheduling interamente via SW: dov'è finito lo scheduler?). Inoltre scopriamo che larrabee non farà neppure uso di fixed function, tranne che per le operazioni di texturing (immagino saprai cosa comporta per le operazioni di scheduling, vero?). Alla intel sostengono che uno scheduler HW sia poco flessibile (e quindi non puoi cambiare menu, ovvero DX); è evidente che alla intel si sono bevuti il cervello. Ma cosa è larrabee? Niente scheduler, quindi secondo MiKeLeZz, larrabee ha un'architettura vliw. Interssante conclusione: però è anche MIMD, come GT200 e G80 (ti cito testualmente); ed ha una 16-way vector alu secondo Intel. Ora che ne sappiamo meno di prima, concludiamo dicendo che............
4)................. larrabee avrà persino un ring bus che connetterà i singoli core (quelli che si possono definire, a tutti gli effetti, stream processor). Alla Intel sono veramente fuori di testa. :sofico:
http://www.multicoreinfo.com/research/papers/2008/siggraph08-larrabee_manycore.pdf



Non mi pare neppure che l'architettura SIMD possa esser ritenuta superiore, se non nella carta (un’altra famosa citazione dice: “C’è vero progresso solo quando i vantaggi di una nuova tecnologia diventano per tutti”).
Infatti, in un mondo così sempre in aggiornamento come quello delle VGA, avere la necessità di compilare per la specifica architettura, perdi più nel complicato linguaggio macchina (o pseudo-tale), è una bella palla al piede.
Come se non bastasse, la stessa INTEL sta sviluppando per il 2009 una sua VGA discreta, LARRABEE (e qui ti rispondo), che è un perfetto esempio di TRADIZIONALE MIMD, e che ci conferma quale sia la visione INTEL per il futuro.


chiarisciti le idee su simd, mimd, vliw e larrabee prima; poi ne riparliamo; qui c'è solo una gran confusione. E già che ci sei, come definisci un'architettura del tipo di quella, diciamo, di G70? (lo so che è una domanda da carogna, ma te la meriti) :D



NVIDIA è attualmente al lavoro sulle sue prossime architetture per fornire anche lei una MIMD quanto più TRADIZIONALE possibile, e con pieno supporto alla programmabilità.



per la gioia di noi utenti che le dobbiamo eterna riconoscenza e gratitudine :sofico:
A proposito, da chi viene questa informazione? Da Kirk o da Harris? :D
p.s. cosa vuol dire TRADIZIONALE? MIMD? sei fuori strada per due motivi: tradizionale non è gergo tecnico; mimd viene prima di simd solo in ordine alfabetico (non certo temporale)


Se mi seguite, potrò darvi anche dei dati a suffragio di tutto ciò.

ADDENDUM

Se siete svegli avrete capito come mai questa divergenza, le analogie non le ho scritte a caso.
ATI/AMD ha tutto l’interesse a creare una architettura SIMD (simile alle SSE), poiché una architettura MIMD ce l’ha già (PHENOM), con 8 core all’orizzonte.
ATI/AMD ha tutto l’interesse per raggiungere buone prestazioni (neppure ottime) con dimensioni sempre più contenute del chip, non perché crede nel CrossFire (che morirà), ma per poter integrare il core grafico nelle CPU, come loro estensione.


peccato che l'ambito di applicazione ed i paradigmi di programmazione di cpu e gpu siano ancora molto differenti tra loro. Peccato che il xfire è ben lungi dal morire, visto che si stanno sviluppando architetture multicore (lo fa anche Intel con larrabee, lo sai? Sai cos'è il progetto terascale computing?); ovviamente non mi dilungo sulla differenza di approccio tra un'architettura multicore con più core fisici e una multicore con più core logici. Invece ci sono voci insistenti sul probabile abbandono dello sli; chissà come mai: forse perchè non è possibile con chipponi enormi :Prrr:



Al contrario, NVIDIA ha tutto l’interesse a creare dei chip enormi


soprattutto interessi economici, direi :D



che rivaleggino i QUAD-CORE INTEL, con unità di calcolo sempre più avanzate, proprio per riuscire ad offrire un PROCESSORE, e non solo una VGA (nei suoi più rosei piani, anche un possibile debutto nel x86).
Il perché INTEL spinga sul MULTICORE x86 non necessita spiegazioni (dico solo che il suo settore relativo alle CPU ARM lo ha venduto).



nei sogni più rosei di nVIDIA o nei tuoi? A proposito, non ha venduto il "fallito" settore itanium. Che scriteriati :fagiano:



Fonti:
InsideHPC (http://insidehpc.com/2006/11/14/what-is-the-difference-between-amds-stream-processor-and-nvidias-geforce-8800-or-is-crays-strategy-the-right-one-after-all/)


--------------------------------------------------

2.
GPGPU COMPUTING
CUDA

E' davvero come qualcuno afferma, che le attuali GPU ATI vanno meglio, o comunque non peggio, di quelle NVIDIA?
Magari imbambolati da quei "800 PROCESSORI" e "1000GFLOPs" che ho riportato nella tabella di cui sopra?
Temo proprio di no.

A me piace parlare di cose VERE, di cose REALI, di ciò che è TANGIBILE. Non mi piacciono gli sproloqui tecnici, fini a se stessi (certo, a volte sono necessari).


meglio sproloquiare di pizze e pizzette: quelle almeno se magnano :D



Così, un po' per gioco, un po' per fare informazione, ho cercato qualche applicazione che riguardasse questo GPGPU COMPUTING (cioè l'utilizzo della GPU per fare calcoli al posto della CPU), ma che fosse affidabile, super-partes, famosa, multipiattaforma, ed i cui dati fossero ripetibili da chiunque (sì: anche dal fornaio sotto casa!).

Impossibile? No, l'ho trovata in FOLDING@HOME (http://folding.stanford.edu/), un client creato dall'Università di Stanford che permette di sfruttare le risorse della nostra macchina per analizzare la struttura delle proteine, con l'unico scopo di trovare possibili cure per i morbi di Alzheimer, Huntington, Parkinson, e non solo.
Lodevole.
Dal 2000 ha fatto notevoli progressi, prima supportando le ATI, poi la PS3, ed infine le NVIDIA.

Il termine di paragone è dato dalle PPD (Points Per Day), cioè la qualità e la quantità di proteine che riescono ad esser analizzate per giorno. Più il sistema è capace, più alto sarà quel valore.


PS3 : 650 ~ 1000
HD2600XT : 900 ~ 1150
HD3850 : 1400 ~ 2200
8600GT : 1700 ~ 2000
HD4850 : 1700 ~ 2300
HD3870 : 1800 ~ 2500
HD4870 : 2000 ~ 2500
Q6600 : 3000 ~ 3100
9600GT : 3700 ~ 4000
8800GT : 4500 ~ 4900
9800GTX : 5600 ~ 6200
GTX260 : 5700 ~ 6600
GTX280 : 6700 ~ 7200


Come si può vedere, il colore VERDE domina la classifica.

Nota: Dato molto dipende dal tipo di proteina, dal sottosistema, e dall'occupazione di risorse, vengono riportati i valori minimi e massimi, per un confronto ancora più accurato.

Se qualcuno vuole approfondire, o anche solo verificare la veridicità, IO (a differenza di altri) fornisco tutte le fonti:
Folding@home - NVD (http://foldingforum.org/viewtopic.php?f=43&t=3193)
Folding@home - ATI (http://foldingforum.org/viewtopic.php?f=51&t=4263)
PCGamesHardware (http://www.pcgameshardware.com/aid,648270/Reviews/Folding@Home_on_Nvidia_GPUs_PCGH_benchmarks/)
FahMon (http://www.fahmon.net/)
Overclock.net (http://www.overclock.net/overclock-net-folding-home-team/355545-f-h-amd-intel-ati-nvidia.html)
Anandtech (http://forums.anandtech.com/messageview.aspx?catid=39&threadid=2215500&enterthread=y)




peccato che quello che hai npostato non è un confronto diretto tra le prestazioni delle singole gpu ma un confronto sul totale delle gpu nVIDIA E ATi usate per folding@home (quindi neppure circolanti).
L'unico confronto diretto risale alla generazione precedente, quella a shader dedicati, tra un G70 e un R520.
http://www-graphics.stanford.edu/~mhouston/public_talks/R520-mhouston.pdf
Vedere i risultati verso la fine.

Non sto a sindacare l'utilità di programmi di calcolo distribuito, poichè non è la sede opportuna, ma segnalo che tra i programmatori le opinioni sono alquanto divergenti.



CONCLUSIONI

Sia l'architettura HD4800 che quella GTX200 sono state lanciate in Giugno 2008, quindi si presuppone abbiano una PARI MATURITA' di driver, e un PARI SUPPORTO dagli sviluppatori - niente giustificazioni.
Eppure, sia GTX260 sia 9800GTX+ vanno circa - 3 VOLTE - la HD4850, e questo nonostante sulla carta dovrebbe essere il contrario (vedi GFLOPs)!!!
Ulteriori conferme ci vengono date da modelli inferiori, dove la 9600GT va - IL DOPPIO - della HD3870.


conclusioni sbagliate basate su premesse sbagliate



Che sia grazie a CUDA, più semplice da programmare rispetto il linguaggio macchina attualmente usato da ATI, che sia grazie ai maggior sforzi che NVIDIA butta nel progetto GPGPU (ha tutta una sezione dedicata agli sviluppatori, con forum annesso), che sia un po' quel che più si vuole credere...
Il risultato è che al momento l'architettura NVIDIA nel GPGPU COMPUTING prende a sonore mazzate quella ATI, e i progetti commerciali/professionali che stanno uscendo sono per il 99% rivolti verso NVIDIA QUADRO e NVIDIA CUDA.



altra conclusione sbagliata. Posta un confronto diretto sullo stesso applicativo e poi ne riparliamo.


Nota: Il progetto di calcolo scientifico FOLDING@HOME si basa su SINGLE PRECISION, questo la dice lunga anche sull’utilità della DOUBLE PRECISION nel nostro ambito di interesse (=ZERO).


questo la dice lunga sull'inaccuratezza dei calcoli; si usa fp32 solo per allargare la base delle piattaforme impiegate, non perchè fp64 sia inutile :D



MOTORI FISICI I
STORIA

Uno dei più grandi avanzamenti tecnologici dei prossimi anni sarà l'utilizzo della fisica dei giochi, con calcoli in tempo reale.
Le schede grafiche hanno raggiunto una tale complessità e una tale potenza da rendere finalmente possibile tutto ciò, e con decadimenti prestazionali neppure troppo elevati.
Una GPU raggiunge 400-1200 GigaFLOPs, mentre una CPU si aggira intorno ai 4-40 GigaFLOPs (il "FLOP" è una unità di misura prestazionale).
Questo enorme divario fornisce subito le basi per comprendere come mai l'attuale piattaforma privilegiata sia la GPU.


:blah: :blah:




Precisazione faziosamente erronea.

I nomi da ricordare sono solo 2 : HAVOK (http://en.wikipedia.org/wiki/Havok_(software)) e AGEIA (http://en.wikipedia.org/wiki/AGEIA) .
La loro storia, una telenovela.
HAVOK lavora nel campo dal 2000, e ha concentrato i suoi sforzi su una libreria di sviluppo multipiattaforma che sfrutti principalmente la CPU.
AGEIA nasce nel 2003, e decide invece di fornire un sistema completo: un acceleratore grafico (prima PCI, poi PCI-E) e una libreria di sviluppo.
Nel 2005, quando si cominciano a vedere i primi frutti da AGEIA, è rivelata una partnership di HAVOK con NVIDIA per sviluppare HAVOK FX (http://www.xbitlabs.com/news/multimedia/display/20051028224421.html), la loro risposta ad AGEIA, cioè una libreria di sviluppo che sfrutti direttamente la GPU.
Da qui scatta la corsa all'oro.
A fine 2007 spunta un terzo incomodo, INTEL. Questi sta sviluppando una sua architettura, LARRABEE (http://en.wikipedia.org/wiki/Larrabee_(GPU)), basata su CPU x86, e non GPU. L'acquisizione di HAVOK è strategica (http://www.intel.com/pressroom/archive/releases/20070914corp.htm), INTEL ottiene gli strumenti di sviluppo, ed azzoppa i progetti per supportare le GPU sul nascere.
A fine 2008 NVIDIA acquisisce AGEIA (http://www.firingsquad.com/features/ageia_physx_acquisition_interview/), sfruttando una sua crisi finanziaria.


il resto sono solo chiacchiere: cosa ci sarebbe di fazioso ed errato nella mia affermazione? La ripeto: havok non presenta un approccio cpu only ma si può utlizzare anche su gpu. Se hai una qualche confidenza con Mark Harris, chiedi pure a lui :D


ATI? Rimane fuori dai giochi.

A metà 2008 cerca di cambiare l'opinione pubblica annunciando un accordo con HAVOK (http://www.custompc.co.uk/news/602763/amd-announces-physics-partnership-with-havok.html), che è semplicemente pari a fumo negli occhi. Per tre motivi:
1. Subito dopo l'acquisizione ATI ha confermato che le comunicazioni con HAVOK sono terminate, data la divergenza di finalità (http://www.custompc.co.uk/news/601677/gpu_physics_dead_says_amd.html).
2. HAVOK è basato sulla CPU, e il progetto GPU (HAVOK FX) è morto.
3. HAVOK fra i suoi partner (http://www.havok.com/content/blogcategory/30/68/) annoverava già NVDIA, MICROSOFT, SONY, NINTENDO; l'entrata di ATI fra questi avviene addirittura in ritardo.


altre conclusioni errate: intel ha intenzione di implementare la fisica nei giochi tramite havok su larrabee che non è una cpu e neppure una gpu; o meglio, è tutt'e due. Così come utilizzerà larrabee per il gpgpu.



Al danno si aggiunge la beffa, datosi che è possibile portare i programmi scritti in NVIDIA CUDA sull'architettura ATI, fra cui proprio PHYSX, con NVIDIA disponibilissima a questo, addirittura supportando terze parti in progetti amatoriali volti ad ottenere questi risultati.
http://www.extremetech.com/article2/0,2845,2324555,00.asp
ATI non vuole.


ci dai una sola buona ragione per cui AMD dovrebbe favorire il tentativo di nVIDIA di imporre come standard per la fisica il suo ageia e come standard per il gpgpu il suo CUDA. Personalmente non ne vedo, però vedo molti motivi per cui AMD non avrebbe interesse a farlo


CONCLUSIONI:
NVIDIA e INTEL hanno preso strade diverse, ma entrambe sono anni che si impegnano a portarle avanti.
ATI invece ha trascurato questo aspetto, e lo sta ancora facendo, nonostante le siano state date possibilità TANGIBILI.
Il perché quindi non abbracci PHYSX può portare a molteplici interrogativi, implicitamente risolti: non vuole pagare per l'uso di altrui tecnologie, e teme il confronto con la concorrenza.
Fatto sta che quello che al momento offre ai suoi clienti sono solo tante parole, neppure più di tanto confortanti.

Le fonti sono disponibili come formato hyperlink, cliccando sopra alcune parole presenti del testo.

la risposta è semplice per tutti, tranne che per chi non la vuole vedere

Chi volesse davvero un buon software di transcoding con supporto CUDA prenda in considerazione questo:
http://tmpgenc.pegasys-inc.com/en/product/te4xp.html
che importa ed esporta in molteplici formati :)

L'ho sempre pensato che Google ha rovinato i forum :D (sto facendo dell'ironia eh, no flame)

Ritorno IT. Ho provato il software, effettivamente risulta molto semplicistico ma è un programma dalle buone potenzialità.

quoto matteo1

Dopo aver parlato di tutte queste pizze e focaccine, mi è venuta una fame!!
Comunque, secondo me è tutto un FLOP. :p
L'architettura teoricamente migliore non è quella che vince, così come la console migliore non è quella più potente. Sono tantissimi i fattori che entrano in gioco. Ad esempio, chi si ricorda della serie GeForce FX5xxx ? Erano delle schede video velocissime in ambito PS1.1, ma facevano pena con shader 2.0. Tuttavia vendettero tantissimo, perché le applicazioni che sfruttavano decentemente shader 2.0 uscirono molto più tardi, e su quelle tradizionali (vecchi engine 3D) le FX si comportavano meglio delle ATi dell'epoca.

Fatto sta che, tutte queste tecnologie proprietarie non facilitano di certo l'utilizzo di calcolo parallelo mediante GPU in ambito accademico... Sarebbe stato molto più giusto organizzare un comitato, fra i principali produttori di GPU, per definire uno standard aperto che poi ognuno sarebbe stato libero di implementare. Così, invece, mi sembra tutta una barzelletta. Speriamo almeno che le prossime DirectX (e magari anche OpenGL) includano al loro interno dei meccanismi di programmazione GPGPU, così che spariscano tutti i linguaggi proprietari, con buona pace degli utenti e delle università.

L'architettura teoricamente migliore non è quella che vince, così come la console migliore non è quella più potente.Per me è il contrario. Possiamo stare giornate intere a parlare di MIMD SIMD VLIW EPIC (FAIL) e minchiate varie (eventualmente offendendoci reciprocamente sulla correttezza o meno di un termine tecnico), ma l'unica cosa davvero importante sono le prestazioni REALI; definite peraltro da diversi fattori (tutti utili al loro conseguimento):
- bontà dell'architettura (potenza bruta, capacità specifiche)
- bontà del supporto implicito (ottimizzazioni lato driver)
- bontà del supporto esplicito (compilatore, tool, esempi)

Un esempio (che può esser fatto anche lato 3D), il C*DA. Potenza bruta solo discreta (se lo confrontiamo con i GFLOPS teorici del concorrente), ma ottime capacità specifiche, ottimizzazioni, compilatore, supporto ed esempi, che poi è il motivo per cui va prendendo così tanto piede (vedi questo Badaboom).

Mi da altresì grande dispiacere vedere postati da taluni confronti di folding@home fra G70 e R520 (due architetture lato desktop oramai obsolete), quando ho fornito i nuovi di G80/G92/GT200 (ben 3 serie di chip) e concorrenti ATI, che non lasciano minimamente adito a dubbi.
Significa proprio cercare una ragione prettamente faziosa attraverso fumo negli occhi e comparative pasticciate.

Concludo, poichè immagino pochi avran avuto la forza di regger fin qua (e siamo anche mezzi OT), con la distruzione di alcuni sogni AT*/HAV*K.
FallOut 3 utilizza proprio il motore HAVOK, vogliamo quindi vedere le prestazioni, chiudendo il cerchio con la linea di pensiero espressa a inizio reply? (sentendo alcuni soliti noti, con piattaforma AT* dovremmo aspettarci millemila FPS!)
http://www.firingsquad.com/hardware/fallout_3_performance/page3.asp
Totale ownage da parte di NV*DIA (con la HD4850 superata già dalla 9800GTX, e non dalla 9800GTX+, la vera diretta concorrente).

Saluti.

Per me è il contrario. Possiamo stare giornate intere a parlare di MIMD SIMD VLIW EPIC (FAIL) e minchiate varie (eventualmente offendendoci reciprocamente sulla correttezza o meno di un termine tecnico), ma l'unica cosa davvero importante sono le prestazioni REALI; definite peraltro da diversi fattori (tutti utili al loro conseguimento):
- bontà dell'architettura (potenza bruta, capacità specifiche)
- bontà del supporto implicito (ottimizzazioni lato driver)
- bontà del supporto esplicito (compilatore, tool, esempi)



i termini tecnici, per definizione, devono essere corretti e mai approssimativi o sbagliati. Altrimenti si fa conversazione da bar dello sport.Dai un'occhiata alla serie di inesattezze (voglio essere buono) che hai detto su scheduler, intel, larrabee, itanium, simd, mimd sisd, vliw, ecc, ovvero gran parte di quegli elementi che aiutano a capire la bontà di un'architettura (tanto per restare in campo neutro)



Un esempio (che può esser fatto anche lato 3D), il CUDA. Potenza bruta solo discreta, ma ottime capacità specifiche, ottimizzazioni, compilatore, supporto ed esempi, che poi è il motivo per cui va prendendo così tanto piede (vedi questo Badaboom).

Mi da altresì grande dispiacere vedere postati da taluni confronti di folding@home fra G70 e R520 (due architetture lato desktop oramai obsolete), quando ho fornito i nuovi di G80/G92/GT200 (ben 3 serie di chip) e concorrenti ATI, che non lasciano minimamente adito a dubbi.
Significa proprio cercare una ragione prettamente faziosa attraverso fumo negli occhi e comparative pasticciate.



il pasticcio si crea quando si forniscono dati sull'utilizzo di una piattaforma rispetto ad un'altra e li si spaccia per test sulla potenza delle rispettive piattaforme. Il test tra le due architetture "obsolete" rappresenta l'unico termine di confronto diretto tra un'architettura ATi ed una nVIDIA (con la seconda che vanta una potenza di calcolo teorica superiore) con applicazioni fisiche e, che ti piaccia o no, il risultato è quello riportato.



Concludo, poichè immagino pochi avran avuto la forza di regger fin qua (e siamo anche mezzi OT), con la distruzione di alcuni sogni ATI/HAVOK.
FallOut 3 utilizza proprio il motore HAVOK, vogliamo quindi vedere le prestazioni, chiudendo il cerchio con la linea di pensiero espressa a inizio reply? (sentendo alcuni soliti noti, con piattaforma ATI dovremmo aspettarci millemila FPS!)
http://www.firingsquad.com/hardware/fallout_3_performance/page3.asp
Totale ownage da parte di NVIDIA (con la HD4850 superata già dalla 9800GTX, e non dalla 9800GTX+, la vera diretta concorrente).

Saluti.

nessuna distruzione dei sogni; AMD non sta ancora supportando ufficialmente havok e fallourt 3 ha lo stesso engine grafico di oblivion che è un gioco in cui le gpu nVIDIA vanno notoriamente meglio (basta reperire uno dei tanti test on line).

nessuna distruzione dei sogni; AMD non sta ancora supportando ufficialmente havok e fallourt 3 ha lo stesso engine grafico di oblivion che è un gioco in cui le gpu nVIDIA vanno notoriamente meglio (basta reperire uno dei tanti test on line).

Quand'anche ci fosse il supporto GPGPU all'Havok, dubito che un titolo come Fallout3 potrebbe essere un benchmark indicativo, in quanto la fisica non e' certo il collo di bottiglia.

Quand'anche ci fosse il supporto GPGPU all'Havok, dubito che un titolo come Fallout3 potrebbe essere un benchmark indicativo, in quanto la fisica non e' certo il collo di bottiglia.

tra le altre cose e comunque, aumentando la risoluzione ed utilizzando i filtri, in nessun titolo la fisica fa da collo di bottiglia (salvo usare il multigpu) :)