[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[yossarian]

Originariamente inviato da Diobrando_21

ok, ora è tutto più chiaro...grazie.

Però allora fermi avrà problemi x i discorsi suddetti, le ati hanno problemi non appena si attiva un minimo di tessellazione...io sinceramente non ne vedo più l'utilità...in entrambe i casi non vedo risultati che potrebbero soddisfarmi. È ovvio che se avremmo vga che stanno a 300fps senza e 100 con, sarò strafelice ma non credo proprio sia il caso di queste vga...che ne dite?

credo che l'uso che si farà, almeno all'inizio, della tessellation, sarà più che altro volto al risparmio delle risorse, con un aumento moderato del dettaglio poligonale in alcuni casi ma, per lo più, con la tessellation usata per minimizzare l'uso di bandwidth e memoria.

[skizzo99999999]

Originariamente inviato da yossarian

non hai tenuto conto di alcuni elementi:
1) gli Hull shader hanno unità fixed function il cui lavoro deve essere emulato da quelle fp dello shader core
2) nell'esecuzione di VS, HS, DS, GS, PS, texture blending, sono richieste operazioni di thread switching; e tanto maggiore è il numero di tilogie di calcoli che una unità può eseguire, tanto più alto sarà la probabilità di dover eseguire uno switch (= cicli persi per ogni switch)
3) al contrario, se immagini un'elaborazione di tipo seriale (prima i VS, poi gli HS, poi la tessellation, quindi DS, GS, rasterizer) allora toriniamo al concetto di pipeline classica e si perde gran parte del vantaggio degli shader unificati.
In base a queste considerazioni, avere 512+T è meglio che avere 544 alu generiche a parità di die size.
4) se fai il raffronto con RV870 (perchè di questo si parla) il secondo è proprio nella situazione di chi ha 512+T.

1) Mi sembra che non ci siano dubbi sul fatto che le fsi di hull e domain girano più veloci su sp dedicati che non su generici. Il fatto è che mi sembra evidente dal tipo di operazioni da eseguire che iul rallentamento non sia drammatico (come ad esempio succuederebbe sulle operazioni di texture emulate), un po come il passaggio da pixel/vertex shader a shader unificati. E' il termine emulazione che di primo acchito è secondo me fuorviante, sembra indicare un range di prestazioni completamente diverso.
2) Giusto, ma non mi sembra una perdita di efficienza significativa come ordine di grandezza rispetto agli altri problemi di cui si sta parlando
3) L'elaborazione ad alto livello all'interno del frame è sempre seriale. Visto però che per ogni frame ci sono migliaia di vertici e pixel e che la GPU non ha risorse per elaborarli tutti contemporaneamente, è normale che non si faccia tutto in sequenza, ma "localmente" ad ogni vertice/pixel le operazioni che lo riguardano scorrono ovviamente secondo la pipeline che hai prospettato o cmq quella decisa dal programmatore tramite il codice caricato negli shader. Non vedo che centra con il discorso dell'efficienza tra pixel/vertex e shader unificati. Anzi, se si eseguisse brutalmente in maniera sequenziale ogni pixel dell'interno frame allora si vedrebbe un vantaggio dell'architettura unificata ancora maggiore, visto che mentre la GPU a shader separati deve eseguire tutti i calcoli relativi ai vertex shader finchè non avesse finito tutti i vertici, i pixel shader starebbero con le mani in mano, cosa che ovviamente non accadrebbe con gli shader unificati. Ovviamente l'efficienza generale farebbe comunque schifo in entrambi i casi visto lo spreco di tutto il resto dell'HW per gran parte del tempo...

