[yossarian]

Originariamente inviato da Free Gordon

Yoss... secondo te è possibile una cosa del genere?

Questo tizio pare esser riuscito a portare il physX su una 3870... (tramite CUDA ).

yes, we can

Originariamente inviato da Free Gordon

[b]

E poi,secondo te:
quale delle due architetture (tra R600/G80 e Rv770/GT200)) è più adatta a macinare calcoli fisici?
Dovrebbe essere abbastanza avvantaggiata ATI, giusto? Dato che i calcoli sui vertici sfruttano nativamente tutte e 5 le unità disponibili negli SP a disposizione delle architetture ATI...

dipende dal tipo di codice che si usa. Con istruzioni, tipo quelle geometriche, che tendono a privilegiare il calcolo parallelo, sicuramente l'architettura dei chip ATi è più performante, in alcuni casi anche di molto.

Originariamente inviato da Free Gordon

Ma perchè non ci sono state 32TU in R600?
Perchè non uscire già a 65nm... se ormai il ritardo era cosa nota??

perchè R600 ha 4 gruppi di 16 sp con 4 tu ciascuno, con un rapporto sp/tu di 4:1, mentre RV770 ha 10 gruppi di 16 sp con 4 tmu ciascuno, con un rapporto sp/tu sempre di 4:1. Quindi l'architettura non è stata modificata.

Originariamente inviato da Free Gordon

Con un ipotetico raddoppio delle TU rispetto a R600, tolgliendo le unità inutili (troppi texture samplers e le 16 unità non filtranti che non son servite a granchè), credo che il chip ATI sarebbe stato almeno pari di G80, nei giochi del periodo... (e cmq più veloce nei giochi shader-bounded).

perchè ritieni le tsu inutili? Avere un numero di texture samplers unit maggiore rispetto a quello delle texture filtering unit e delle texture address unit, permette, insieme a cache di tipo fully associative, di minimizzare le latenze per le operazioni diaccesso alle texture; per questo scopo, sia R600 che i chip seguenti, sono dotati di funzionalità memexport e memimport, per permettere alle unità di calcolo, qualora fosse necessario, di accedere direttamente alla vram senza necessità di caricare i dati nei registri.
Le 16 unità "non filtranti" erano state messe lì per le operazioni di vertex texturing per i giochi shader bounded il discorso da fare è un po' più lungo e complesso; in sintesi si può dire che dipende da come il gioco è programmato: se vuoi favorire in maniera spudorata nVidia, allora compili un codice con tante iastruzioni di tipo float mad serial; se, al contrario, intendi favorire ATi, allora utilizzi codice che preveda il massimo parallelismo possibile. In parole povere, tante istruzioni seriali con istruzioni di tipo dependent read che non possono essere assemblate in macro istruzioni esaltano l'architettura nVidia e frenao quella ATi; thread con più istruzioni "legate" tra loro, tipo calcoli su vettori, fanno rendere al massimo l'architettura ATi e fanno piantare quella nVidia. Questo perchè il singolo sp di G8x/GT2x0 è pensato per operare in maniera seriale, mentre il singolo sp di R600 e derivati in modalità parallela

Originariamente inviato da Free Gordon

Per me è palese che il problema di R600...era nelle 16TU e nel fatto che diversi transistor sono stati sprecati...

non sarei così sicuro del fatto che il problema fosse legato solo alle 16 tmu

Originariamente inviato da Free Gordon

Oltretutto la maggiore potenza dello shader core di R600, sarebbe stata più sfruttabile con più TU a disposizione.. no?

la maggior potenza dello shader core di R600 ha più bisogno di codice ottimizzato rispetto al meno potente G80 e non solo a causa del minor numero di tmu.
Le modifiche fatte al MC dovrebbe farti capire qualcosa di più. Pensa a quello che ti dicevo a proposito del numero massimo di gruppi di unità che era possibile servire senza avere colli di bottiglia o senza rendere impervia la programmazione del mc con un ring bus. E pensa a quante unità o gruppi di unità serve il ring bus di R600 e di RV6x0 (non parlo solo di alu) e chiediti a cosa serva l'hub in RV770.