Disponibile la versione 1.0 di Badaboom, transcoder via GPU

[yossarian]

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)

[yossarian]

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

Originariamente inviato da MiKeLezZ

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

http://forums.amd.com/devforum/messa...&enterthread=y

http://forums.amd.com/forum/messagev...threadid=93635

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

http://forum.beyond3d.com/archive/in...p/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.

Originariamente inviato da MiKeLezZ

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.

Originariamente inviato da MiKeLezZ

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.

Originariamente inviato da MiKeLezZ

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.

Originariamente inviato da MiKeLezZ

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! 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).

Originariamente inviato da MiKeLezZ

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:



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................

Originariamente inviato da MiKeLezZ

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.............................

Originariamente inviato da MiKeLezZ

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

Originariamente inviato da MiKeLezZ

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.
http://www.multicoreinfo.com/researc...e_manycore.pdf

Originariamente inviato da MiKeLezZ

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)

Originariamente inviato da MiKeLezZ

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
A proposito, da chi viene questa informazione? Da Kirk o da Harris?
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)

Originariamente inviato da MiKeLezZ

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

Originariamente inviato da MiKeLezZ

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

soprattutto interessi economici, direi

Originariamente inviato da MiKeLezZ

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

Originariamente inviato da MiKeLezZ

Fonti:
InsideHPC


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

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

Originariamente inviato da MiKeLezZ

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, 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
Folding@home - ATI
PCGamesHardware
FahMon
Overclock.net
Anandtech

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/~mh...0-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.

Originariamente inviato da MiKeLezZ

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

Originariamente inviato da MiKeLezZ

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.

Originariamente inviato da MiKeLezZ

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

Originariamente inviato da MiKeLezZ

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.

Originariamente inviato da MiKeLezZ

Precisazione faziosamente erronea.

I nomi da ricordare sono solo 2 : HAVOK e 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, 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, basata su CPU x86, e non GPU. L'acquisizione di HAVOK è strategica, INTEL ottiene gli strumenti di sviluppo, ed azzoppa i progetti per supportare le GPU sul nascere.
A fine 2008 NVIDIA acquisisce AGEIA, 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

Originariamente inviato da MiKeLezZ

ATI? Rimane fuori dai giochi.

A metà 2008 cerca di cambiare l'opinione pubblica annunciando un accordo con HAVOK, 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à.
2. HAVOK è basato sulla CPU, e il progetto GPU (HAVOK FX) è morto.
3. HAVOK fra i suoi partner 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.

Originariamente inviato da MiKeLezZ

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/...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

Originariamente inviato da MiKeLezZ

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

[matteo1]

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

[ABCcletta]

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

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

[EMAXTREME]

quoto matteo1

[Dott.Wisem]

Dopo aver parlato di tutte queste pizze e focaccine, mi è venuta una fame!!
Comunque, secondo me è tutto un FLOP.
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à.

[MiKeLezZ]

Originariamente inviato da Dott.Wisem

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/...ance/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.

[yossarian]

Originariamente inviato da MiKeLezZ

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)

Originariamente inviato da MiKeLezZ

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.

Originariamente inviato da MiKeLezZ

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/...ance/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).

[blade9722]

Originariamente inviato da yossarian

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.

[yossarian]

Originariamente inviato da blade9722

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)