Che ti devo dire, secondo me è meglio avere 544 sp generici che 512+T, sempre se gli ordini di grandezza della perdita di efficienza sia tipo quella prospettata negli esempi. Bisogna tenere conto che ogni sp guadagnato è oro, visto il tempo per cui può essere impiegato all'interno dell'elaborazione del frame rispetto a quanto vengano utilizzate le unità di tessellazione.
E' come se un programnmatore avesse scritto un programma che per eseguire un dato calcolo ci impiega 10 secondi suddivisi in questo modo: 1 secondo tramite la funziona A e 9 secondi tramite la funzione B. E' inutile che si sprema il cervello per ottimizzare fino all'inverosimile la funzione A; è la B che utilizza la maggior parte delle risorse. Siccome le fasi di hull e domai occupano una piccola parte del tempo per frame è molto meglio migliorare anche di poco le prestazioni del resto (avere maggiori sp) che dedicarsi a migliorare queste.
Sono confronti che per chi progetta (e quindi ha l'hardware in mano con latenze e balle varie davanti al naso) sono abbastanza semplici da fare, se hanno optato per questa scelta mi sembra evidente che, almeno per come li avrebbero implementato loro (NVIDIA) hull e domain, la scelta è quella prestazionalmente migliore. Poi se ATi ha fatto Hull e domain moooolto più veloci di quello a suo tempo previsto da NVIDIA, peggio per loro... La mia è solo un'osservazione sull'architettura a livello generale, per far capire che "emulare" quelle due fasi non vuol dire togliere risorse alle altre, anzi, è il contrario.

[Diobrando_21]

Originariamente inviato da yossarian

credo che l'uso che si farà, almeno all'inizio, della tessellation, sarà più che altro volto al risparmio delle risorse, con un aumento moderato del dettaglio poligonale in alcuni casi ma, per lo più, con la tessellation usata per minimizzare l'uso di bandwidth e memoria.

ma a me andrebbe anche bene così, basta che non ci siano cali prestazionali visti finora...per me non ha molto senso guadagnare da un lato e perdere dall'altro...cmq a questo punto si può tranquillamente dire (come ghiltanas sopra) che parleremo di vera tessellation solo con le vga (e le console) della prox generazione...

[Athlon 64 3000+]

Originariamente inviato da yossarian

credo che l'uso che si farà, almeno all'inizio, della tessellation, sarà più che altro volto al risparmio delle risorse, con un aumento moderato del dettaglio poligonale in alcuni casi ma, per lo più, con la tessellation usata per minimizzare l'uso di bandwidth e memoria.

Quindi in buone parole la tesselation verra usata più che altro non per aumentare in maniera considerevole l'uso dei poligoni,ma diciamo che la cpu manderà un numero di vertici più basso del solito e farà aumentare il numero di poligoni alla tesselation cosi da far aumentare magari le prestazioni.
Un gioco ha modelli da 20000 poligoni e questi vengono creati con la normale rasterizzazione.
Con la tesselation attiva invece al principio ci sono modelli con 2000 poligoni e la tesselation li porta a 20000 poligoni.
Mi sembra di avere capito che intendi questo e protrebbe portare anche ad un aumento delle prestazioni.
Se mi sbaglio correggimi naturalmente.

[yossarian]

Originariamente inviato da skizzo99999999

1) Mi sembra che non ci siano dubbi sul fatto che le fsi di hull e domain girano più veloci su sp dedicati che non su generici. Il fatto è che mi sembra evidente dal tipo di operazioni da eseguire che iul rallentamento non sia drammatico (come ad esempio succuederebbe sulle operazioni di texture emulate), un po come il passaggio da pixel/vertex shader a shader unificati. E' il termine emulazione che di primo acchito è secondo me fuorviante, sembra indicare un range di prestazioni completamente diverso.

le constant function degli hull shader sono, per forza di cose, emulate; non è così per la parte programmabile né per i domain shader. Che l'impatto non sia drammatico come quello del ricorso a unità generiche per le operazioni di texture sampling siamo d'accordo, ma se anche il rapporto, anzichè 20:1 fosse di 3:1 significherebbe che per avere un'elaborazione su unità generiche che sia veloce come quella su unità dedicate devo avere 3 unità generiche per ognuna dedicata (il che mi aumenta le dimensioni del die, tra l'altro, perchè un'unità generica è sensibilmente più grande rispetto ad una dedicata.

Originariamente inviato da skizzo99999999

2) Giusto, ma non mi sembra una perdita di efficienza significativa come ordine di grandezza rispetto agli altri problemi di cui si sta parlando

è comunque una perdita di efficienza che si va a sommare alle altre (sempre in relazione allo specifico task e non in riferimento all'architettura, ovviamente)

Originariamente inviato da skizzo99999999

3) L'elaborazione ad alto livello all'interno del frame è sempre seriale. Visto però che per ogni frame ci sono migliaia di vertici e pixel e che la GPU non ha risorse per elaborarli tutti contemporaneamente, è normale che non si faccia tutto in sequenza, ma "localmente" ad ogni vertice/pixel le operazioni che lo riguardano scorrono ovviamente secondo la pipeline che hai prospettato o cmq quella decisa dal programmatore tramite il codice caricato negli shader. Non vedo che centra con il discorso dell'efficienza tra pixel/vertex e shader unificati. Anzi, se si eseguisse brutalmente in maniera sequenziale ogni pixel dell'interno frame allora si vedrebbe un vantaggio dell'architettura unificata ancora maggiore, visto che mentre la GPU a shader separati deve eseguire tutti i calcoli relativi ai vertex shader finchè non avesse finito tutti i vertici, i pixel shader starebbero con le mani in mano, cosa che ovviamente non accadrebbe con gli shader unificati. Ovviamente l'efficienza generale farebbe comunque schifo in entrambi i casi visto lo spreco di tutto il resto dell'HW per gran parte del tempo...

un'architettura a shader dedicati non funziona in maniera tale che finchè non si è terminata l'elaborazione di tutti i vertici del frame i PS sono in idle. L'input avviene per batch di vertici che vengono elaborati dai VS e passati ai PS man mano che procede l'elaborazione. Ci sono momenti in cui gli uni o gli altri sono in idle (ad esempio quando i VS hanno riempito il byìuffer posizionato tra i due stadi di VS e PS e i PS non hanno ancora terminato la precedente elaborazione, oppure quanto i PS non hanno pieno il loro set di registri costanti all'inizio dell'elaborazione di ogni nuovo gruppo di primitive. Per il resto, però, PS e VS lavorano in contemporanea; il problema, semmai, è la sottooccupazione di uno dei due stadi epr la maggior parte del tempo.
Il vantaggio degli shader unificati è proprio che grazie alla possibilità di usare la stessa unità per più compiti (e grazie alla presenza di registri costanti di diverso tipo, ovvero, in pratica tutti quelli che erano presenti sia sulle unità di pixel che di vertex e geometry shader) c'è la possibilità di fare eseguire, a quella stessa unità (o meglio, a quel gruppo di unità di quello specifico cluster) il tipo di calcoli che mi servono o mi fanno comodo in quel momento; il che significa che posso farli lavorare su dei dati geometrici e, immediatamente dopo, se non c'è dipendenza, su dei pixel.
Se mi metto a far eseguire, al contrario, prima VS, poi HS, quindi DS, GS e, infine, PS, torno allo schema a shader dedicati, localmente o globalmente non ha importanza o, quanto meno, ha un'importanza relativa.

Originariamente inviato da skizzo99999999

Che ti devo dire, secondo me è meglio avere 544 sp generici che 512+T, sempre se gli ordini di grandezza della perdita di efficienza sia tipo quella prospettata negli esempi. Bisogna tenere conto che ogni sp guadagnato è oro, visto il tempo per cui può essere impiegato all'interno dell'elaborazione del frame rispetto a quanto vengano utilizzate le unità di tessellazione.
E' come se un programnmatore avesse scritto un programma che per eseguire un dato calcolo ci impiega 10 secondi suddivisi in questo modo: 1 secondo tramite la funziona A e 9 secondi tramite la funzione B. E' inutile che si sprema il cervello per ottimizzare fino all'inverosimile la funzione A; è la B che utilizza la maggior parte delle risorse. Siccome le fasi di hull e domai occupano una piccola parte del tempo per frame è molto meglio migliorare anche di poco le prestazioni del resto (avere maggiori sp) che dedicarsi a migliorare queste.
Sono confronti che per chi progetta (e quindi ha l'hardware in mano con latenze e balle varie davanti al naso) sono abbastanza semplici da fare, se hanno optato per questa scelta mi sembra evidente che, almeno per come li avrebbero implementato loro (NVIDIA) hull e domain, la scelta è quella prestazionalmente migliore. Poi se ATi ha fatto Hull e domain moooolto più veloci di quello a suo tempo previsto da NVIDIA, peggio per loro... La mia è solo un'osservazione sull'architettura a livello generale, per far capire che "emulare" quelle due fasi non vuol dire togliere risorse alle altre, anzi, è il contrario.

cioè, fammi capire: istante t0, tessellator spento.
RV870 ha 1600 alu e fermi 512 impegnate a fare altro. Istante t1, parte la tessellation; RV870 ha 1600 alu impegnate a fare quello che stavano facendo prima ed, in più, un'unità dedicata alla tessellation; fermi ha n alu impegnate a fare tessellation e 512-n impegnate a fare quello che stavano facendo prima. Questo significa sottrarre risorse.
In RV870 il tessellator può diventare il collo di bottiglia? In fermi anche, direttamente o indirettamente (perchè provoca il verificarsi di colli di bottiglia altrove).
Controprova: attivi physx, il frame rate cala anzi, se l'elaborazione è particolarmente pesante, crolla. Questo perchè n alu stanno facendo altro. Ulteriore controprova: il MSAA su R600 con il resolve via shader. Anche in questi casi non parliamo di emulazione ma il risultato è lo stesso Non vedo per quale motivo il tessellator su fermi debba fare eccezione. Inoltre, sei partito da un altro assunto sbagliato, ovvero che la parte del leone la faccia il tessellator. Niente di più lontano dalla realtà. Il tessellator lavora a 16 bit in virgola fissa ed esegue i suoi calcoli molto velocemente. In molti casi sono i DS, che si occupano anche di fare dispplacement mapping, ad occupare la maggrior parte del tempo (questo significa tenere bloccate delle unità generiche ocn delle chiamate a texture anche per le operazioni geometriche)

[ghiltanas]

si può fare un paragone (molto con le pinze) tra la potenza eleborativa dell'unità dedicata presente in rv870, e gli sp di fermi? molto teoricamente, quanti sp nvidia occorrono per arrivare alla stessa potenza dell'hw dedicato nelle ati?

[halduemilauno]

la GTX470 in vendita in Cina per l'equivalente di 366$.
http://diy.yesky.com/vga/259/11163259.shtml

[DVD2005]

Originariamente inviato da halduemilauno

la GTX470 in vendita in Cina per l'equivalente di 366$.
http://diy.yesky.com/vga/259/11163259.shtml

ogni tanto spunti, ciao

[halduemilauno]

Originariamente inviato da DVD2005

ogni tanto spunti, ciao

Ciao.

[calabar]

Originariamente inviato da yossarian

credo che l'uso che si farà, almeno all'inizio, della tessellation, sarà più che altro volto al risparmio delle risorse, con un aumento moderato del dettaglio poligonale in alcuni casi ma, per lo più, con la tessellation usata per minimizzare l'uso di bandwidth e memoria.

Questa situazione per me sarebbe decisamente auspicabile, ma ho paura che sia anche troppo ottimistica.
Abbassare il dettaglio geometrico di base significa avere una pessima grafica sulle schede che non supportano tessellation (la stragrande maggioranza ancora per un bel po').
Per questo mi pare plausibile che il dettaglio di partenza sarà comunque alto, e la tessellation venga utilizzata per aggiungere un "superdettaglio" su alcuni modelli, appesantendo nel complesso la scena.
Quando poi le schede dx11 saranno più diffuse e magari ci saranno le nuove consolle, allora penso si possa fare un uso più "corretto" della tessellation.

Originariamente inviato da yossarian

cioè, fammi capire: istante t0, tessellator spento.
RV870 ha 1600 alu e fermi 512 impegnate a fare altro. Istante t1, parte la tessellation; RV870 ha 1600 alu impegnate a fare quello che stavano facendo prima ed, in più, un'unità dedicata alla tessellation; fermi ha n alu impegnate a fare tessellation e 512-n impegnate a fare quello che stavano facendo prima. Questo significa sottrarre risorse.

Credo che lui intendesse dire che se RV 870 non avesse avuto la tessellation hardware, avrebbe potuto avere magari, nello stesso spazio, 1920 sp (numero a caso) che avrebbe garantito prestazioni superiori senza tessellation e prestazioni simili con tessellation rispetto alla versione 1600+T.

[yossarian]

Originariamente inviato da calabar

Credo che lui intendesse dire che se RV 870 non avesse avuto la tessellation hardware, avrebbe potuto avere magari, nello stesso spazio, 1920 sp (numero a caso) che avrebbe garantito prestazioni superiori senza tessellation e prestazioni simili con tessellation rispetto alla versione 1600+T.

cypress ha già 1920 alu (numero a caso) e in più anche il tessellator

Battute a parte, è evidente che lo spazio occupato dal tessellator è inferiore rispetto a quello che sarebbe stato occupato da un numero di unità di calcolo equivalenti, per prestazioni, allo stesso tessellator. Sicuramente con altri 4 cluster attivi RV870 sarebbe stato più veloce, ma non nelle operazioni di tessellation

[zorco]

Originariamente inviato da halduemilauno

la GTX470 in vendita in Cina per l'equivalente di 366$.
http://diy.yesky.com/vga/259/11163259.shtml

per 350 euro o -,secondo tè riusciremo a papparcela quà in italia?...

[sickofitall]

Originariamente inviato da zorco

per 350 euro o -,secondo tè riusciremo a papparcela quà in italia?...

il 26 lo sapremo

[halduemilauno]

Originariamente inviato da zorco

per 350 euro o -,secondo tè riusciremo a papparcela quà in italia?...

si credo di si.

Originariamente inviato da sickofitall

il 26 lo sapremo

esatto.

[ghiltanas]

Originariamente inviato da zorco

per 350 euro o -,secondo tè riusciremo a papparcela quà in italia?...

a 350 euro perè deve andare come la 5870, anzi di +...se è tra quest'ultima e la 5850 nn ci siamo

[halduemilauno]

Originariamente inviato da ghiltanas

a 350 euro perè deve andare come la 5870, anzi di +...se è tra quest'ultima e la 5850 nn ci siamo

in attesa della collocazione esatta e dei suoi prezzi attualmente la 5870 sta cosi...
http://www.trovaprezzi.it/categoria....zoMax=&sbox=sb
se andasse di + sarebbero 400 e passa €.

[Alekos Panagulis]

Originariamente inviato da halduemilauno

in attesa della collocazione esatta e dei suoi prezzi attualmente la 5870 sta cosi...
http://www.trovaprezzi.it/categoria....zoMax=&sbox=sb
se andasse di + sarebbero 400 e passa €.

Di più forse no, ma deve andare come la 5870.

[skizzo99999999]

Originariamente inviato da yossarian

un'architettura a shader dedicati non funziona in maniera tale che finchè non si è terminata l'elaborazione di tutti i vertici del frame i PS sono in idle. L'input avviene per batch di vertici che vengono elaborati dai VS e passati ai PS man mano che procede l'elaborazione. Ci sono momenti in cui gli uni o gli altri sono in idle (ad esempio quando i VS hanno riempito il byìuffer posizionato tra i due stadi di VS e PS e i PS non hanno ancora terminato la precedente elaborazione, oppure quanto i PS non hanno pieno il loro set di registri costanti all'inizio dell'elaborazione di ogni nuovo gruppo di primitive. Per il resto, però, PS e VS lavorano in contemporanea; il problema, semmai, è la sottooccupazione di uno dei due stadi epr la maggior parte del tempo.
Il vantaggio degli shader unificati è proprio che grazie alla possibilità di usare la stessa unità per più compiti (e grazie alla presenza di registri costanti di diverso tipo, ovvero, in pratica tutti quelli che erano presenti sia sulle unità di pixel che di vertex e geometry shader) c'è la possibilità di fare eseguire, a quella stessa unità (o meglio, a quel gruppo di unità di quello specifico cluster) il tipo di calcoli che mi servono o mi fanno comodo in quel momento; il che significa che posso farli lavorare su dei dati geometrici e, immediatamente dopo, se non c'è dipendenza, su dei pixel.
Se mi metto a far eseguire, al contrario, prima VS, poi HS, quindi DS, GS e, infine, PS, torno allo schema a shader dedicati, localmente o globalmente non ha importanza o, quanto meno, ha un'importanza relativa.

evidentemente non hai capito quello che ho scritto. In un post precedente hai detto:

Originariamente inviato da yossarian

se immagini un'elaborazione di tipo seriale (prima i VS, poi gli HS, poi la tessellation, quindi DS, GS, rasterizer) allora toriniamo al concetto di pipeline classica e si perde gran parte del vantaggio degli shader unificati.

ed io ti ho risposto che SE l'elaborazione di tutti i vertici/pixel fosse sequenziale allora la differenza tra shader unificati e dedicati sarebbe ancora maggiore di questi ultimi. Lo so bene che in realtà non è così, per cui nonostante avere gli shader unificati comporti molti benefici, non sono così drastici come sarebbero se le unità dedicate funzionassero un "gruppo per volta". E' quindi ovvio che nell'insieme degli sp vadano sia calcoli vertex, pixel, geometry, ecc... contemporaneamente, ma sono riferiti a primitive differenti. Mi spiego meglio: se ho un triangolo, prima applico i vertex shader sui vertici e soltanto dopo posso avviare i pixel (meglio dire fragment) shader sui pixel che lo compongono. Il contrario è ovviamente impossibile, visto che non posso sapere prima su quali pixel il triangolo agirà. Per capire la dipendenza ( che ci sarà sempre, in questo caso) basta esaminare del codice per vedere che l'attributo "varying" presente nei vertex shader è un parametro di uscita che viene ricevuto in ingresso dai fragment shader.
La sequenzialità delle operazione è quindi rispettata se si considera, diciamo, un poligono singolarmente. Poi è ovvio che la GPU ne esegua molti in parallelo e che non tutti abbiano lo stesso peso computazionale, per cui finiranno e cominceranno in momenti diversi, ma ai fini dell'analisi che stiamo esaminando non ha importanza.
Detto questo, sicccome i dati di input non sono infiniti (poniamo 10'000 triangoli, 1'000'000 di pixel) e che le operazioni di fragment shading impiegano molte più risorse rispetto a quelle di vertex, è sempre possibile che in un'architettura a shader dedicati alcuni sp rimangano in alcuni momenti inutilizzati. DA qui il vantaggi degli shader unificati. Ma mi sembra che su questo (e ci mancherebbe) siamo daccordo.

Originariamente inviato da yossarian

cioè, fammi capire: istante t0, tessellator spento.
RV870 ha 1600 alu e fermi 512 impegnate a fare altro. Istante t1, parte la tessellation; RV870 ha 1600 alu impegnate a fare quello che stavano facendo prima ed, in più, un'unità dedicata alla tessellation; fermi ha n alu impegnate a fare tessellation e 512-n impegnate a fare quello che stavano facendo prima. Questo significa sottrarre risorse.
In RV870 il tessellator può diventare il collo di bottiglia? In fermi anche, direttamente o indirettamente (perchè provoca il verificarsi di colli di bottiglia altrove).
Controprova: attivi physx, il frame rate cala anzi, se l'elaborazione è particolarmente pesante, crolla. Questo perchè n alu stanno facendo altro. Ulteriore controprova: il MSAA su R600 con il resolve via shader. Anche in questi casi non parliamo di emulazione ma il risultato è lo stesso Non vedo per quale motivo il tessellator su fermi debba fare eccezione

e grazie al ca@@o, se la metti così è evidente... ma il problema non è in questi termini: sennò io ti piazzo una ipotetica GPU con shader dedicati per vertex pixel geometry hull e domain grande 50000 mm2 con 10000 unità a testa e vediamo quale va più veloce. E' ovvio che si sta parlando di un solo elemento, per cui bisogna considerare il resto alla pari. Se prendo una gpu1 con 512+Tess+Hull+Domain e una gpu2 con 512+Tess è ovvio che la gpu1 è più veloce quando ci sono anche operazioni di tessellazione e va uguale altrimenti. Ma la gpu1 è più grande, perchè ha unità in più. Per paragonare i due differenti approcci al tessellatore bisogna aggiungere alla gpu2 qualche sp generico per pareggiare il die-size e per questo ho tirato fuori il 544, ponendo che 32sp occupassero l'area di Hull e domain dedicati. Ovviamente i numeri sono solo esempi ma il concetto mi sembra chiaro. Parlare di velocità della fase di tessellazione della gpu2 è del tutto irilevante, visto che a seconda di quanti sp dedico a hull e domain la velocità cambia (anche se il grosso lo fa il tessellator vero e prorpio che è fixed sempre e comunque). Quello che conta è che nonostante l'efficienza della tessellazione nella gpu1 è superiore a quella della gpu2 (basta vedere l'esempio dei msec che ho fatto in precedenza), in un frame questa fase è poca cosa rispetto a tutto il resto, che sarà più efficiente nella gpu2 rispetto alla gpu1 dato il numero maggiore di sp. Per cui considerato il lavoro svolto per tutto il frame, la gpu è più efficiente=più veloce.
Con questo non dico che fermi è meglio di cypress. Non ci sono ancora le prestazioni definitive, ma è molto probabile che fermi sia meno efficiente di cypress rapportando le prestazioni al die-size. Ma non centra nulla con quello di cui stiamo parlando

x calabar
hai capito cosa volevo dire

[Kharonte85]

Originariamente inviato da halduemilauno

la GTX470 in vendita in Cina per l'equivalente di 366$.
http://diy.yesky.com/vga/259/11163259.shtml

Originariamente inviato da zorco

per 350 euro o -,secondo tè riusciremo a papparcela quà in italia?...

Bè dai speriamo...350 ci potrei ancora stare...per quello che è probabile al momento, ovvero:

Specifiche:



Prestazioni fra la hd5850 e la HD5870 (ma più vicine a quest'ultima) ottime prestazioni con uso intensivo di Tesseletion, FPS più costanti (se i test sono veri), scheda lunga 24cm, consumo atteso attorno ai 190w.

[goten]

per 350€ deve andare meglio della 5870, pochi cazzi. Altrimenti non ha nessun senso.