[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[Foglia Morta]

Ma il GTC non è stato a Ottobre 2009?

9 - 13 Marzo: http://www.gdconf.com/

[veltosaar]

Ma come è possibile che la 4870x2 sia superiore alla 295.. bah.. sono proprio scettico.

[faber80]

la versione 1.1 di unigine heaven è, a detta degli stessi sviluppatori, ottimizzata per le operazioni di backface culling e permette di guadagnare il 30% sulle prestazioni rispetto alla 1.0

http://www.overclockear.com/foro/showthread.php?t=3350&language=en

http://twitter.com/binstream/status/9518230933

quindi nn sono cmq confrontabili, grazie yoss ;)
vorrei la tua opinione sul fatto che ormai insistono solo su tessellation, tralasciando completamente i test su strada, ovvero i videogame, che direbbero molto più di un semplice test.

[yossarian]

:eek:

traduco in termini più terra terra tenendo conto dell'architettura del tessellator di fermi.
Fare un test con molte meno superfici nascoste da renderizzare e senza AF, significa far lavoarre molto meno lo shader core sulle operazioni di rendering e per nulla su quelle di texture filtering; il risultato è che si possono dedicare meglio alle operazioni di tessellation. Il limite del tessellator di fermi è proprio quello che le stesse unità devono fare un gran numero di cose e quando si è in presenza di filtraggio texture, gestione della fisica con, in aggiunta, rendering pesante, la capacità di tessellation cala a picco.

[yossarian]

quindi nn sono cmq confrontabili, grazie yoss ;)
vorrei la tua opinione sul fatto che ormai insistono solo su tessellation, tralasciando completamente i test su strada, ovvero i videogame, che direbbero molto più di un semplice test.

leggi sopra

[PConly92]

traduco in termini più yerra terra tenendo conto dell'architettura del tessellator di fermi.
Fare un test con molte meno superfici nascoste da renderizzare e senza AF, significa far lavoarre molto meno lo shader core sulle operazioni di rendering e su quelle di texture filtering; il risultato è che si possono dedicare meglio alle operazioni di tessellation. Il limite del tessellator di fermi è proprio quello che le stesse unità devono fare un gran numero di cose e quando si è in presenza di filtraggio texture, gestione della fisica con, in aggiunta, rendering pesante, la capacità di tessellation cala a picco.

ahh ok grazie;) quindi se la gtx 470 venisse testata con unigine 1.0 avrebbe fps molto più bassi? questo mi sembra di capire...:confused:

[faber80]

leggi sopra

quello che pensavo (e temevo), grazie sempre yoss.... ;)

[luX0r.reload]

scusate l'ot ma adesso anche amd ha un "physx" pure gratis e multipiattaforma;)
http://www.techpowerup.com/117030/AMD_Open_Physics_Initiative_Expands_Ecosystem_with_Free_DMM_for_Game_Production.html
Da notare che anche cuda è open e multipiattaforma

http://en.wikipedia.org/wiki/CUDA

E' ATI che si è rifiutata (forse a ragione?) di implementare la cosa nei propri drivers

http://www.maximumpc.com/article/news/cuda_running_a_radeon

:rolleyes:

[Rsdj]

la versione 1.1 di unigine heaven è, a detta degli stessi sviluppatori, ottimizzata per le operazioni di backface culling e permette di guadagnare il 30% sulle prestazioni rispetto alla 1.0

http://www.overclockear.com/foro/showthread.php?t=3350&language=en

http://twitter.com/binstream/status/9518230933

E quando verrà rilasciata al pubblico la versione 1.1?

Cmq molto interessante anche la notizia sulla fisica open di AMD ;)

[PConly92]

Da notare che anche cuda è open e multipiattaforma

http://en.wikipedia.org/wiki/CUDA

E' ATI che si è rifiutata (forse a ragione?) di implementare la cosa nei propri drivers

http://www.maximumpc.com/article/news/cuda_running_a_radeon

:rolleyes:

certo che è open! ho solo segnalato la notizia visto che riguarda tutti;)
ati usa stream, non vedo perché utilizzare una tecnologia avversaria:confused:

[ghiltanas]

traduco in termini più terra terra tenendo conto dell'architettura del tessellator di fermi.
Fare un test con molte meno superfici nascoste da renderizzare e senza AF, significa far lavoarre molto meno lo shader core sulle operazioni di rendering e per nulla su quelle di texture filtering; il risultato è che si possono dedicare meglio alle operazioni di tessellation. Il limite del tessellator di fermi è proprio quello che le stesse unità devono fare un gran numero di cose e quando si è in presenza di filtraggio texture, gestione della fisica con, in aggiunta, rendering pesante, la capacità di tessellation cala a picco.

infatti sembra si stia andando sempre + verso l'utilizzo di 2 schede per usufruire di alcuni features ed effetti in +. Una scheda per il rendering e una per la fisica (che per quanto se ne possa dire, richiede un'elevata potenza di calcolo, quindi una scheda sola soffrirà sempre) e/o per il tesselation per esempio...E cmq anche la secondaria nn dev'essere di certo una ciofeca...

Per quanto riguarda la fisica sarebbe doveroso uno standard comune, e penso che se fermi venderà poco e ci sarà un'ulteriore rimescolamento del market share si potrà arrivare a ciò

[yossarian]

ahh ok grazie;) quindi se la gtx 470 venisse testata con unigine 1.0 avrebbe fps molto più bassi? questo mi sembra di capire...:confused:

rispetto a quelli ottenuti con la 1.1 di sicuro.

In ogni caso, unigine è un bel demo e raffigura un posto in cui vivrei volentieri, ma non lo prenderei sul serio per valutare le prestazioni di una vga in game. :D

[luX0r.reload]

Ma sempre delle stesse cose OT dobbiamo parlare?

CUDA non è affatto Open, e link che hai postato tu stesso lo dice chiaramente:

http://img138.imageshack.us/img138/5231/cuda.jpg (http://img138.imageshack.us/i/cuda.jpg/)

:rolleyes:
Non intendevo OpenSource... chiedo venia. Per open intendevo che può essere usato anche su piattaforma non nVidia.
Sono d'accordo con te... sempre i soliti off topic, ma siccome su cuda c'è molta disinformazione, ho postato due link "interessanti"... anche se erano già stati postati e ripostati.

Chiedo scusa per l'off topic ;)

[ghiltanas]

E' un peccato che non si possa dire a una scheda di fare solo la Tessellation ;)

perchè nn si potrebbe dedicare una scheda a fisica e tessellation? :confused:
gli shader sono programmabili, hull e domain le nvidia nn lo fanno mediante shader core? in + ci aggiungi l'unità per il tessellator ed ecco fatto :D -> scheda dedicata

[scorpion73]

E così ritorna l'idea che paventavo io un bel po' di tempo fa.
Ovvero che Nvidia sta facendo la furbata di costringere chi prese una schedina dedicata per physx a cambiarla prendendo di fatto due fermi, magari una GTX480 per il rendering e una GTX470 da dedicare a physx e tessellation, in modo da non far calare le performance.
Vedrete che a breve secondo me questa opzione uscirà magicamente dai Forceware.... e a me personalmente mi implica che dovrò vendere mezzo arsenale di schede video quando passerò a Fermi....

DOMANDINA (mi scuso per l'OT): secondo voi un ali da 750W le regge una 295 e una 280 AMP! insieme?

[veltosaar]

E così ritorna l'idea che paventavo io un bel po' di tempo fa.
Ovvero che Nvidia sta facendo la furbata di costringere chi prese una schedina dedicata per physx a cambiarla prendendo di fatto due fermi, magari una GTX480 per il rendering e una GTX470 da dedicare a physx e tessellation, in modo da non far calare le performance.
Vedrete che a breve secondo me questa opzione uscirà magicamente dai Forceware.... e a me personalmente mi implica che dovrò vendere mezzo arsenale di schede video quando passerò a Fermi....

DOMANDINA (mi scuso per l'OT): secondo voi un ali da 750W le regge una 295 e una 280 AMP! insieme?

Se è un buon alimentatore si..

corsair, enermax, seasonic.

[ghiltanas]

E dopo che i triangoli sono stati preparati si passa tutta la pappardella per il PCIe per rimandarli tutti all'altra scheda (la quale è stata istruita a dovere dal driver sul girarsi i pollici mentre attende i triangoli)?

certamente :D

ok lo ammetto potrei aver detto la cazzata del giorno, potrei :fiufiu:

[veltosaar]

una utile(credo/spero)corposa rece che raffigura + o - l'attuale situazione, il tutto ovviamente in vista delle nuove GTX.
http://www.hardware.fr/articles/784-10/comparatif-geant-89-gpu-nvidia-ati-amd.html
(passateci sopra con il mouse).
qui il link generale...
http://www.hardware.fr/articles/784-1/comparatif-geant-89-gpu-nvidia-ati-amd.html

Secondo voi è attendibile? A me pare impossibile una 4870x2 che spinge più della gtx295!

http://www.hardware.fr/medias/photos_news/00/28/IMG0028099.gif

[veltosaar]

Hai ragione. Ragionissima anzi.

Solo che era stato postato precedentemente e si asseriva che i nuovi driver Ati (comprese 5970 e 5870 quindi) vanno una bomba..

Quindi mi chiedevo vedendolo se era possibile che Ati aveva scalato così tanto su Nvidia anche in campo Driver.. a questo punto per Fermi si mette male.

Temo proprio per la concorrenza guarda.

[scorpion73]

se questo è vero la mossa finale sarebbe l'implementazione di PhysX anche per ATI... e allora penso che sarebbero dolori.
Mi auguro di no, ma per Fermi comincio a vederla buia pure io che sono sempre stato fiducioso...

[Iantikas]

Secondo voi è attendibile? A me pare impossibile una 4870x2 che spinge più della gtx295!

http://www.hardware.fr/medias/photos_news/00/28/IMG0028099.gif

il risultato globale non'è altro che il frutto dei vari singoli test effettuati...e se confronti i singoli risultati dei 4 giochi testati alle varie impo è tutto in linea con quello che fanno vedere altre rece...


...solo che lì fermandosi solo a quei 4 giochi (io avrei preferito una ventina di gpu in meno, ce ne son parecchie molto simili che potevano evitare, e 3/4 giochi in più) e inserendo nel globale anche i test a qualità più basse poi di media s'ottiene quel risultato...


...l'indice globale di quella rece cmq lo trovo fuorviante perchè di parecchie gpu (soprattutto di quelle più vecchiotte) da un quadro molto differente a quello che s'ottiene analizzando le singole prove (soprattutto se uno si sofferma sulle impo più adatte ad ognuna scheda per ottenere il miglior gameplay)...



....ciao

[aledemo]

Secondo voi è attendibile? A me pare impossibile una 4870x2 che spinge più della gtx295!


in alcuni giochi e situazioni si!

http://www.hwupgrade.it/articoli/skvideo/2326/fc2_s_2560.png

http://www.hwupgrade.it/articoli/skvideo/2326/fc2_s_1920.png

http://www.hwupgrade.it/articoli/skvideo/2326/crysis_whead_2560.png

forse quando la 295 satura la memoria non so..

[Qetzalcoatl]

la 5890 uscirà indipendentemente da fermi (la tua impressione sulla mancanza di una marcatura su GF100 è esatta) perchè serve, comunque, ad AMD per capire i limiti di questa architettura in funzione del passaggio ai 28 nm.
D'altra parte, fermi non pare costituire un problema stando a quello che è trapelato finora su presunti prezzi, disponibilità e prestazioni.

Non riesco a posizionare bene però il processo a 28nm, ma più che una 5890 (in pratica una sorta di spremitura dell'architettura attuale, sempre sullo stesso processo, come fu 4890) per testare il nuovo processo sarei orientato a pensare ad un cypress light (qualcosa di dimensioni simili a Juniper ma prestazioni vicino a cypress) cioè qualcosa di comunque abbastanza grosso e complesso da essere un punto di partenza per la nuova architettura, ma sufficientemente contenuto da essere sviluppato in tempi utili. Però mi pare ottimistico vederlo arrivare per il prossimo anno, sarà che i 40nm inducono alla cautela, e non riesco a farci rientrare l'attuale policy di AMD di rilasciare una nuova architettura ogni 12-14 mesi (Anche un NI a fine anno su 40nm è un azzardo comunque se il numero di transistor salirà).
Ma, anche per rientrare dal clamoroso OT, non so cosa pensare neanche del silenzio (o quasi) sull'ipotetico gf104, con il ritardo accumulato dalla fascia alta, posto che fermi è un architettura che appare alquanto modulare, uno penserebbe che sia praticamente bello e pronto per il debutto. Non saprei quanto Nvidia voglia evitare di togliere attenzione al top della gamma visto che contro juniper soffre anche di più che contro cypress (le 5770 non hanno avuto apprezzamenti ma mi sembrano ancora restie nel calare di prezzo, e non sono partite proprio basse).

[yossarian]

Hai ragione. Ragionissima anzi.

Solo che era stato postato precedentemente e si asseriva che i nuovi driver Ati (comprese 5970 e 5870 quindi) vanno una bomba..

Quindi mi chiedevo vedendolo se era possibile che Ati aveva scalato così tanto su Nvidia anche in campo Driver.. a questo punto per Fermi si mette male.

Temo proprio per la concorrenza guarda.

OT per OT, mi pare che questi risultati siano abbastanza in linea con questi altri

http://www.computerbase.de/artikel/hardware/grafikkarten/2009/test_grafikkarten_2009/18/#abschnitt_performancerating_qualitaet

dove manca la 4870x2 ma si può fare il confronto tra 295 e 5870

[yossarian]

Non riesco a posizionare bene però il processo a 28nm, ma più che una 5890 (in pratica una sorta di spremitura dell'architettura attuale, sempre sullo stesso processo, come fu 4890) per testare il nuovo processo sarei orientato a pensare ad un cypress light (qualcosa di dimensioni simili a Juniper ma prestazioni vicino a cypress) cioè qualcosa di comunque abbastanza grosso e complesso da essere un punto di partenza per la nuova architettura, ma sufficientemente contenuto da essere sviluppato in tempi utili. Però mi pare ottimistico vederlo arrivare per il prossimo anno, sarà che i 40nm inducono alla cautela, e non riesco a farci rientrare l'attuale policy di AMD di rilasciare una nuova architettura ogni 12-14 mesi (Anche un NI a fine anno su 40nm è un azzardo comunque se il numero di transistor salirà).
Ma, anche per rientrare dal clamoroso OT, non so cosa pensare neanche del silenzio (o quasi) sull'ipotetico gf104, con il ritardo accumulato dalla fascia alta, posto che fermi è un architettura che appare alquanto modulare, uno penserebbe che sia praticamente bello e pronto per il debutto. Non saprei quanto Nvidia voglia evitare di togliere attenzione al top della gamma visto che contro juniper soffre anche di più che contro cypress (le 5770 non hanno avuto apprezzamenti ma mi sembrano ancora restie nel calare di prezzo, e non sono partite proprio basse).

NI non uscirà entro quest'anno.
Le tappe consuete sono:
- ottimizzazione del pp
- sviluppo di un'architettura basata su quel pp
- ottimizzazione della nuova architettura in relazione al pp adottato
- ricerca di un nuovo pp da adottare per le future architetture.

Ovviamente il processo è ciclico.
ATi è partita dall'architettura di Rv770 per collaudare i 40 nm e, ovviamente, l'ha fatto con un chip di fascia media (o medio-bassa) perchè è più semplice da gestire. Poi è passata ad adottare i 40 nm con la nuova architettura. Adesso deve lavorare ad ottimizzare l'architettura di RV870. Infine, quando avrà completato questo step (in cui si inserisce la 5890) passerà ai 28 nm con un chip di fascia media derivato da cypress.
Teoricamente si potrebbe anche ottimizzare l'attuale architettura e il relativo pp e pensare di adottare i 40 nm per la successiva architettura (e poi eseguire la transizione al pp successivo con un nuovo chip di fascia media). Ma questa seconda strada è solitamente meno percorribile perchè i nuovi porgetti sono caratterizzati da architetture molto più complesse della precedente generazione, il che porta inevitabilemente a realizzare chip troppo grossi e antieconomici (quello che è avvenuto con R600)

[Qetzalcoatl]

traduco in termini più terra terra tenendo conto dell'architettura del tessellator di fermi.
Fare un test con molte meno superfici nascoste da renderizzare e senza AF, significa far lavoarre molto meno lo shader core sulle operazioni di rendering e per nulla su quelle di texture filtering; il risultato è che si possono dedicare meglio alle operazioni di tessellation. Il limite del tessellator di fermi è proprio quello che le stesse unità devono fare un gran numero di cose e quando si è in presenza di filtraggio texture, gestione della fisica con, in aggiunta, rendering pesante, la capacità di tessellation cala a picco.

Sono un po' arrugginito ma, per capirci, la versione di unigine 1.0 renderizzava anche le superfici nascoste? Mi sembrava un qualcosa che per i motori grafici moderni (ma neanche troppo) fosse andata in disuso (sono fermo allo Z only pass, ma già quella era una tecnica che si apprezzava particolarmente con le architetture a shaders unificati rispetto a quelle "classiche").
Addirittura mi era passato per la mente che il culling era relativo invece ai vertici nascosti (e di conseguenza alle operazioni di tessellation) ma evidentemente ero davvero ottimista a riguardo (che poi paradossalmente ridurre del 70% (0% il carico poligonale della scena avvantaggerebbe forse l'architettura ATI sutup limited rispetto a Fermi).

[yossarian]

Sono un po' arrugginito ma, per capirci, la versione di unigine 1.0 renderizzava anche le superfici nascoste? Mi sembrava un qualcosa che per i motori grafici moderni (ma neanche troppo) fosse andata in disuso (sono fermo allo Z only pass, ma già quella era una tecnica che si apprezzava particolarmente con le architetture a shaders unificati rispetto a quelle "classiche").
Addirittura mi era passato per la mente che il culling era relativo invece ai vertici nascosti (e di conseguenza alle operazioni di tessellation) ma evidentemente ero davvero ottimista a riguardo (che poi paradossalmente ridurre del 70% (0% il carico poligonale della scena avvantaggerebbe forse l'architettura ATI sutup limited rispetto a Fermi).

i motori di tipo deferred hanno iniziato a metterli a punto con la generazione dx9 ma, ancora oggi, non sono tutti di quel tipo anche a causa dello scarso sviluppo di engine dx10. Questo eprchè le gpu dx9 non possono far uso di MSAA con deferred rendering e la stragrande maggioranza dei motori grafici sono stati sviluppati, per ora, su gpu dx9 o antecedenti.
Per quanto riguarda la pipeline di una gpu, ad oggi, non c'è ancora l'equivalente del TBR fatto vedere da PowerVR.
http://images.anandtech.com/reviews/video/ATI/5870/CypressLarge.jpg

Dallo schema puoi vedere che c'è sempre l'hyper-z (ovviamente migliorato) che fa una prima scrematura delle superfici nascoste, a valle del tessellator. Poi i dati geometrici finiscono nelle ROP's dove, a valle delle operazioni di rendering, c'è un ulteriore stadio che fa z-compare ed elimina le superfici residuali (ma solo dopo che è stato effettuato il rendering)

[dj883u2]

rispetto a quelli ottenuti con la 1.1 di sicuro.

In ogni caso, unigine è un bel demo e raffigura un posto in cui vivrei volentieri, ma non lo prenderei sul serio per valutare le prestazioni di una vga in game. :D

Che romantico che sei!:asd:

[yossarian]

Che romantico che sei!:asd:

Anto', che vuoi che ti dica: sono un ragazzo di campagna e mi è rimasto un animo agreste e bucolico :p

[dj883u2]

Anto', che vuoi che ti dica: sono un ragazzo di campagna e mi è rimasto un animo agreste e bucolico :p

Sei il igliore!;)

[Qetzalcoatl]

Ok comincio a vedere la luce. In poche parole per Deffered Rendering si intende appunto di fare una passata preventiva per identificare la superficie visibile e limitare il rendering successivo solo a quella. Non so perché l'ho sempre considerato un ulteriore evoluzione, ma non ho mai approfondito la cosa. L'ultima volta che mi sono addentrato in tecnicismi del genere era stata presentata l'architettura di Xenos (R500) e ora che ci penso fa un po strano che effettivamente Microsoft raccomandava all'epoca di usare la Z only pass dato che in pratica avrebbe invalidato la feature più declamata dell'architettura (l'AA "quasi" free). Grazie delle spiegazioni comunque, assolutamente impagabile.

[The_SaN]

veramente la 4870 da 1 GB sta alla pari della 260 216 :read: Si si, mi riferivo alla 512, che poi é quella che é uscita insieme alla gtx260 192. :)
PowerVRBei tempi quelli...
PowerVR, 3dfx, matrox, nvidia e ati che se le davano di santa ragione :cry:

Ma sarebbe difficile oggi implementare un'equivalente del TBR con le tecnologie a disposizione?
Ero un po' troppo giovane per capirci qualcosa ai tempi, e non so esattamente come funziona.

[Crysis90]

Da buon italiano poco dotto non ci ho capito una mazza :D . Potete darmi delucidazioni su cosa c'è scritto? :D

Semplice, c'è scritto che un sacco di gente installando i drivers 196.75, hanno avuto la bella sorpresina: gli si è fritta la VGA!! Il fatto ha fatto incavolare un sacco di clienti e anche i partners, dato che dovranno accettare le richieste di RMA di chi ha subito il danno, perciò dovranno "regalare" delle schede video solo per colpa di NVidia...

Io dico solo una cosa, questo è un altro fatto che testimonia che questi quì si, SECONDO ME, sono COMPLETAMENTE bevuti il cervello. E parlo io che sono sempre stato cliente NVidia...

[Adone_1985]

Semplice, c'è scritto che un sacco di gente installando i drivers 196.75, hanno avuto la bella sorpresina: gli si è fritta la VGA!! Il fatto ha fatto incavolare un sacco di clienti e anche i partners, dato che dovranno accettare le richieste di RMA di chi ha subito il danno, perciò dovranno "regalare" delle schede video solo per colpa di NVidia...

Io dico solo una cosa, questo è un altro fatto che testimonia che questi quì si, SECONDO ME, sono COMPLETAMENTE bevuti il cervello. E parlo io che sono sempre stato cliente NVidia...

hai ragione in parte....

questa cosa è successa in un momento un po' brutto per nvidia e quindi è stata la goccia che ha fatto trabboccare il vaso...

cm

[A.L.M.]

Si si, mi riferivo alla 512, che poi é quella che é uscita insieme alla gtx260 192. :)
Bei tempi quelli...
PowerVR, 3dfx, matrox, nvidia e ati che se le davano di santa ragione :cry:

Ma sarebbe difficile oggi implementare un'equivalente del TBR con le tecnologie a disposizione?
Ero un po' troppo giovane per capirci qualcosa ai tempi, e non so esattamente come funziona.

Se non mi sbaglio il TBR è ancora usato più di quanto non si creda. Le gpu degli iPhone (e di tanti altri telefoni di fascia alta) infatti sono PowerVR. ;)

[Adone_1985]

edit

[kingpix22]

edit

[Adone_1985]

edit

[betha]

edit

[mapoetti]

edit

[davide155]

edit

[Diobrando_21]

edit

[Adone_1985]

edit

[davide155]

edit

[Adone_1985]

edit

[Diobrando_21]

edit

[Rsdj]

si, il discorso è tutto qui...per me l'OT finisce qui....vado a giocare a Mass Effect 2, bella ;)

Ma lascia stare ME2, piuttosto fatti un giro a Bad Company 2!! :D

Cmq ho notato che da quando si è chiuso il CeBIT non ci sono più in giro grosse notizie... non che abbiamo avuto chissà quali notizie però almeno qualcosa si muoveva... secondo voi tra quanto inizieranno ad arrivare le prime notizie attendibili? Intendo prima del 26 marzo... :D

[ghiltanas]

nn so se era già stato postato:

http://www.semiaccurate.com/2010/03/08/nvidias-gtx480-case-dissected/

[gianni1879]

Semplice, c'è scritto che un sacco di gente installando i drivers 196.75, hanno avuto la bella sorpresina: gli si è fritta la VGA!! Il fatto ha fatto incavolare un sacco di clienti e anche i partners, dato che dovranno accettare le richieste di RMA di chi ha subito il danno, perciò dovranno "regalare" delle schede video solo per colpa di NVidia...

Io dico solo una cosa, questo è un altro fatto che testimonia che questi quì si, SECONDO ME, sono COMPLETAMENTE bevuti il cervello. E parlo io che sono sempre stato cliente NVidia...
si era detto basta, considerati ammonito, ci sono le apposite discussioni dove se ne parla
hai ragione in parte....

questa cosa è successa in un momento un po' brutto per nvidia e quindi è stata la goccia che ha fatto trabboccare il vaso...

cm
come sopra

[appleroof]

rispetto a quelli ottenuti con la 1.1 di sicuro.

In ogni caso, unigine è un bel demo e raffigura un posto in cui vivrei volentieri, ma non lo prenderei sul serio per valutare le prestazioni di una vga in game. :D

quindi Fermi andrebbe meglio in game... :asd:

io invece credo che i test sintetici siano utili a dare molte indicazioni che poi, con le dovute proporzioni, possono ritrovarsi nei giochi...di certo non sono da prendere come oro colato, questo si

[gianni1879]

quindi Fermi andrebbe meglio in game... :asd:

io invece credo che i test sintetici siano utili a dare molte indicazioni che poi, con le dovute proporzioni, possono ritrovarsi nei giochi...di certo non sono da prendere come oro colato, questo si

in realtà non è proprio così, si è visto spesso che vga andavano forte nei vari bench sintetici e poi in game erano invertite le sorti.

[Severnaya]

i test sintetici vanno bene solo nel momento in cui si osserva a parità di sistema il cambio di 1 solo componente e si osserva il risultato, confrontare unigine o un 3dmark con un gioco reale nn ha senso

[appleroof]

in realtà non è proprio così, si è visto spesso che vga andavano forte nei vari bench sintetici e poi in game erano invertite le sorti.

per quello usavo parole come "indicazioni", "dovute proporzioni" ecc

è ovvio che un test sintetico di per sè non basta ed infatti nelle rece è sempre affiancato da più giochi; però ad esempio nemmeno 1 gioco di per sè non basta dipende da come è programmato: anni fà hl2 era fatto su misura di Ati, Doom 3 per Nvidia

diciamo che il test perfetto non esiste perchè Ati e Nvidia da sempre, pur avendo linee guida simili, hanno interpretato le stesse con molte differenze, per cui per forza questa applicazione piuttosto che l'altra andrà meglio sull'una o sull'altra

su unigine la vedo così: poichè implementa la tassellazione in modo massiccio mentre renderizza, mi dà un'idea di come una vga X si comporterà nei giochi futuri; difatti, se è vero che la tassellazione non verrrà mai implementata in quel modo massiccio nei giochi (almeno nei primi dx11), allora l'approccio di Nvidia potrebbe rivelarsi più equilibrato

[Pat77]

Io aspetto la seconda parte dell'articolo di Yossarian sul Tesselator, il primo era molto molto interessante per capire come funziona, il secondo dovrebbe accennare alle interpretazioni Ati e Nvidia dello stesso, e magari accennerà anche all'unigine e il perchè va meglio x o y nell'ambito specifico.
Credo sia il modo migliore per voler entrare nello specifico senza schieramenti e forse sapere meglio cosa ci aspetta fuori dai proclami di marketing.

[faber80]

diciamo che il test perfetto non esiste perchè Ati e Nvidia da sempre, pur avendo linee guida simili, hanno interpretato le stesse con molte differenze, per cui per forza questa applicazione piuttosto che l'altra andrà meglio sull'una o sull'altra

ecco perchè il test unigine vale meno di zero, poichè calcola solo ed esclusivamente una variante; è lo stesso discorso del physx, una vga che fa solo quello va anche bene, ma se a quella vga fai fare anche il resto..... sappiamo tutti come va. Il discorso tessellator dedicato o emulato è ancora prematuro; ci sono pro/contro in entrambi i casi.

[appleroof]

ecco perchè il test unigine vale meno di zero, poichè calcola solo ed esclusivamente una variante; è lo stesso discorso del physx, una vga che fa solo quello va anche bene, ma se a quella vga fai fare anche il resto..... sappiamo tutti come va. Il discorso tessellator dedicato o emulato è ancora prematuro; ci sono pro/contro in entrambi i casi.

non è vero, infatti mentre è attiva la tassellazione è attiva anche la "classica" renderizzazione (quest'ultima la puoi escludere ma normalmente il test è fatto "completo")

[faber80]

non è vero, infatti mentre è attiva la tassellazione è attiva anche la "classica" renderizzazione (quest'ultima la puoi escludere ma normalmente il test è fatto "completo")

ah :D mea culpa, pensavo alla sola tessellazione...

[appleroof]

ah :D mea culpa, pensavo alla sola tessellazione...

:asd:

[faber80]

:asd:

ormai ho gli incubi tessellati :asd:

[skizzo99999999]

Vorrei fornire un mio contributo per tentare di dirimere la questione sulla tessellazione, visto che mi sembra che non se ne esca.
Il fatto che le operazioni di vertex shading, tessellation, pixel shading, ecc... siano parallelizzabili nonostante facciano parte di una pipeline è corretto, per il semplice fatto che quello che può elaborare in parallelo di uno "stadio" della pipeline (prendiamo come esempio il pixel shading che è molto facile da spiegare) anche di una moderna GPU è una parte microscopica di quello che bisogna fare per ogni frame.
Si parte infatti sempre dall'assunto che ogni frame dipende da quello successivo (magari non sempre nella parte grafica, ma per la fisica, IA e altra roba si), per cui prima di elaborare i pixel del frame successivo si devono elaborare tutti i pixel di quello attuale. Ma se prendiamo ad esempio anche una risoluzione ridicola come 800x600, quanti pixel abbiamo? 800x600=480000, un po troppi anche per le 512sp di fermi... questo perchè ogni shader agisce su ogni pixel, per cui deve essere calcolato per ogni singolo pixel. Ecco perchè gli shader sui pixel (sarebbe più corretto parlare di fragment, ma con pixel ci si capisce meglio) occupano una enorme quantità di tempo nella generazione del frame rispetto, per esempio agli shader per i vertex. E' in quest'ottica che si deve vedere il passaggio da unità per vertex e pixel agli shader unificati. Il tempo di calcolo per ogni pixel è aumentato, ma siccome ci sono + unità disponibili allora il tempo totale per il calcolo del frame è diminuito, oltre al fatto che così sicuramente non si avranno mai sp inutilizzati, visto che vertex o pixel qualcosa da fargli fare sempre ci sarà.

A prima vista anche qui si potrebbe fare la stessa osservazione per quanto riguarda il "sottrarre le risorse" nel discorso sul tessellatore. Cerco di spiegarmi meglio cercando di essere breve. Se ho 10 vertex e 10 pixel nella GPU1 e ho 20 sp unificate nella GPU2, in totale ho sempre 20 sp. Nella GPU2, potrebbero esserci momenti in cui avrò 3 sp che fanno vertex shading e 17 pixel shading. Si potrebbe dire che i 3 sp stanno sottraendo risorse che sarebbero utili per i pixel shader da eseguire (che come detto sopra sono, alla meglio, centinaia di migliaia di pixel da elaborare). Il fatto è che io comunque i calcoli sui vertex li devo pur fare, e per non "sottrarre" risorse allo shading per i pixel dovrei avere unità dedicate per i vertex. Ma allora, per lasciare inalterata la dimensione fisica della GPU dovrei ridurre il numero si sp disponibili per i pixel e quindi ritornerei di nuovo con solo 17 sp per i pixel. Questo presupponendo che unità dedicate occupino lo stesso spazio di quello generiche e che si tralasci il fattore velocità (le dedicate sono + veloci delle generiche). Ovviamente non è così, ma è per rendere più semplice la questione che voglio spiegare. Ovviamente questo rapporto 3/17 varia sempre, è già questo è un segno che la GPU2 avrà una marcia in più. Quindi in realtà non si sottrae niente: se io ho 10000 vertici e 500000 pixel prima o poi le devo elaborare tutti. L'obbiettivo è tenere il più possibile occupato tutto quello che ho a disposizione. Unificando i vertex e pixel si è visto che la perdita di velocità era più che compensata dall'utilizzo sempre totale di tutto quello che era disponibile.

Il discorso per il tessellator è più o meno lo stesso. Non bisogna vedere come "emulati" (che poi non è neanche così corretto: sempre shader, cioè programmi, sono) hull e domain shader. Iniziamo con due concetti:
1) Sicuramente l'operazione più dispensiona della pipeline della tessellazione è largamente quella del tesellator e non quella di hull e domain, almeno se usata con giudizio e non a sproposito (visto che si tratta sempre di shader che scrive il programmatore, può sempre fare cazzate). Non mi sembra utile ai fini del discorso spiegare nei dettagli si cosa si occupano questi due stadi, per cui sorvoliamo.
2) Un'altra cosa che mi sembra essenziale dire è che non si può parlare di fixed function. Per il tessellator si, ma non per hull shader e domain shader. Proprio il nome dovrebbe già dare un indizio... Vengono caricati programmi proprio come per i vertex, pixel e geometry shader, anche se l'input/output è ovviamente molto più vincolante. Proprio per questo passare da una unità dedicata a un sp generico non comporta un rallentamento terrificante.

Chiariti questi 2 punti veniamo al succo del discorso. Avendo in mente l'analogia di GPU1 e GPU2 precedente prendiamo il caso di fermi: ho 512 sp 16 tessellator (GPU1). Se avessi hull e domain separati, avrei meno sp; tanto per fare un esempio facciamo 480, cioè 2 sp (hull e domain) per ogni tessellator (GPU2). in realtà sicuramente ne servirebbero di più e non sarebbe una equivalenza 1:1 in termini di spazio come già detto, ma facciamo finta di si per semplificare. Ricapitolando, in questo modo in apparenza non sottrarrei nulla: io avrei sempre disponibili i miei 480sp, ma quando non ho niente da tessellare i 32 dedicati sarebbero "buttati". Anche qui quindi, bisogna guardare le cose da un'altra prospettiva: ho 100000 vertici da processare, 10000 vertici da tessellare, 500000 pixel da elaborare. Ogni tanto nella GPU1 potrò utilizzare + di 480 sp, e ogni tanto meno, ma visto che in totale, per quanto riguarda i pixel, ne avrò sempre 500000, almeno userò SEMPRE tutto quello che ho a disposizione. Come vedete non si sottrae proprio niente: se avessi roba dedicata gli sp generici in + usati per hull e domain non li avrei proprio.
Se veramente il cambio di "ruolo" negli sp fosse sempre 1:1 come velocità e dimensione allora il problema non si porrebbe nemmeno: sarebbe sempre meglio avere più roba generica possibile. Ma siccome non è così bisogna valutare di volta in volta e progetto per progetto. La tessellazione però è una delle cose che si presta con più efficienza a questo giochino (per hull e domain), visti i punti 1 e 2 speficicati sopra. Inoltre saggiamente NVIDIA ha, almeno nelle intenzioni, potenziato in modo significativo il tessellator vero e prorpio rispetto alla soluzione di ATI. per cui il tempo che perde nelle fasi di hull e domain dovrebbe, almeno nelle intenzioni, essere più che compensato dalla maggior velocità del tessellator. Quindi la situazione dovrebbe avere moltissimi vantaggi e pochi svantaggi. Uno degli svantaggi è sicuramente il maggior casino nel dimensionare correttamente bus & cache per gestire il flusso di dati da e verso gli sp, che devono gestire risorse per più compiti.
Ovviamente questo non vuol dire che Fermi sarà una GPU molto performante, ma soltanto che questa particolare scelta architetturale per la tessellazione è più complicata da gestire sotto l'aspetto progettuale ma è altamente probabile che sia più efficiente.

[aledemo]

speriamo che non sia un po come la ps3 che su carta con sto cell doveva essere una bestia e poi complicatissima da programmare ci si ritrova con risultati piu scadenti del 360...

era x vedere il lato drastico della cosa eh..non credo che sia la stessa cosa..

[zorco]

io spero e credo che le gpu fermi non saranno da meno rispetto alle attuali proposte ati,il problema principale al meno parlo per mè,lo farà il prezzo

[Alex656]

speriamo che non sia un po come la ps3 che su carta con sto cell doveva essere una bestia e poi complicatissima da programmare ci si ritrova con risultati piu scadenti del 360...

era x vedere il lato drastico della cosa eh..non credo che sia la stessa cosa..

Non credo che l'analogia sia tanto azzeccata; nel caso di PS3 il programmatore del gioco è obbligato ad uscire dal "seminato" delle directx di Pc ed Xbox, per Fermi chi programma il gioco continuerà a lavorare ad alto livello.............la complicazione sarà più per chi deve scrivere ed ottimizzare i driver, ovvero per gli stessi ingegneri Nvidia.

[Pike79]

Grazie Skizzo, bella spiegazione! :)

[yossarian]

quindi Fermi andrebbe meglio in game... :asd:

io invece credo che i test sintetici siano utili a dare molte indicazioni che poi, con le dovute proporzioni, possono ritrovarsi nei giochi...di certo non sono da prendere come oro colato, questo si

sono sempre stato un convinto fautore dei bench sintetici ma solo se questi sono eseguiti a parità di condizioni. NOn posso far girare il 3dmark 2001 su una vga e il 3dmark2003 su un'altra e trarre conclusioni in merito sulle prestazioni relative :D

Vorrei fornire un mio contributo per tentare di dirimere la questione sulla tessellazione, visto che mi sembra che non se ne esca.
Il fatto che le operazioni di vertex shading, tessellation, pixel shading, ecc... siano parallelizzabili nonostante facciano parte di una pipeline è corretto, per il semplice fatto che quello che può elaborare in parallelo di uno "stadio" della pipeline (prendiamo come esempio il pixel shading che è molto facile da spiegare) anche di una moderna GPU è una parte microscopica di quello che bisogna fare per ogni frame.
Si parte infatti sempre dall'assunto che ogni frame dipende da quello successivo (magari non sempre nella parte grafica, ma per la fisica, IA e altra roba si), per cui prima di elaborare i pixel del frame successivo si devono elaborare tutti i pixel di quello attuale. Ma se prendiamo ad esempio anche una risoluzione ridicola come 800x600, quanti pixel abbiamo? 800x600=480000, un po troppi anche per le 512sp di fermi... questo perchè ogni shader agisce su ogni pixel, per cui deve essere calcolato per ogni singolo pixel. Ecco perchè gli shader sui pixel (sarebbe più corretto parlare di fragment, ma con pixel ci si capisce meglio) occupano una enorme quantità di tempo nella generazione del frame rispetto, per esempio agli shader per i vertex. E' in quest'ottica che si deve vedere il passaggio da unità per vertex e pixel agli shader unificati. Il tempo di calcolo per ogni pixel è aumentato, ma siccome ci sono + unità disponibili allora il tempo totale per il calcolo del frame è diminuito, oltre al fatto che così sicuramente non si avranno mai sp inutilizzati, visto che vertex o pixel qualcosa da fargli fare sempre ci sarà.

A prima vista anche qui si potrebbe fare la stessa osservazione per quanto riguarda il "sottrarre le risorse" nel discorso sul tessellatore. Cerco di spiegarmi meglio cercando di essere breve. Se ho 10 vertex e 10 pixel nella GPU1 e ho 20 sp unificate nella GPU2, in totale ho sempre 20 sp. Nella GPU2, potrebbero esserci momenti in cui avrò 3 sp che fanno vertex shading e 17 pixel shading. Si potrebbe dire che i 3 sp stanno sottraendo risorse che sarebbero utili per i pixel shader da eseguire (che come detto sopra sono, alla meglio, centinaia di migliaia di pixel da elaborare). Il fatto è che io comunque i calcoli sui vertex li devo pur fare, e per non "sottrarre" risorse allo shading per i pixel dovrei avere unità dedicate per i vertex. Ma allora, per lasciare inalterata la dimensione fisica della GPU dovrei ridurre il numero si sp disponibili per i pixel e quindi ritornerei di nuovo con solo 17 sp per i pixel. Questo presupponendo che unità dedicate occupino lo stesso spazio di quello generiche e che si tralasci il fattore velocità (le dedicate sono + veloci delle generiche). Ovviamente non è così, ma è per rendere più semplice la questione che voglio spiegare. Ovviamente questo rapporto 3/17 varia sempre, è già questo è un segno che la GPU2 avrà una marcia in più. Quindi in realtà non si sottrae niente: se io ho 10000 vertici e 500000 pixel prima o poi le devo elaborare tutti. L'obbiettivo è tenere il più possibile occupato tutto quello che ho a disposizione. Unificando i vertex e pixel si è visto che la perdita di velocità era più che compensata dall'utilizzo sempre totale di tutto quello che era disponibile.

Il discorso per il tessellator è più o meno lo stesso. Non bisogna vedere come "emulati" (che poi non è neanche così corretto: sempre shader, cioè programmi, sono) hull e domain shader. Iniziamo con due concetti:
1) Sicuramente l'operazione più dispensiona della pipeline della tessellazione è largamente quella del tesellator e non quella di hull e domain, almeno se usata con giudizio e non a sproposito (visto che si tratta sempre di shader che scrive il programmatore, può sempre fare cazzate). Non mi sembra utile ai fini del discorso spiegare nei dettagli si cosa si occupano questi due stadi, per cui sorvoliamo.
2) Un'altra cosa che mi sembra essenziale dire è che non si può parlare di fixed function. Per il tessellator si, ma non per hull shader e domain shader. Proprio il nome dovrebbe già dare un indizio... Vengono caricati programmi proprio come per i vertex, pixel e geometry shader, anche se l'input/output è ovviamente molto più vincolante. Proprio per questo passare da una unità dedicata a un sp generico non comporta un rallentamento terrificante.

Chiariti questi 2 punti veniamo al succo del discorso. Avendo in mente l'analogia di GPU1 e GPU2 precedente prendiamo il caso di fermi: ho 512 sp 16 tessellator (GPU1). Se avessi hull e domain separati, avrei meno sp; tanto per fare un esempio facciamo 480, cioè 2 sp (hull e domain) per ogni tessellator (GPU2). in realtà sicuramente ne servirebbero di più e non sarebbe una equivalenza 1:1 in termini di spazio come già detto, ma facciamo finta di si per semplificare. Ricapitolando, in questo modo in apparenza non sottrarrei nulla: io avrei sempre disponibili i miei 480sp, ma quando non ho niente da tessellare i 32 dedicati sarebbero "buttati". Anche qui quindi, bisogna guardare le cose da un'altra prospettiva: ho 100000 vertici da processare, 10000 vertici da tessellare, 500000 pixel da elaborare. Ogni tanto nella GPU1 potrò utilizzare + di 480 sp, e ogni tanto meno, ma visto che in totale, per quanto riguarda i pixel, ne avrò sempre 500000, almeno userò SEMPRE tutto quello che ho a disposizione. Come vedete non si sottrae proprio niente: se avessi roba dedicata gli sp generici in + usati per hull e domain non li avrei proprio.
Se veramente il cambio di "ruolo" negli sp fosse sempre 1:1 come velocità e dimensione allora il problema non si porrebbe nemmeno: sarebbe sempre meglio avere più roba generica possibile. Ma siccome non è così bisogna valutare di volta in volta e progetto per progetto. La tessellazione però è una delle cose che si presta con più efficienza a questo giochino (per hull e domain), visti i punti 1 e 2 speficicati sopra. Inoltre saggiamente NVIDIA ha, almeno nelle intenzioni, potenziato in modo significativo il tessellator vero e prorpio rispetto alla soluzione di ATI. per cui il tempo che perde nelle fasi di hull e domain dovrebbe, almeno nelle intenzioni, essere più che compensato dalla maggior velocità del tessellator. Quindi la situazione dovrebbe avere moltissimi vantaggi e pochi svantaggi. Uno degli svantaggi è sicuramente il maggior casino nel dimensionare correttamente bus & cache per gestire il flusso di dati da e verso gli sp, che devono gestire risorse per più compiti.
Ovviamente questo non vuol dire che Fermi sarà una GPU molto performante, ma soltanto che questa particolare scelta architetturale per la tessellazione è più complicata da gestire sotto l'aspetto progettuale ma è altamente probabile che sia più efficiente.

ciao skizzo, quello che dici su unità dedicate e generiche è vero, ma ciò non toglie che quando ho unità generiche che si occupano di tante cose, all'aumentare della tipologia o dei carichi di lavoro di una o più elaborazioni portate avanti in parallelo, diminuisce la velocità con cui vengono svolte le altre. Paradossalmente, in quest'ottica, se non ci fossero problemi di spazio, la soluzione ideale sarebbe quella di avere solo unità dedicate, perchè sono più veloci nell'esecuzione dello specifico task e perchè non sottraggono risorse ad altre elaborazioni. Il problema è che non posso avere un die size delle dimensioni del ponte di un incrociatore e, di conseguenza, sacrifico l'efficienza nella specifica esecuzione per puntare ad una maggior efficienza dell'intera architettura. Questo è ciò che ha spinto ad adottare il modello a shader unificati.
Entrando nello specifico del tessellator, anche all'interno degli hull shader ci sono delle unità fixed function. Il tessellator vero e proprio è l'equivalente di una blind box all'interno della quale arriva l'istruzione di quanti nuovi vertici creare in base a come sono stati riordinati o modificati i control point negli HS. Il tessellator non è necessariamente il collo di bottiglia (dipende dal tipo di elaborazione richiesta) e il motivo per cui è l'unica unità che non sia stata rimpiazzata da altre di tipo generico è semplicemente che la sua sostituzione prevedeva l'uso di un gran numero di unità per avere le stesse performance (come accade per le unità che fanno texture addressing e texture sampling, ad esempio).
Tornando al discorso sulla sottrazione di risorse, ti faccio un altro esempio.
Hai a disposizione 32 cluster di alu (da 16 ciascuno) per fare PS, VS, GS e texture blending. Immagina di dover fare tutte queste operazioni in contemporanea; in un dato momento avrai, ad esempio, 28 cluster che si stanno occupando di eseguire PS e texture blending e 4 che stanno facendo VS e GS. Improvvisamente arriva un'istruzione relativa alla tessellation. Se hai unità dedicate, tranne il primo passaggio in cui i dati vengono trasferiti dal vertex buffer ai VS, per il resto le unità della tua GPU possono continuare ad eseguire i loro task, senza subire rallentamenti. Se hai unità generiche, allora dovrai, ad esempio, sottrarre 4 cluster di alu per eseguire HS e DS; supponiamo che questo avvenga per quelle che si stanno occupando dei PS, in un determinato momento avrai 4 cluster dedicati a VS e GS, 4 alla tessellation e 24 alle operazioni di PS e texture blending. Fino a che non finisce la tessellation le operazioni di PS hanno subito un rallentamento quantificabile con il 14% (poco più) della loro precedente capacità. Se vuoi aumentare la velocità di tessellation devi dedicare atre unità a HS e DS e, di conseguenza, cala ancora la capacità di elaborazione di altri tipi di istruzione.
Ovvio che se ho un'elaborazione "leggera", posso permettermi di stornare risprse ad altri tipi di calcoli. Se lavoro in wireframe non faccio PS e texture blending e posso dedicare tutte le unità alle operazioni geometriche, tessellation inclusa. Questo senza contare che se ho 32 unità dedicate e 32 generiche, nell'eseguire la stessa istruzione le prime somo molto più efficienti delle seconde.
Ovviamente questo esempio è piuttosto semplificato e non tiene conto del fatto che c'è la possibilità di fare thread switching (ma ai fini di ciò che si deve dire cambia poco, anzi è meglio che un singolo cluster si occuipi di portatre a termine una specifica elaborazione, almeno finchè non rischia lo stallo, e non più tipi di elaborazioni in parallelo perchè il thread switching ha un costo in termini di cicli di clock); infine, non è la singola alu che si dedica ad un task, ma l'intero cluster che lavora su un thread e questo impedisce, in ogni caso, il raggiungimento dell'efficenza teorica del 100% anche in un'architettura a shader unificati

[Alekos Panagulis]

Spiegazione magnifica :O
Chiara e semplice.

[Maury]

Ma secondo voi come mai Ati non ha reclamato per via delle versioni non equivalenti di unigine usate da nVidia ? Forse sa già che alla prova dei fatti, che avverrà presumibilmente tra poco, tutto il castello cadrà miseramente ? :confused:

[calabar]

Immagino che Nvidia, scegliendo una soluzione più dinamica, abbia anche fatto i propri calcoli, magari scommettendo un po' sul futuro.
Un po' come aveva fatto ATI con R600 e l'AA via shader, scommessa che per ati si è rivelata poi fallimentare e corretta in seguito.

Cosa sarà di questa invece lo sapremo tra qualche tempo.
Secondo me, visti i supposti consumi di Fermi, questo tipo di vantaggio dovrà mostrarsi in fretta, perchè se lo facesse quando sarà disponibile una generazione più aggiornata di schede, allora chi si terrebbe una scheda che si ha ancora prestazioni decenti, ma consumi indecenti, per godersi questo vantaggio?

A mio parere comunque, se il "potenziamento" del tessellator nvidia (che poi da quel che avevo capito non era il tessellator ad essere stato potenziato, ma gli stadi successivi che dovevano gestire il gran numero di triangoli generati dal tessellator) porterà dei vantaggi con i giochi futuri, questo accadrà quando i motori di tali giochi saranno programmati per schede con il tessellator, ossia con geometrie leggerissime arricchite poi dal tessellator, così come accade per l'Ungine bench.
E questo secondo me non si vedrà ancora per parecchi anni, ossia fino a quando ci sarà la necessità di creare una geometria di base molto fitta per poter girare su schede senza tessellator.

@skizzo99999999
Un appunto sul tuo discorso (ne riprendo i numeri):
Nel caso della GPU con l'hardware dedicato (quindi 480SP + tessellazione completa) e della GPU flessibile (512SP con parte del tessellator via shader) si rischia di farsi ingannare dai numeri.
Di fatto cioè la scheda con da 512 sarà paragonabile ad una scheda da 480+hw come prestazioni (posto che le due soluzioni possano un minimo equivalersi, sempre per ipotesi), il che significa che a parità di sp andrà di meno.
Quindi se una scheda con 512 SP può far gridare all'estrema potenza, dobbiamo ricordare che di fatto con tessellation questa scheda è come se fosse una 480 SP, e non dobbiamo stupirci se non raggiunge i risultati che ci aspettereno da un "full 512 SP".
Forse il discorso è un po' contorto, ma spero di essermi fatto capire! :p

[yossarian]

Immagino che Nvidia, scegliendo una soluzione più dinamica, abbia anche fatto i propri calcoli, magari scommettendo un po' sul futuro.
Un po' come aveva fatto ATI con R600 e l'AA via shader, scommessa che per ati si è rivelata poi fallimentare e corretta in seguito.

Cosa sarà di questa invece lo sapremo tra qualche tempo.
Secondo me, visti i supposti consumi di Fermi, questo tipo di vantaggio dovrà mostrarsi in fretta, perchè se lo facesse quando sarà disponibile una generazione più aggiornata di schede, allora chi si terrebbe una scheda che si ha ancora prestazioni decenti, ma consumi indecenti, per godersi questo vantaggio?

A mio parere comunque, se il "potenziamento" del tessellator nvidia (che poi da quel che avevo capito non era il tessellator ad essere stato potenziato, ma gli stadi successivi che dovevano gestire il gran numero di triangoli generati dal tessellator) porterà dei vantaggi con i giochi futuri, questo accadrà quando i motori di tali giochi saranno programmati per schede con il tessellator, ossia con geometrie leggerissime arricchite poi dal tessellator, così come accade per l'Ungine bench.
E questo secondo me non si vedrà ancora per parecchi anni, ossia fino a quando ci sarà la necessità di creare una geometria di base molto fitta per poter girare su schede senza tessellator.

@skizzo99999999
Un appunto sul tuo discorso (ne riprendo i numeri):
Nel caso della GPU con l'hardware dedicato (quindi 480SP + tessellazione completa) e della GPU flessibile (512SP con parte del tessellator via shader) si rischia di farsi ingannare dai numeri.
Di fatto cioè la scheda con da 512 sarà paragonabile ad una scheda da 480+hw come prestazioni (posto che le due soluzioni possano un minimo equivalersi, sempre per ipotesi), il che significa che a parità di sp andrà di meno.
Quindi se una scheda con 512 SP può far gridare all'estrema potenza, dobbiamo ricordare che di fatto con tessellation questa scheda è come se fosse una 480 SP, e non dobbiamo stupirci se non raggiunge i risultati che ci aspettereno da un "full 512 SP".
Forse il discorso è un po' contorto, ma spero di essermi fatto capire! :p

diciamo che non ha senso considerare un'architettura da 512 alu alla stregua di una di tipo 480+unità dedicate (mi tengo l'architettura 480+T che è molto più veloce anche nel'esecuzione di T). Il vantaggio di un'architettura con alu generiche è che posso bilanciare meglio i carichi di lavoro in base alle necessità e questo significa che quando mi servirà più tessellation non avrò una 480+T (tessellator) ma, magari, una 320+T, il che significa che T sarà eseguita molto più velocemente ma tutto il resto subirà notevoli rallentamenti, senza ocntare che un massiccio utilizzo di tessellation richede anche un maggior impegno dei PS

[Foglia Morta]

Immagino che Nvidia, scegliendo una soluzione più dinamica, abbia anche fatto i propri calcoli, magari scommettendo un po' sul futuro.
Un po' come aveva fatto ATI con R600 e l'AA via shader, scommessa che per ati si è rivelata poi fallimentare e corretta in seguito.

se non sbaglio l' approccio di Fermi è simile a quello di RV770 ( che può fare hull e domain tramite VS e GS ) mentre con RV870 ATi ha scelto circuiteria dedicata , quindi al limite direi scelte diverse e stop

[Andrea deluxe]

scusate, ma non resisto....

http://www.youtube.com/watch?v=gNIPcSF5Wms&feature=related

[Maury]

I nodi vengono al pettine da soli nelle recensioni, perché scoprirsi prima? ;)

E' quello che penso io :)

Del resto ATI è troppo tranquilla in questo periodo, va bene che non ha mai fatto chissà che proclami o attacchi mediatici alla concorrenza, ma a questo giro è davvero mansueta nel proporsi (o meglio nel non proporsi)...

Qua gatta ci cova ...;)

[Andrea deluxe]

E' quello che penso io :)

Del resto ATI è troppo tranquilla in questo periodo, va bene che non ha mai fatto chissà che proclami o attacchi mediatici alla concorrenza, ma a questo giro è davvero mansueta nel proporsi (o meglio nel non proporsi)...

Qua gatta ci cova ...;)

http://www.thinq.co.uk/news/2010/3/8/amd-game-devs-only-use-physx-for-the-cash/

[Diobrando_21]

Scusate è vero che in fermi nell'uso massivo di tessellazione verrano sottratte risorse x il rendering, tuttavia non vedo il problema...se ho ben capito (anche in base a discorsi precedentemente fatti) lo scopo è proprio quello di creare modelli poligonali di partenza più semplici (quindi diminuirà la RICHIESTA di risorse x il rendering) per poi arricchirli con un uso intensivo di tessellazione (quindi è giusto dedicare la maggior parte delle risorse a questa funzione)...mentre fermi potrà farlo senza problemi, le ati no, perdendo colpi nell'uso intensivo di tessellazione (visto che ad un certo punto le risorse del tessellatore ati finiscono senza possibilità di incrementarle, tra l'altro già perdono colpi adesso che la tessellazione è minima)...quindi a me sembra più che altro che fermi dia uno sguardo al futuro su l'uso che effettivamente se ne dovrà fare della tessellazione mentre le ati siano più adatte all'uso attuale...questo è quello che ho capito, spero di avere qualche delucidazione, grazie...:)

[appleroof]

sono sempre stato un convinto fautore dei bench sintetici ma solo se questi sono eseguiti a parità di condizioni. NOn posso far girare il 3dmark 2001 su una vga e il 3dmark2003 su un'altra e trarre conclusioni in merito sulle prestazioni relative :D

cut

non capisco, intenderesti che unigine è sbilanciato verso Nvidia?

Ti da un'idea più affidabile vedere bench di Call of Prypat, DiRT2 e AvP, per capire come vanno e andranno i giochi DX11 che non Unigine. Questo esattamente come accade per 3DMark Vantage che è molto meno affidabile di un qualunque gioco DX10 per capire come vanno i giochi DX10.
cut

ma i post li leggete?? :what: dicevo che unigine è un test sintetico e vale per quello che è, ciò non toglie che come al solito occorre anche testare i giochi (e quanti più possibili) per capire in media come va una vga

[Andrea deluxe]

Scusate è vero che in fermi nell'uso massivo di tessellazione verrano sottratte risorse x il rendering, tuttavia non vedo il problema...se ho ben capito (anche in base a discorsi precedentemente fatti) lo scopo è proprio quello di creare modelli poligonali di partenza più semplici (quindi diminuirà la RICHIESTA di risorse x il rendering) per poi arricchirli con un uso intensivo di tessellazione (quindi è giusto dedicare la maggior parte delle risorse a questa funzione)...mentre fermi potrà farlo senza problemi, le ati no, perdendo colpi nell'uso intensivo di tessellazione (visto che ad un certo punto le risorse del tessellatore ati finiscono senza possibilità di incrementarle, tra l'altro già perdono colpi adesso che la tessellazione è minima)...quindi a me sembra più che altro che fermi dia uno sguardo al futuro su l'uso che effettivamente se ne dovrà fare della tessellazione mentre le ati siano più adatte all'uso attuale...questo è quello che ho capito, spero di avere qualche delucidazione, grazie...:)

metti caso che hai fermi con 512sp.

stai eseguendo una scena senza tassellazione e sei a 300fps....

ad un certo punto della scena compaiono degli oggetti che necessitano di tassellazione.

a questo punto il driver deve associare il compito agli shader che hanno una funzione fissa di tassellazione con priorita' rispetto agli altri effetti.

da 300fps al secondo ne avrai molti meno, perche' quegli shader che stanno calcolando la tassellazione, non possono calcolare il resto allo stesso momento.

poi sara' comunque il driver a stabilire quanti shader impegnare allo stesso momento per la tassellazione e gli halt per le altre istruzioni.
tutto questo facendo attenzione a non creare colli di bottiglia per il resto delle istruzioni...

[yossarian]

non capisco, intenderesti che unigine è sbilanciato verso Nvidia?


nVidia ha usato una versione differente, la 1.1, che permette un incremento prestazionale del 30% in quanto riduce l'overdraw dovuto alle superfici nascoste grazie ad un uso più aggressivo delle operazioni di culling. Questo incremento, su un'architettura come quella di fermi che si giova in misuta maggiore, della riduzione di tale overdraw perchè scarica gran parte del lavoro delle unità di shading e ha più risorse da dedicate alla tessellation, può avere anche valori superiori al 30%

[skizzo99999999]

@skizzo99999999
Un appunto sul tuo discorso (ne riprendo i numeri):
Nel caso della GPU con l'hardware dedicato (quindi 480SP + tessellazione completa) e della GPU flessibile (512SP con parte del tessellator via shader) si rischia di farsi ingannare dai numeri.
Di fatto cioè la scheda con da 512 sarà paragonabile ad una scheda da 480+hw come prestazioni (posto che le due soluzioni possano un minimo equivalersi, sempre per ipotesi), il che significa che a parità di sp andrà di meno.
Quindi se una scheda con 512 SP può far gridare all'estrema potenza, dobbiamo ricordare che di fatto con tessellation questa scheda è come se fosse una 480 SP, e non dobbiamo stupirci se non raggiunge i risultati che ci aspettereno da un "full 512 SP".
Forse il discorso è un po' contorto, ma spero di essermi fatto capire! :p

Ribadisco che i numeri che ho dato sono campati in aria e servono solo come esempi, ma ciò non toglie che secondo me parlare con un po di numeri aiuta. Ribadisco che quello che conta è quanto ci metto ad elaborare un frame completo di tutto: tutti i vertex, tutti i pixel, tutta la tessellazione, ecc... Mettiamo caso che un frame impieghi 16 millisedondi per essere eseguito sulla gpu1 con 480+T. In quei 16 msec, diciamo che la tessellazione ci mette 2 millisecondi. quindi per quei 2 millisendi io ho 480 sp occupati (facciamo finta che si abbia un utilizzo del 100% tanto per semplificare) più gli sp per hull e domain, mentre per i restanti 14 msec saranno occupati "soltanto" i 480 sp generici, con quelli per hull e domain a girarsi i pollici. Nella gpu2 a 512 sp, mettiamo (sempre per semplificare) di dedicare 32 sp alla tessellazione, quindi di rimanere con 480 sp generici per il resto. Quelle operazioni che prima richiedevano 2 msec, grazie alla minor efficienza degli sp generici (ma comunque relativa, visto le considerazione del post precedente) mettiamo che ne richiedono 3. Guardando gli atri 480sp, per quanto riguarda i primi 3 msec la situazione è uguale alla gpu1, presupponendo che si riesca ad occuparli tutti nonostante si abbiano meno dati in "uscita" dalla fase di tessellazione nell'unità di tempo, ma questo non possiamo saperlo (anche se il tessellator potenziato e diviso in 16 parti serve anche per poter offrire, oltre a una potenza totale maggiore anche una migliore granularità utile nel caso in questione). Negli gli altri 13 msec però, io ho a disposizione tutti e 512 gli sp, per cui posso eseguire il resto più velocemente (e quindi impiegare meno di 13 msec). Quindi rallentando una fase ho velocizzato il resto. Il fatto di dedicare 64, 128, 256, sp alla tessellazione invece che 32 non cambia il risultato: infatti gli sp "sottratti" serviranno a terminare prima la tessellazione in modo da liberarli prima per eseguire gli altri compiti, ma il tempo totale non cambia. Può essere utile per bilanciare meglio il carico in modo da tenere sempre più unità utilizzate, visto che le operazioni possono dipendere le une dalle altre ed eseguire massicciamente operazioni prima di un tipo poù essere utile per occupare meglio tutte le risorse a disposizione.
Faccicamo un altro esempio con la gpu2: mettiamo che gli sp eseguano una operazione ogni msec e ci mettano sempre un ciclo per ogni operazione (altra semplificazione, ma come sempre è per far capire): vuol dire che ho a disposizione 512 "cicli" per ogni msec, il che vuol dire 512x16=8192 cicli in totale occupati nel frame. Se io uso 32sp per hull e domai e ho detto che ci metto 3msec, vuol dire che l'operazione consuma 32x3=96 cicli. Me ne rimangono (480x3)+(512x13)=8096 a disposizione per il resto. Se io invece impiego subito 96sp, finisco tutto in 1 msec, per cui ho bruciato più sp subito, ma da'altro canto ci ho sempre messo 96 cicli, per cui ho sempre (416x1)+(512x15)=8096 per il resto. Se gli sp eseguissero invece una operazione più velocemente di un'altra allora il bialnciamento delle unità servirebbe a trovare il "punto" giusto in cui avere le migliori prestazioni, ma non è questo il nocciolo della questione. Il senso dell'esempio è che quello che conta è il tempo totale del frame, non della singola fase.

Come nel mio esempio precedente, è più o meno lo stesso principio del pixel e vertex shader contro shader unificati: questi ultimi, nonostante fossero meno efficienti (= più lenti) hanno permesso di sfruttare al meglio tutte le unità a disposizione in ogni momento, in modo da ganarare l'intero frame più velocemente. Qundi una scheda "full 512sp", cioè 512+T (che presuppone ulteriori sp per hull e domain) sarebbe si più veloce di una "512 senza T", ma sello stesso die size della 512+T magari ci posso mettere una 544 senza T. Il concetto è questo.

[Diobrando_21]

metti caso che hai fermi con 512sp.

stai eseguendo una scena senza tassellazione e sei a 300fps....

ad un certo punto della scena compaiono degli oggetti che necessitano di tassellazione.

a questo punto il driver deve associare il compito agli shader che hanno una funzione fissa di tassellazione con priorita' rispetto agli altri effetti.

da 300fps al secondo ne avrai molti meno, perche' quegli shader che stanno calcolando la tassellazione, non possono calcolare il resto allo stesso momento.

poi sara' comunque il driver a stabilire quanti shader impegnare allo stesso momento per la tassellazione e gli halt per le altre istruzioni.
tutto questo facendo attenzione a non creare colli di bottiglia per il resto delle istruzioni...

Il problema è che prima arricchisci i modelli poligonali e poi fai rendering su quei poligoni, quindi le richieste di risorse per il rendering on diminuiscono, ma solo il numero di poligoni che la CPU deve dare in pasto alla GPU.



Questo si sapeva anche se non ce lo diceva AMD :)

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?

[PConly92]

non è vero, infatti mentre è attiva la tassellazione è attiva anche la "classica" renderizzazione (quest'ultima la puoi escludere ma normalmente il test è fatto "completo")

peccato che nvidia usasse una versione modificata di unigine dove la renderizzazione "classica" è ridotta al minimo...quindi quei frame adesso e come non ci fosserò;)

[calabar]

Io direi il contrario. Se la tessellation diventerà massiva nell'approccio nVIDIA toglierà risorse al rendering (che non sarà quello di Unigine), in quello AMD no.
Con "scommessa per il futuro" NON intendevo dire che quello sarà il futuro e nvidia scommetterà su di esso, ma semplicemente che nvidia ha scommesso sul fatto che in futuro quelle feature saranno un vantaggio. :)

[...] il che significa che T sarà eseguita molto più velocemente ma tutto il resto subirà notevoli rallentamenti, senza ocntare che un massiccio utilizzo di tessellation richede anche un maggior impegno dei PS
Credo che in questo Diobrando_21 abbia ragione: si può supporre che in un motore ben programmato faccia corrispondere alla tessellazione una diminuzione della necessità di potenza per il resto.
Quindi: no tessellation: SP liberi per il resto, tessellation: riversamento della potenza non più necessaria nel rendenring per fare tessellation.
Tutto sommato l'idea sembra buona, bisogna poi vedere i numeri della pratica.

[...]
Certo ;) Anche i miei numeri del resto lo erano.

Provo a chiarire quel che volevo dire con un ulteriore esempio, totalmente ipotetico.
Poniamo di avere un'architettura x dx11 con tessellatore dedicato (tutto!) e 240SP. Ora facciamo un'architettura nuova, con 512 sp (più del doppio) e tessellatore solo in parte dedicato (tipo fermi).
Ora, vedendo i 512SP, l'utente si aspetta prestazioni legate ad una potenza più che doppia. Ma in realtà questo non è vero, perchè la mancanza di hd dedicato lo farà andare come una 480 sp (anche stavolta, un numero quasi a caso, tanto per capirci).

Per il resto naturalmente concordo, l'unico dubbio riguarda proprio quei parametri che non conosciamo, ossia quanto un'unità dedicata è più efficiente e quanto spazio occupa rispetto alle SP.

[...] (che poi da quel che avevo capito non era il tessellator ad essere stato potenziato, ma gli stadi successivi che dovevano gestire il gran numero di triangoli generati dal tessellator) [...]
Qualcuno può dire qualcosa di preciso a riguardo?

[yossarian]

Ribadisco che i numeri che ho dato sono campati in aria e servono solo come esempi, ma ciò non toglie che secondo me parlare con un po di numeri aiuta. Ribadisco che quello che conta è quanto ci metto ad elaborare un frame completo di tutto: tutti i vertex, tutti i pixel, tutta la tessellazione, ecc... Mettiamo caso che un frame impieghi 16 millisedondi per essere eseguito sulla gpu1 con 480+T. In quei 16 msec, diciamo che la tessellazione ci mette 2 millisecondi. quindi per quei 2 millisendi io ho 480 sp occupati (facciamo finta che si abbia un utilizzo del 100% tanto per semplificare) più gli sp per hull e domain, mentre per i restanti 14 msec saranno occupati "soltanto" i 480 sp generici, con quelli per hull e domain a girarsi i pollici. Nella gpu2 a 512 sp, mettiamo (sempre per semplificare) di dedicare 32 sp alla tessellazione, quindi di rimanere con 480 sp generici per il resto. Quelle operazioni che prima richiedevano 2 msec, grazie alla minor efficienza degli sp generici (ma comunque relativa, visto le considerazione del post precedente) mettiamo che ne richiedono 3. Guardando gli atri 480sp, per quanto riguarda i primi 3 msec la situazione è uguale alla gpu1, presupponendo che si riesca ad occuparli tutti nonostante si abbiano meno dati in "uscita" dalla fase di tessellazione nell'unità di tempo, ma questo non possiamo saperlo (anche se il tessellator potenziato e diviso in 16 parti serve anche per poter offrire, oltre a una potenza totale maggiore anche una migliore granularità utile nel caso in questione). Negli gli altri 13 msec però, io ho a disposizione tutti e 512 gli sp, per cui posso eseguire il resto più velocemente (e quindi impiegare meno di 13 msec). Quindi rallentando una fase ho velocizzato il resto. Il fatto di dedicare 64, 128, 256, sp alla tessellazione invece che 32 non cambia il risultato: infatti gli sp "sottratti" serviranno a terminare prima la tessellazione in modo da liberarli prima per eseguire gli altri compiti, ma il tempo totale non cambia. Può essere utile per bilanciare meglio il carico in modo da tenere sempre più unità utilizzate, visto che le operazioni possono dipendere le une dalle altre ed eseguire massicciamente operazioni prima di un tipo poù essere utile per occupare meglio tutte le risorse a disposizione.
Faccicamo un altro esempio con la gpu2: mettiamo che gli sp eseguano una operazione ogni msec e ci mettano sempre un ciclo per ogni operazione (altra semplificazione, ma come sempre è per far capire): vuol dire che ho a disposizione 512 "cicli" per ogni msec, il che vuol dire 512x16=8192 cicli in totale occupati nel frame. Se io uso 32sp per hull e domai e ho detto che ci metto 3msec, vuol dire che l'operazione consuma 32x3=96 cicli. Me ne rimangono (480x3)+(512x13)=8096 a disposizione per il resto. Se io invece impiego subito 96sp, finisco tutto in 1 msec, per cui ho bruciato più sp subito, ma da'altro canto ci ho sempre messo 96 cicli, per cui ho sempre (416x1)+(512x15)=8096 per il resto. Se gli sp eseguissero invece una operazione più velocemente di un'altra allora il bialnciamento delle unità servirebbe a trovare il "punto" giusto in cui avere le migliori prestazioni, ma non è questo il nocciolo della questione. Il senso dell'esempio è che quello che conta è il tempo totale del frame, non della singola fase.

Come nel mio esempio precedente, è più o meno lo stesso principio del pixel e vertex shader contro shader unificati: questi ultimi, nonostante fossero meno efficienti (= più lenti) hanno permesso di sfruttare al meglio tutte le unità a disposizione in ogni momento, in modo da ganarare l'intero frame più velocemente. Qundi una scheda "full 512sp", cioè 512+T (che presuppone ulteriori sp per hull e domain) sarebbe si più veloce di una "512 senza T", ma sello stesso die size della 512+T magari ci posso mettere una 544 senza T. Il concetto è questo.

non hai tenuto conto di alcuni elementi:
1) gli Hull shader hanno unità constant function il cui lavoro deve essere emulato da quelle fp dello shader core (minore efficienza)
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.

Il discorso di Calabar è corretto: parliamo di un chip che ha un numero massimo di 512 alu teoriche che si confronta con un chip che ne ha 1600 (di tipo differente). Se faccio uso di tessellation il secondo continuerà ad avere 1600 alu dedicate a fare ciò che facevano anche prima, il primo non avrà più 512 alu dedicate agli stessi compiti ma decisamente meno e saranno tante di mneo quante più si deciderà di dedicarne alla tessellation. Discorso analogo a quello visto per physx: attivalo e vedrai il frame rate andare a picco e tanto più è pesante l'effetto implementato e tanto più è pesante il motore grafico, tanto più le prestazioni crollano. Fisicamente parlando un'unità o un cluster che si sta occupando di tessellare o di fare calcoli fisici non può, contemporaneamente fare altro.

Diciamo che nVidia ha scelto la strada che le permetteva di implemenatre il maggior numero possibile di unità di calcolo di generiche. Questo permette di avere una maggior efficienza dell'intera architettura ma una minor efficienza in ogni singolo task. D'altra parte, con un chip così complesso la strada era pressoche obbligata e l'adozione di unità dedicate avrebbe portato ad un ulteriore aumento delle dimensioni del chip per degli stadi che sono impiegati solo quando servono (in un gioco privo di tessellation, l'unità dedicata resta del tutto inattiva mentre quelle generiche le utilizzo per fare altro). In tal senso, anche la scelta di ricorrere alle unitàà di shading per il texture blending. Restano, però, come unità dedicate, quelle di texture sampling e addressing e quelle che fanno resolve per il MSAA box. Questo significa che la loro sostituzione comportava un eccessivo aumento delle unità generiche per compensare le perdite prestazionali (un'operazione di texture sampling richiede 20 cicli con unità generiche dove una dedicata se la cava con un singolo ciclo, ad esempio).

[yossarian]

Credo che in questo Diobrando_21 abbia ragione: si può supporre che in un motore ben programmato faccia corrispondere alla tessellazione una diminuzione della necessità di potenza per il resto.
Quindi: no tessellation: SP liberi per il resto, tessellation: riversamento della potenza non più necessaria nel rendenring per fare tessellation.
Tutto sommato l'idea sembra buona, bisogna poi vedere i numeri della pratica.


la tessellation può essere usata per aumentare il dettaglio poligonale (e allora comporta un maggior peso di calcoli anche a valle) o per conservare lo stesso dettaglio migliorando l'occupazione di memoria e la banda passante occupata (ho meno vertici da immagazzinare all'interno dei buffer, ho meno vertici da trasferire attraverso il bus, ecc). In tal caso, a valle del tessellator, la complessità dei calcoli non diminuisce. Il vantaggio è che lavora meno la cpu perchè deve definire un numero inferiore di punti iniziali

[ghiltanas]

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?

io dico che questa nn è la generazione del tessellation, e lo si vede anceh dal fatto che giochi che ne fanno uso intensivo ancora nn ce ne sono, e anche in uscita nn mi pare di aver sentito nulla a riguardo. Credo bisognerà attendere la seconda generazione di schede dx11, ati e nvidia miglioreranno sicuramente ò'hardware per tale scopo, e allora si spera sarà necessario.
Al momento entrambe le implementazioni vanno bene (sempre imho) proprio perchè tale features è implementata in maniera lieve

[Alex656]

Finalmente la discussione riacquista interesse con il confronto serrato tra Yoss e Skizzo...............alla faccia delle solite stupidaggini sulla manciata di frames in più o in meno del benckmark x o del gioco y.

[yossarian]

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]

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]

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+]

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

[yossarian]

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.


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)



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.



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]

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

ogni tanto spunti, ciao ;)

[halduemilauno]

ogni tanto spunti, ciao ;)

Ciao.
;)

[calabar]

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.

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]

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 :D

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]

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]

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

il 26 lo sapremo ;)

[halduemilauno]

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

si credo di si.

il 26 lo sapremo ;)

esatto.

[ghiltanas]

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]

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.aspx?libera=5870&id=28&prezzoMin=&prezzoMax=&sbox=sb
se andasse di + sarebbero 400 e passa €.

[Alekos Panagulis]

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

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

[skizzo99999999]

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:

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.




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]

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?...
Bè dai speriamo...350 ci potrei ancora stare...per quello che è probabile al momento, ovvero:

Specifiche:

http://image.tianjimedia.com/uploadImages/2010/062/12SY5FFF3053.jpg

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.

[halduemilauno]

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

Specifiche:

http://image.tianjimedia.com/uploadImages/2010/062/12SY5FFF3053.jpg

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.

http://tof.canardpc.com/view/21bd86d6-df91-4b6d-8d88-73ba7825af5f.jpg

http://tof.canardpc.com/preview2/b1796530-ed7d-4f48-921d-a3dfceac3f8b.jpg

[halduemilauno]

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

spiegami dovrebbe andare di + di una scheda che costa di +???? per carità magari vado di + e spendo di -.

[zorco]

per 350 euro, se va quanto la 5870 sarà mia e non ci sono ne cazzi ne mazzi:p :D

[Marscorpion]

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

Se la mettono a quel prezzo e per fare concorrenza alla 5870, perciò andrà + o - uguale. Stai tranquillo che se andrà anche solo 2 fps in più della 5870 la vendono a 400 euro.

[yossarian]

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

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.


ok, ma non possiamo ipitizzare qualcosa che non può essere ipotizzato perchè non funziona così. :D


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


continui a ragionare considerando che il tessellator sia quello che assorbe più risorse. Ti stupiresti se ti dicessi che in un'operazione di tessellation sono spesso i domain shader ad occupare la maggior parte del tempo? Questo significa che fermi avrà uno degli stadi di tessellation con maggiori latenze (il problema è proprio quello) a carico dello shader core mentre cypress fa uso di unità dedicate.
Torno a ripetere, se una gpu sta lavorando a tessellator spento e si accende il tessellator, nel caso in cui lo stesso fa uso di unità generiche condivise da altri stadi, l'elaborazione relativa a questi ultimi rallenta inevitabilmente e questo significa sottrarre risorse ad altre elaborazioni. E' evidente che nVidia non si è potuta per mettere di far uso di unità dedicate (avrebbe anche potuto frammentare il tessellator, come ha fatto, ma utilizzando unità dedicate ma non lo ha fatto e non per libera scelta ma perchè il die di fermi è già enorme di suo).
E' altrettanto evidente che nel caso di RV870, il tessellator non sottrare risorse ad alcunchè.
Nell'ipotesi che sia un solo cluster ad occupare l'area di hull e domain shader, quando si farà tessellation quel cluster in più non sarà un vantaggio perchè, a parità di area occupata, hull e domain shader sono più veloci (hanno meno latenze e impiegano meno cicli, sono più numerosi perchè, in quanto unità dedicate occupano meno spazio, ecc).
Ti rifaccio l'esempio precedente; in R600 il MSAA box fa resolve via shader; hanno tolto l'unità dedicata di tipo INT dalle ROP's, hanno guadagnato spazio per mettere altre alu, eppure il MSAA va molto peggio.

[aaasssdddfffggg]

Se la mettono a quel prezzo e per fare concorrenza alla 5870, perciò andrà + o - uguale. Stai tranquillo che se andrà anche solo 2 fps in più della 5870 la vendono a 400 euro.

Allora io sono fottuto...in vista delle 480 (ammeso che riesca a reperirle).:asd:

[Blackcat73]

Stavo leggendo con interesse(pur non capendo proprio tutto:D ) il discorso sull'implementazione del tesselator e mi chiedevo una cosa... se (e ripeto se dato che non se ne hanno notizie fino ad ora) uscisse una fascia media da parte di Nvidia basteranno gli sp presenti su queste ipotetiche schede a gestire il tutto?

[yossarian]

Stavo leggendo con interesse(pur non capendo proprio tutto:D ) il discorso sull'implementazione del tesselator e mi chiedevo una cosa... se (e ripeto se dato che non se ne hanno notizie fino ad ora) uscisse una fascia media da parte di Nvidia basteranno gli sp presenti su queste ipotetiche schede a gestire il tutto?

giusta domanda; infatti un altro punto debole dell'implementazione di nVidia è che se taglio, ipotesi, 128 alu, riduco anche di 1/4 il numero dei polymorph engine. Questo significa meno potenza di calcolo per la tessellation vera e propria e anche meno potenza di calcolo per HS e DS. Al contrario, il tessellator di ATi può essere trasferito, così com'è, anche sulla fascia bassa.

[bomkill]

per 350 euro, se va quanto la 5870 sarà mia e non ci sono ne cazzi ne mazzi:p :D

Se va quanto una 5870 Ati a sempre in mano la carta del ribasso e con questa carta pupuò far male,pensa la 5870 a 275€ e la 5850 a 199€

[Blackcat73]

Se va quanto una 5870 Ati a sempre in mano la carta del ribasso e con questa carta pupuò far male,pensa la 5870 a 275€ e la 5850 a 199€

Sarebbe ottimo per noi sperando che i numeri sulla disponibilità non siano veri perchè in quel caso anche se fosse competitiva come prezzo/prestazioni diventerebbe introvabile e la gente acquisterebbe comunque Ati in mancanza d'altro e il taglio di prezzi andrebbe a farsi benedire:doh:

[okorop]

Sarebbe ottimo per noi sperando che i numeri sulla disponibilità non siano veri perchè in quel caso anche se fosse competitiva come prezzo/prestazioni diventerebbe introvabile e la gente acquisterebbe comunque Ati in mancanza d'altro e il taglio di prezzi andrebbe a farsi benedire:doh:

a 350 euro non si trova la ati, la ati 5870 si trova a 300 euro, fatta questa puntualizzazzione se la gtx470 costasse 350 euro non sarebbe assai competitiva, rimarrebbe fissa ai prezzi Nvidia in quanto avrà delle prestazioni tra la 5850 e la 5870 e costerà piu' di entrambe....il tutto stando alle indiscrezioni trapelate

[luX0r.reload]

Sarebbe ottimo per noi sperando che i numeri sulla disponibilità non siano veri perchè in quel caso anche se fosse competitiva come prezzo/prestazioni diventerebbe introvabile e la gente acquisterebbe comunque Ati in mancanza d'altro e il taglio di prezzi andrebbe a farsi benedire:doh:
Chi vuole il massimo delle features, come Nemesis, acquisterà ugualmente nVidia. Physx ed il 3dVision possono piacere o non piacere, possono essere features vincenti o cagate, ma se uno vuole giocarsi un videogioco con tutte le features che implementa, senz'altro punterà sulle nuove nVidia... sopratutto se il tessellatore funzionerà, come dicono i rumors, molto meglio della controparte ATI ;)

[ertruffa]

a 350 euro non si trova la ati, la ati 5870 si trova a 300 euro, fatta questa puntualizzazzione se la gtx470 costasse 350 euro non sarebbe assai competitiva, rimarrebbe fissa ai prezzi Nvidia in quanto avrà delle prestazioni tra la 5850 e la 5870 e costerà piu' di entrambe....il tutto stando alle indiscrezioni trapelate

300 euro dove?all'estero? in italia si trova sui 350.

[okorop]

300 euro dove?all'estero? in italia si trova sui 350.

il problema è il cambio euro dollaro che varia, io al lancio la pagai 280 euro, bisognerebbe sapere il prezzo in dollari per fare comparazioni

[Andrea deluxe]

Chi vuole il massimo delle features, come Nemesis, acquisterà ugualmente nVidia. Physx ed il 3dVision possono piacere o non piacere, possono essere features vincenti o cagate, ma se uno vuole giocarsi un videogioco con tutte le features che implementa, senz'altro punterà sulle nuove nVidia... sopratutto se il tessellatore funzionerà, come dicono i rumors, molto meglio della controparte ATI ;)

l'hai detto bene.;)

[aaasssdddfffggg]

l'hai detto bene.;)

Benissimo aggiungerei.:asd:

[Raven]

Chi vuole il massimo delle features, come Nemesis, acquisterà ugualmente nVidia. Physx ed il 3dVision possono piacere o non piacere, possono essere features vincenti o cagate, ma se uno vuole giocarsi un videogioco con tutte le features che implementa, senz'altro punterà sulle nuove nVidia... sopratutto se il tessellatore funzionerà, come dicono i rumors, molto meglio della controparte ATI ;)

Il "problema" però è che chi vuole invece il massimo delle performance (gli enthusiast, quelli che guardano i freddi numeri dei bench e se ne fregano delle feature) ignoreranno questa generazione di nvidia e andranno su sistemi crossX di ati hd5970... ;)

[Rsdj]

Ma i post di Yossarian proprio li ignorate fatemi capire?? :D

[okorop]

Il "problema" però è che chi vuole invece il massimo delle performance (gli enthusiast, quelli che guardano i freddi numeri dei bench e se ne fregano delle feature) ignoreranno questa generazione di nvidia e andranno su sistemi crossX di ati hd5970... ;)

quoto e sembra proprio che la ati radeon 5870 vada di piu' della gtx470 nei benchmark mentre invece la 480 solamente il 15% stando a quello riportato da nickshih

[aaasssdddfffggg]

Il "problema" però è che chi vuole invece il massimo delle performance (gli enthusiast, quelli che guardano i freddi numeri dei bench e se ne fregano delle feature) ignoreranno questa generazione di nvidia e andranno su sistemi crossX di ati hd5970... ;)

Felicissimo di non far parte della categoria Enthusiast allora...:asd:

[Raven]

Felicissimo di non far parte della categoria Enthusiast allora...:asd:

Il mondo è bello perché è vario! :sofico:

[aaasssdddfffggg]

Il mondo è bello perché è vario! :sofico:

e ci mancherebbe che fosse il contrario : sai che tristezza sarebbe?;)

[Rsdj]

Ragazzi ma quali features... ancora stiamo qua a farci impollinare bene bene dal marketing delle società che troppo spesso cercano di venderci aria fritta... sia ATI sia nVidia, sia AMD sia Intel, chi più chi meno ma sono tutte a scopo di lucro, fin troppo per i miei gusti ;)

[luX0r.reload]

Questo i rumors non lo dicono...
E chi lo dice? :D

[ghiltanas]

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

il punto è che bisogna vedere anche quanto può realmente prezzare la scheda nvidia....ed eventualmente il ribasso di amd che penso si possa permettere..
Se vanno uguali e costano uguali allora ok, però resta da vedereil consumo, aspetto nn secondario. Se va tra la 5850 e la 5870 invece 350 sono troppi, una 5850 si trova a 250, probabilmente subirà anche una flessione verso il basso, troppa differenza in questo caso.

[ghiltanas]

Se va quanto una 5870 Ati a sempre in mano la carta del ribasso e con questa carta pupuò far male,pensa la 5870 a 275€ e la 5850 a 199€

è quello che sto aspettando :( , mia all'istante :O

[ghiltanas]

quoto e sembra proprio che la ati radeon 5870 vada di piu' della gtx470 nei benchmark mentre invece la 480 solamente il 15% stando a quello riportato da nickshih

infatti ancora nn ho capito quale sarà la differenza tra 480 e 470 (principalmente in sp), e inoltre trovo strano che si trovino sempre + spesso bench con la sorella minore...La 480 sembra proprio essere una chimera, molto di figura, la scheda top realmente in commercio (10000 unità nn vorrebbe dire realmente in commercio) sembra essere la 470

[luX0r.reload]

il punto è che bisogna vedere anche quanto può realmente prezzare la scheda nvidia....ed eventualmente il ribasso di amd che penso si possa permettere..
Se vanno uguali e costano uguali allora ok, però resta da vedereil consumo, aspetto nn secondario. Se va tra la 5850 e la 5870 invece 350 sono troppi, una 5850 si trova a 250, probabilmente subirà anche una flessione verso il basso, troppa differenza in questo caso.
Dipende, come dicevo, da utente a utente. A prescindere da quanto andranno realmente le nuove nVidia, ci sono utenti che magari andranno sulle 4x0 perchè hanno intenzione di giocare in 3d con il 3dVision... e ci saranno utenti che preferiranno le performance e/o il rapporto prestazioni di ATI.
Naturalmente sempre considerano un eventuale divario, a vantaggio di ATI, di pochi punti percentuale.

[ghiltanas]

http://tof.canardpc.com/view/21bd86d6-df91-4b6d-8d88-73ba7825af5f.jpg

http://tof.canardpc.com/preview2/b1796530-ed7d-4f48-921d-a3dfceac3f8b.jpg

anche qui test a risoluzione uber e nn mi pare precisi se si parla di gtx480 o 470 (in questo caso rinnovo il dubbio sul perchè effettuare bench nn con la scheda top)

[luX0r.reload]

Tu...
Beh allora le decine di pagine che ho letto su questi presunti rumors erano in un altro forum... :rolleyes:

[okorop]

anche qui test a risoluzione uber e nn mi pare precisi se si parla di gtx480 o 470 (in questo caso rinnovo il dubbio sul perchè effettuare bench nn con la scheda top)

punto due a quanto si vede la 5870 e la vga 4x0 vanno praticamente uguali......

[ghiltanas]

Dipende, come dicevo, da utente a utente. A prescindere da quanto andranno realmente le nuove nVidia, ci sono utenti che magari andranno sulle 4x0 perchè hanno intenzione di giocare in 3d con il 3dVision... e ci saranno utenti che preferiranno le performance e/o il rapporto prestazioni di ATI.
Naturalmente sempre considerano un eventuale divario, a vantaggio di ATI, di pochi punti percentuale.

apparte che il 3d e il 3d vision ammazzano le prestazioni (ricordo che il 3d ben fruibile ha bisogno di un elevato framerate, doppio per la precisione rispetto alla versione 2d, quindi l'ideale sarebbe 120Hz), quindi con certi giochi anche con schede cosi ce lo si può scordare,poi se è a metà strada tra 5850 e 5870, spendere 100 euro di + nn mi pare sensato, diverso ovviamente se è a ridosso della 5870, e anche qui però ripeto vanno guardati i consumi e l'eventuale nuovo prezzi di 5850 e 5870.

[okorop]

apparte che il 3d e il 3d vision ammazzano le prestazioni (ricordo che il 3d ben fruibile ha bisogno di un elevato framerate, doppio per la precisione rispetto alla versione 2d, quindi l'ideale sarebbe 120Hz), quindi con certi giochi anche con schede cosi ce lo si può scordare,poi se è a metà strada tra 5850 e 5870, spendere 100 euro di + nn mi pare sensato, diverso ovviamente se è a ridosso della 5870, e anche qui però ripeto vanno guardati i consumi e l'eventuale nuovo prezzi di 5850 e 5870.

ma scusa se vanno uguali perchè ati dovrebbe abbassare i prezzi? secondo me la 5870 resta e rimane una vga da 379 dollari, come lo era al lancio ed ancora di piu' vedendo i prezzi della concorrenza....

[ghiltanas]

ma scusa se vanno uguali perchè ati dovrebbe abbassare i prezzi? secondo me la 5870 resta e rimane una vga da 379 dollari, come lo era al lancio ed ancora di piu' vedendo i prezzi della concorrenza....

perchè può farlo e aggredirebbe al massimo la concorrenza ;)
ovviamente nel caso di disponibilità effettiva, se fermi è limitato ai parenti degli sviluppatori nn credo che ati abbassi nulla :p

[luX0r.reload]

apparte che il 3d e il 3d vision ammazzano le prestazioni (ricordo che il 3d ben fruibile ha bisogno di un elevato framerate, doppio per la precisione rispetto alla versione 2d, quindi l'ideale sarebbe 120Hz), quindi con certi giochi anche con schede cosi ce lo si può scordare,poi se è a metà strada tra 5850 e 5870, spendere 100 euro di + nn mi pare sensato, diverso ovviamente se è a ridosso della 5870, e anche qui però ripeto vanno guardati i consumi e l'eventuale nuovo prezzi di 5850 e 5870.
Quando di parla di gaming con la G maiuscola il "sensato" va a farsi friggere.
Io non spenderei mai 400€ per una scheda video, ma non la pensiamo tutti allo stesso modo.
Naturalmente spero per tutti che nVidia non spari troppo in alto con i prezzi... anche se non penso arriverà mai all'ottimo rapporto prezzo/prestazioni che hanno avuto (e hanno) le ati.

[Greifi Grishnackh]

anche qui test a risoluzione uber e nn mi pare precisi se si parla di gtx480 o 470 (in questo caso rinnovo il dubbio sul perchè effettuare bench nn con la scheda top)
perchè la gtx480 è ancora piu irreperibile della 470...

[luX0r.reload]

Hai letto commenti, non rumors. Il rumor (che poi non è un rumor ma una slide nVIDIA) parla di prestazioni in Unigine con tessellation attiva, ad una risoluzione sola, ad un set di impostazioni solo, con una versione di Unigine ancora non rilasciata.

I rumors che parlano delle prestazioni dicono +5% nei giochi in DX11.
... saranno commenti a rumors, visto che di ufficiale non c'è niente...

E poi chi dice che il rumor più veritiero sia quello che dice che sia più veloce solo di un 5%?
Ecco perchè ho sottolineato "Se...". Io non ho la verità assoluta come non ce l'hai tu.

[davide155]

Chi vuole il massimo delle features, come Nemesis, acquisterà ugualmente nVidia. Physx ed il 3dVision possono piacere o non piacere, possono essere features vincenti o cagate, ma se uno vuole giocarsi un videogioco con tutte le features che implementa, senz'altro punterà sulle nuove nVidia... sopratutto se il tessellatore funzionerà, come dicono i rumors, molto meglio della controparte ATI ;)

Non è del tutto vero.

Io mi ritengo uno di quelli da te descritti, ma ho scelto comunque una Ati 5850, da ex possessore di una fantastica 8800gt AMP.

L'ho scelta perchè ho tutte le features del momento. Dx11-Tassellation-Accelerazione encoding, decoding e delle prestazioni che nessun'altra scheda ha al momento nella stessa fascia di prezzo.
Senza contare l'overcloccabilità sbalorditiva con una facilità imbarazzante. Si clocca facilmente a 1ghz/1250 sopravanzando la sorella maggiore 5870, avendo risparmiato 100€!

Tu dimmi perchè avrei dovuto aspettare una scheda Nvidia, che per ora è solo utopia, ma si sa certamente che consumerà molto di più a pari prestazioni ed avrà prezzi lievemente più alti, per non parlare del calore emanato e quindi zero o quasi, overcloccabilità.

Per cosa avrei dovuto aspettare 6 mesi? Per physX? Per il 3dvision che serve un monitor apposito ed il corredo di occhiali il che si traduce in un esborso di soldi fuori dal normale.

Per me Nvidia stavolta ha toppato alla grande, aggiungendo, purtroppo.

[Albi80]

Sono curioso di sapere come implementeranno il 3D quelli della ATi .
Se è vero che si potranno usare gli occhiali di terzi , mi piace l idea di poter scegliere tra occhiali piu o meno performanti . Vedremo . Sarei curioso di provare la soluzione di Nvidia . Ma al momento dovrei sostituire pure il monitor 24" e leggendo in giro perdono molto in qualità dell'immagine gli lcd 120hz di adesso .
Devono maturare un po .
Saluti
OT
Bello !!! due Deltoni di seguito !!! :D :D

[luX0r.reload]

Non è del tutto vero.

Io mi ritengo uno di quelli da te descritti, ma ho scelto comunque una Ati 5850, da ex possessore di una fantastica 8800gt AMP.

L'ho scelta perchè ho tutte le features del momento. Dx11-Tassellation-Accelerazione encoding, decoding e delle prestazioni che nessun'altra scheda ha al momento nella stessa fascia di prezzo.
Senza contare l'overcloccabilità sbalorditiva con una facilità imbarazzante. Si clocca facilmente a 1ghz/1250 sopravanzando la sorella maggiore 5870, avendo risparmiato 100€!

Tu dimmi perchè avrei dovuto aspettare una scheda Nvidia, che per ora è solo utopia, ma si sa certamente che consumerà molto di più a pari prestazioni ed avrà prezzi lievemente più alti, per non parlare del calore emanato e quindi zero o quasi, overcloccabilità.

Per cosa avrei dovuto aspettare 6 mesi? Per physX? Per il 3dvision che serve un monitor apposito ed il corredo di occhiali il che si traduce in un esborso di soldi fuori dal normale.

Per me Nvidia stavolta ha toppato alla grande, aggiungendo, purtroppo.
Il presupposto era "voglio tutte le features"... senza considerare se la spesa in più vale gli effetti Physx e/o 3dVision.

Tutto a prescindere. Questo è il discorso... anche se a te (e anche a me) potrà sembrare irrazionale ;)

[Rsdj]

Non è ancora il momento del 3D... aspettiamo gli schermi autostereoscopici ;)

[davide155]

OT
Bello !!! due Deltoni di seguito !!! :D :D
Delta nel cuore :O
Il presupposto era "voglio tutte le features"... senza considerare se la spesa in più vale gli effetti Physx e/o 3dVision.

Tutto a prescindere. Questo è il discorso... anche se a te (e anche a me) potrà sembrare irrazionale ;)

Vabbè ma allora che presupposto è se non è razionale :D

Cmq ho afferrato cosa volevi dire ;)

[Kharonte85]

punto due a quanto si vede la 5870 e la vga 4x0 vanno praticamente uguali......
Se è la 470 direi che va bene (e molto probabilmente lo è dato che di gtx 480 in giro ce ne saranno pochissime)

I motivi per fare vedere benchmark a risoluzioni alte potrebbero essere: la scheda si avvantaggia dei 200mb (500 nel caso della gtx 480) di memoria in più, la scheda alle risoluzioni inferiori è più CPU limited, per fare :sborone:

[marco XP2400+]

Chi vuole il massimo delle features, come Nemesis, acquisterà ugualmente nVidia. Physx ed il 3dVision possono piacere o non piacere, possono essere features vincenti o cagate, ma se uno vuole giocarsi un videogioco con tutte le features che implementa, senz'altro punterà sulle nuove nVidia... sopratutto se il tessellatore funzionerà, come dicono i rumors, molto meglio della controparte ATI ;)
io mi fiderei di rata, ha già dimostrato di essere del settore...
cioè i rumors riportano schermate di Unigine Heaven 1.1, quindi non è ,che è così scontato, che durante un gioco tali prestazioni siano riproposte
nVidia ha usato una versione differente, la 1.1, che permette un incremento prestazionale del 30% in quanto riduce l'overdraw dovuto alle superfici nascoste grazie ad un uso più aggressivo delle operazioni di culling. Questo incremento, su un'architettura come quella di fermi che si giova in misuta maggiore, della riduzione di tale overdraw perchè scarica gran parte del lavoro delle unità di shading e ha più risorse da dedicate alla tessellation, può avere anche valori superiori al 30%

poi yoss e skizzo stanno discutendo e spero che continuino anche su questo
quindi potremmo riuscire ad avere alla fine, una opinione tecnica (in forma facile)che ci chiarisca le idee,
anche se come già detto nei vari post per la stessa architettura ad unità geenriche presenti in fermi durante test come quello dell Unigine Heaven 1.1 l'architettura fermi è normale che renda di più con i punti,
nei giochi però la situazione ovviamente non sarà la stessa!!
stanno ora cercando di capire in che proporzione....

[A.L.M.]

Se è la 470 direi che va bene (e molto probabilmente lo è dato che di gtx 480 in giro ce ne saranno pochissime)

I motivi per fare vedere benchmark a risoluzioni alte potrebbero essere: la scheda si avvantaggia dei 200mb (500 nel caso della gtx 480) di memoria in più, la scheda alle risoluzioni inferiori è più CPU limited, per fare :sborone:

Direi questo più la banda maggiore. Non penso proprio che una HD5870 o una GTX470 siano cpu limited con un Core i7 OC in full HD, tanto per dire, che tra l'altro è una risoluzione alla quale si gioca benissimo a tutto con schede di tale potenza. Mostrare i 2560x1600 per poi farmi vedere che con entrambe giochi male (perchè sotto i 25-30fps giochi male, solitamente) ma con una un pelino meno male, e nemmeno in tutti gli scenari, lascia un po' il tempo che trova, imho, nè tantomeno mi fa gridare alla scheda che fa girare i giochi DX11 come si deve.
Alla fine le risoluzioni d'elezione per schede come queste sono 1920x1200 e 1920x1080. Risoluzioni più alte sono più terreno da multigpu.
D'altro canto il MSRP che si sente in giro per la GTX470 sembra essere da scheda meno performante della controparte, la quale ha ancora oggi un MSRP di $399 (http://www.pricewatch.com/search?q=hd5870). Sarebbe la prima volta che NVidia con una scheda che va di più ti fa pagare meno già al lancio, io lo escluderei, ma ovviamente tutto può essere. :)

[ghiltanas]

a quanto pare nvidia sta accusando il ritardo:

http://www.brightsideofnews.com/news/2010/3/9/steam-survey-february-2010-amd-radeon-hd-4800-takes-nvidias-crown.aspx

4800 in vetta, battendo per la prima volta le 8800, e molto sono anche le 5000..
E' salita molto anche la risoluzione...tutti dati che mi fanno piacere, se la potenza dei sistemi aumenta, si spera che aumenti anche il dettaglio dei giochi.
Sono curioso di vedere anche quanto ne ha risentito il market share del ritardo nvidia.

[AnonimoVeneziano]

a quanto pare nvidia sta accusando il ritardo:

http://www.brightsideofnews.com/news/2010/3/9/steam-survey-february-2010-amd-radeon-hd-4800-takes-nvidias-crown.aspx

4800 in vetta, battendo per la prima volta le 8800, e molto sono anche le 5000..
E' salita molto anche la risoluzione...tutti dati che mi fanno piacere, se la potenza dei sistemi aumenta, si spera che aumenti anche il dettaglio dei giochi.
Sono curioso di vedere anche quanto ne ha risentito il market share del ritardo nvidia.

Più che altro sarà colpa degli ultimi drivers ... :asd:

[Albi80]

a quanto pare nvidia sta accusando il ritardo:

http://www.brightsideofnews.com/news/2010/3/9/steam-survey-february-2010-amd-radeon-hd-4800-takes-nvidias-crown.aspx

4800 in vetta, battendo per la prima volta le 8800, e molto sono anche le 5000..
E' salita molto anche la risoluzione...tutti dati che mi fanno piacere, se la potenza dei sistemi aumenta, si spera che aumenti anche il dettaglio dei giochi.
Sono curioso di vedere anche quanto ne ha risentito il market share del ritardo nvidia.

Con tutte le 8800 andate in fumo , il distacco è destinato ad aumentare :D :banned:

[jaredpace]

http://pctuning.tyden.cz/images/stories/1(9).jpg
http://pctuning.tyden.cz/images/stories/2(5).jpg
http://pctuning.tyden.cz/images/stories/drivers.png

[persa]

così il 470, come velocita della ram andrebbe a 4000mhz invece di 3200?
mah vedremo :confused:

[persa]

edit

[Andrea deluxe]

http://pctuning.tyden.cz/images/stories/exx.jpg

(http://translate.google.com.br/translate?u=http%3A%2F%2Fpctuning.tyden.cz%2Fcomponent%2Fcontent%2Farticle%2F1-aktualni-zpravy%2F16852-prvni-pohled-na-gtx-470&sl=cs&tl=en&hl=&ie=UTF-8)

[nicolasmagister]

Ragazzi, ma secondo voi è vera la notizia del prezzo di 366 $ in Cina per la 470?
Mi sembra troppo. Considerando che la fanno anche lì, considerando che in Europa ci sono le tasse di importazione, il ricarico e L'IVA, 400€ è una previsione molto e troppo ottimistica. A quel prezzo in Cina, vuol dire che in Italia no potrà essere venduta al dettaglio a meno di 420-430 € al lancio, altrimenti i distributori nel mercato Europeo non ci guadagnano nemmeno il 5% di margine.
Spero che questo rumor sia una balla, altrimenti si mette male per i prezzi di entrambi le parti, che vanno per strade loro senza farsi concorrenza, visto che la Ati starebbe comunque sotto e non avrebbe la necessità di abbassare il prezzo per un prodotto che anche se sarà meno efficente è comunque in linea con questo prezzo della 470.
Comunque, come è possibile che un negozio cinese possa vendere un prodotto ancora non ufficialmente presentato prima del 26 marzo? Vabbe' che lì fanno come gli pare, ma è Nvidia che vende ai distributori. Se fosse vero vuol dire che Nvidia ha deciso di lanciare le schede prima in un solo mercato ufficiosamente e poi le lancia ufficilamente a livello mondiale?.
Ba!!!..!!! Mi puzza di fake.

[goldorak]

Ragazzi ma è vera la notizia del prezzo di 366 $ in Cina per la 470?
Mi sembra troppo. Considerando che la fanno anche lì, considerando che in Europa ci sono le tasse di importazione, il ricarico e L'IVA, 400€ è una previsione molto e troppo ottimistica. A quel prezzo in cina, vuol dire che in Italia no potrà essere venduta al dettaglio a meno di 420-430 € al lancio, altrimenti i distributori nel mercato Europeo non ci guadagnano nemmeno il 5% di margine.
Spero che questo rumor sia una balla, altrimenti si mette male per i prezzi di entrambi le parti, che vanno per strade loro senza farsi concorrenza, visto che la Ati starebbe comunque sotto e non avrebbe la necessità di abbasre prezzo per un prodotto che acnhe se sarà meno efficente è comunque in linea con questo prezzo della 470.
Ba!!!..!!!

Io lo dissi mesi e mesi fa che questa generazione DX11 sarebbe stata una fotocopia di quella DX10 pre RV770. Ergo prezzi alti nella fascia medio alta, fascia media ridicola rispetto alla fascia alta della generazione precedente.
Ricordate la 8600 GT/S a 200 € nella fascia media ? :sbonk: Una :ciapet: bella e buona e non che ATI fosse meglio (le schede DX 9 1950pro e 7900 erano migliori di queste presunte DX10 di fascia media).

[appleroof]

nVidia ha usato una versione differente, la 1.1, che permette un incremento prestazionale del 30% in quanto riduce l'overdraw dovuto alle superfici nascoste grazie ad un uso più aggressivo delle operazioni di culling. Questo incremento, su un'architettura come quella di fermi che si giova in misuta maggiore, della riduzione di tale overdraw perchè scarica gran parte del lavoro delle unità di shading e ha più risorse da dedicate alla tessellation, può avere anche valori superiori al 30%

ah...ero rimasto indietro :p

vorrà dire che confronteremo unigine 1.1 su entrambe le architetture :D

[halduemilauno]

http://pctuning.tyden.cz/images/stories/exx.jpg

(http://translate.google.com.br/translate?u=http%3A%2F%2Fpctuning.tyden.cz%2Fcomponent%2Fcontent%2Farticle%2F1-aktualni-zpravy%2F16852-prvni-pohled-na-gtx-470&sl=cs&tl=en&hl=&ie=UTF-8)

GTX470. Se era 375 allora si sarebbe trattato della GTX480.

[Roby0189]

Ciao a tutti, fatemi capire una cosa da tutte queste discursioni ma la futura scheda nvidia ke a breve uscira gestisce meglio le dx11 della controparte xke e piu potente o si limita solo a fare qualke cosa. Vale la pena aspettare per comprarla si o no?

[sickofitall]

Ciao a tutti, fatemi capire una cosa da tutte queste discursioni ma la futura scheda nvidia ke a breve uscira gestisce meglio le dx11 della controparte xke e piu potente o si limita solo a fare qualke cosa. Vale la pena aspettare per comprarla si o no?

senza bench ufficiali è difficile fare paragoni, il 26 avremo sicuramente le idee più chiare ;)

[Andrea deluxe]

http://forum.beyond3d.com/showpost.php?p=1404899&postcount=3138

[Alex656]

Ciao a tutti, fatemi capire una cosa da tutte queste discursioni ma la futura scheda nvidia ke a breve uscira gestisce meglio le dx11 della controparte xke e piu potente o si limita solo a fare qualke cosa. Vale la pena aspettare per comprarla si o no?

Secondo me per chiunque debba comprare una nuova scheda video di alto livello, a meno che non abbia una fretta estrema, conviene aspettare comunque fino a fine mese per avere dati certi sulla nuova architettura Nvidia; a meno che non abbiano il coraggio di far slittare anche la data ufficiale di lancio (23/3)

[mircocatta]

Non è del tutto vero.

Io mi ritengo uno di quelli da te descritti, ma ho scelto comunque una Ati 5850, da ex possessore di una fantastica 8800gt AMP.

L'ho scelta perchè ho tutte le features del momento. Dx11-Tassellation-Accelerazione encoding, decoding e delle prestazioni che nessun'altra scheda ha al momento nella stessa fascia di prezzo.
Senza contare l'overcloccabilità sbalorditiva con una facilità imbarazzante. Si clocca facilmente a 1ghz/1250 sopravanzando la sorella maggiore 5870, avendo risparmiato 100€!

Tu dimmi perchè avrei dovuto aspettare una scheda Nvidia, che per ora è solo utopia, ma si sa certamente che consumerà molto di più a pari prestazioni ed avrà prezzi lievemente più alti, per non parlare del calore emanato e quindi zero o quasi, overcloccabilità.

Per cosa avrei dovuto aspettare 6 mesi? Per physX? Per il 3dvision che serve un monitor apposito ed il corredo di occhiali il che si traduce in un esborso di soldi fuori dal normale.

Per me Nvidia stavolta ha toppato alla grande, aggiungendo, purtroppo.

rimpiango di non aver preso la 5870 al lancio quando costava 50€ in meno di ora :( :rolleyes:

ora mi sa che aspetterò a passare alle directx11... almeno fermi o un altra generazione ati..

[gelox15]

http://forum.beyond3d.com/showpost.php?p=1404899&postcount=3138

quindi forse in giugno saranno disponibili in quantita'...come si supponeva....

[Andrea deluxe]

quindi forse in giugno saranno disponibili in quantita'...come si supponeva....

maggio!

[Greifi Grishnackh]

maggio!
ma a quanto ho capito è probabile che gia da maggio si vedano delle revision B1?? e che probabilmente si vedranno le vere potenzialità con questo step entro un paio di mesi dal lancio?

[gelox15]

maggio!

si ho letto il post, gli ho dato 1 altro mese per avere la certezza :D

[faber80]

rimpiango di non aver preso la 5870 al lancio quando costava 50€ in meno di ora :( :rolleyes:

pensa invece a chi precedentemente si è tolto in fretta e furia, travolto dall'hype, la 5850/70 per avere l'imminente Fermi...... ; aggiungi anche che poi magari qualcuno ha accomodato con una precedente nvidia, e aggiornando i driver l'ha fusa....
morale: si saranno fustigati in diretta sky... :asd:

si ho letto il post, gli ho dato 1 altro mese per avere la certezza :D

Ok, ma che importanza può avere ? conta il numero di pezzi che escono, nn la data, poichè anche se escono a maggio con 10k pezzi, è come nn uscire. Io credo che dopo l'estate avremo i volumi (sempre se Nvidia nn decide di renderla veramente una serie fantasma).

[Athlon 64 3000+]

Revision A3 in quantità ridotta alla fine di questo mese in versione GTX470 e GTX480 e per maggio arriverà la revision B1 che dovrebbe portare finalmente le schede in volumi.

[gelox15]

Ok, ma che importanza può avere ? conta il numero di pezzi che escono, nn la data, poichè anche se escono a maggio con 10k pezzi, è come nn uscire. Io credo che dopo l'estate avremo i volumi (sempre se Nvidia nn decide di renderla veramente una serie fantasma).
certo,sono d accordo....era una battuta la mia ;)

[faber80]

certo,sono d accordo....era una battuta la mia ;)

lo so :D

[Blackcat73]

Chi vuole il massimo delle features, come Nemesis, acquisterà ugualmente nVidia. Physx ed il 3dVision possono piacere o non piacere, possono essere features vincenti o cagate, ma se uno vuole giocarsi un videogioco con tutte le features che implementa, senz'altro punterà sulle nuove nVidia... sopratutto se il tessellatore funzionerà, come dicono i rumors, molto meglio della controparte ATI ;)

Ok punta alle Nvidia.. ma se uno non le trova per carenza di pezzi sul mercato che fa aspetta in eterno?
P.s. Escludendo i "malati" :D (senza offesa per nessuno è solo una battutina si sa mai che in questo thread rischio il :banned: per una cosa simile

[Greifi Grishnackh]

Revision A3 in quantità ridotta alla fine di questo mese in versione GTX470 e GTX480 e per maggio arriverà la revision B1 che dovrebbe portare finalmente le schede in volumi.
è confermata questa notizia??? perchè se cosi fosse sarebbe una bella notizia....almeno non c'è da aspettare il respin 475-485 per avere una scheda al 100% senza problemi

[halduemilauno]

http://www.expreview.com/img/news/2010/03/10/galaxyfermi/1.jpg

[Simedan1985]

Se posso dire la mia ,questo divario di quasi una generazione tra Ati e nvidia mi preoccupa e non poco,e vi dico perche:

Con il flop (per chi si e per chi no) della serie hd2xxx, nvidia in tre anni è rimasta quasi ferma ,permettendo ad Ati di recuperare con le varie serie 3,4,5xxx...Ma come sarebbe stato lo scenario se nvidia avrebbe continuato con prodotti nuovi e sempre + innovativi per questi tre anni??

Adesso ,mettiamo il caso che queste fermi siano una base di partenza per un ottimo prodotto(sicuramente lo saranno)....ma io non penso che Ati si prenda degli anni "sabbatici"...si sa che a breve ci sarà un ipotetica 5890,ma la cosa che più mi fa pensare è che già i primi di ottobre 2009 si parlava tutti di NI.

La morale è che a questo giro nessuno dorme e corrono tutti....ma nvidia se vuole recuperare,a meno che non si ferma Ati, deve correre di +

Sbaglio?

[skizzo99999999]

ok, ma non possiamo ipitizzare qualcosa che non può essere ipotizzato perchè non funziona così. :D


mi hai chiesto tu di immaginare:

"se immagini un'elaborazione di tipo seriale (...) allora toriniamo al concetto di pipeline classica e si perde gran parte del vantaggio degli shader unificati"

e visto che non ne ero convinto, ho immaginato lo scenario prospettatomi e mostrato che in quel caso gli shader unificati sarebbero stati ancora più avvantaggiati e non più penalizzati. tutto qui. Poi se sono stato io ad aver capito male pazienza.


continui a ragionare considerando che il tessellator sia quello che assorbe più risorse. Ti stupiresti se ti dicessi che in un'operazione di tessellation sono spesso i domain shader ad occupare la maggior parte del tempo? Questo significa che fermi avrà uno degli stadi di tessellation con maggiori latenze (il problema è proprio quello) a carico dello shader core mentre cypress fa uso di unità dedicate.
Torno a ripetere, se una gpu sta lavorando a tessellator spento e si accende il tessellator, nel caso in cui lo stesso fa uso di unità generiche condivise da altri stadi, l'elaborazione relativa a questi ultimi rallenta inevitabilmente e questo significa sottrarre risorse ad altre elaborazioni. E' evidente che nVidia non si è potuta per mettere di far uso di unità dedicate (avrebbe anche potuto frammentare il tessellator, come ha fatto, ma utilizzando unità dedicate ma non lo ha fatto e non per libera scelta ma perchè il die di fermi è già enorme di suo).
E' altrettanto evidente che nel caso di RV870, il tessellator non sottrare risorse ad alcunchè.
Nell'ipotesi che sia un solo cluster ad occupare l'area di hull e domain shader, quando si farà tessellation quel cluster in più non sarà un vantaggio perchè, a parità di area occupata, hull e domain shader sono più veloci (hanno meno latenze e impiegano meno cicli, sono più numerosi perchè, in quanto unità dedicate occupano meno spazio, ecc).
Ti rifaccio l'esempio precedente; in R600 il MSAA box fa resolve via shader; hanno tolto l'unità dedicata di tipo INT dalle ROP's, hanno guadagnato spazio per mettere altre alu, eppure il MSAA va molto peggio.

L’esempio dell’antialiasing sarebbe corretto se stessimo valutando l’implementazione via shader del tessellatore e non di hull e domain. MSAA via shader è molto più penalizzante che non domain e hull, perché queste sempre unità programmabili sono.
Sul fatto che i domain possano anche occupare una notevole quantità di risorse non lo metto in dubbio: sono programmabili, e quindi il programmatore può piazzarci un programma arbitrariamente (nei limiti delle scpecifiche) complesso. Ma andare oltre un certo limite non ha senso.
Faccio un esempio che anche se non è molto corretto rende l’idea in modo facilmente comprensibile a tutti.
Io posso tessellare un rettangolo e farne una bandiera che sventola, oppure partire da un parallelepipedo per tirare fuori una ferrari. Il primo esempio è sensato, mentre il secondo no. Utilizzerei molto meglio le risorse (è impiegherei meno tempo) se partissi già da una geometria un poco più somigliante a quello che voglio ottenere (aggiungendo al modello di partenza una manciata di poligoni), per rendere il lavoro più snello negli stadi successivi. Questo non vuol dire fare una tessellazione della geometria più leggera o più pesante, ma diciamo più “intelligente”, che comunque è quello che si fa normalmente (o almeno io ho visto sempre fare così).
Ovvio che se prendesse piede un modo di tessellare brutale tipo parallelepipedo->macchina, allora la tipologia hull-domain via sp potrebbe soffrire. Dico potrebbe perché comunque non possiamo (ancora) quantificare la penalità (secondo me comunque bassa) che intercorre nel portare hull e domain negli sp rispetto ai benefici che si ottengono in tutte le altre fasi di shading.
Sul fatto del rallentamento dell’esecuzione e quindi della sottrazione delle risorse mi sembra di aver già detto e spiegato come la penso e quindi mi ripeterei e basta.
Per carità non voglio convincere a forza nessuno, era solo per portare un punto di vista differente, che si può condividere o meno. Ovvio che, siccome sono io che esprimo la mia opinione, la ritengo valida :D

[Pat77]

Se posso dire la mia ,questo divario di quasi una generazione tra Ati e nvidia mi preoccupa e non poco,e vi dico perche:

Con il flop (per chi si e per chi no) della serie hd2xxx, nvidia in tre anni è rimasta quasi ferma ,permettendo ad Ati di recuperare con le varie serie 3,4,5xxx...Ma come sarebbe stato lo scenario se nvidia avrebbe continuato con prodotti nuovi e sempre + innovativi per questi tre anni??

Adesso ,mettiamo il caso che queste fermi siano una base di partenza per un ottimo prodotto(sicuramente lo saranno)....ma io non penso che Ati si prenda degli anni "sabbatici"...si sa che a breve ci sarà un ipotetica 5890,ma la cosa che più mi fa pensare è che già i primi di ottobre 2009 si parlava tutti di NI.

La morale è che a questo giro nessuno dorme e corrono tutti....ma nvidia se vuole recuperare,a meno che non si ferma Ati, deve correre di +

Sbaglio?

hd2900 non fu un flop, secondo me Fermi non lo sarà nemmeno lei, nel senso che è un'altra base per una serie di gpu future forse meglio collocate.
Flop sono schede che non vendono, che costano troppo rispetto a quello che dannno, o che andavano la metà come le Fx.

[appleroof]

hd2900 non fu un flop, secondo me Fermi non lo sarà nemmeno lei, nel senso che è un'altra base per una serie di gpu future forse meglio collocate.
Flop sono schede che non vendono, che costano troppo rispetto a quello che dannno, o che andavano la metà come le Fx.

cioè appunto la hd2900xt....:stordita:

[Pike79]

Un B1 in 4 mesi è fantascienza...

http://forum.beyond3d.com/showpost.php?p=1404908&postcount=3141

Non è che la famigerata B1 sia in realtà l' A3? Oppure che voleva dire questo utente?

[Pike79]

Intende dire che il prodotto GTX4xx arriverà sul mercato in quantità risibili in A3 e in volumi in B1.

Ma in 4 mesi ci credo solo se lo vedo che hanno pronto e sul mercato in volumi un B1. Essenzialmente vorrebbe dire che hanno cominciato il lavoro sul B1 prima di avere l'A3 pronto, cosa che non ha alcun barlume di logica ;)

Mah, da come l' ha scritto (due parole in piu' no, eh?) sembrava che si commercializzassero le A2 per poi creare volumi delle A3, ribattezzate per l' occasione B1. Comunque sembra difficile anche a me, nonostante non ponga limiti all' ingegno e alla provvidenza...

[veltosaar]

Ma secondo voi il B1 avrà frequenze\pcb\nome e sigla diverse come fu per la gtx285 rispetto alla gtx280?

[gelox15]

Intende dire che il prodotto GTX4xx arriverà sul mercato in quantità risibili in A3 e in volumi in B1.

Ma in 4 mesi ci credo solo se lo vedo che hanno pronto e sul mercato in volumi un B1. Essenzialmente vorrebbe dire che hanno cominciato il lavoro sul B1 prima di avere l'A3 pronto, cosa che non ha alcun barlume di logica ;)
sono d accordo :)

[appleroof]

Fud, ma sembra marketing ufficiale:

“We redesigned GF100 from the ground up to deliver the best performance on DX11. This meant adding dedicated h/w engines in our GPU to accelerate key features like tessellation.

We also made changes on the compute side that specifically benefit gamers like interactive ray-tracing and faster physics performance through things like support for concurrent kernels.

Unfortunately all of these changes took longer than we originally anticipated and that’s why we are delayed.

Do we wish we had GF100 today? Yes. However based on all the changes we made will GF100 be the best gaming GPU ever built. Absolutely.”

http://www.fudzilla.com/content/view/18016/1/

aggiungo solo che è palese che non sono questi i motivi del ritardo

[yossarian]

L’esempio dell’antialiasing sarebbe corretto se stessimo valutando l’implementazione via shader del tessellatore e non di hull e domain. MSAA via shader è molto più penalizzante che non domain e hull, perché queste sempre unità programmabili sono.

il resolve consiste in una semplice interpolazione lineare, analoga a quella che le alu fanno per le operazioni di filtraggio delle texture; eppure il calo prestazionale è notevole



Sul fatto che i domain possano anche occupare una notevole quantità di risorse non lo metto in dubbio: sono programmabili, e quindi il programmatore può piazzarci un programma arbitrariamente (nei limiti delle scpecifiche) complesso. Ma andare oltre un certo limite non ha senso.
Faccio un esempio che anche se non è molto corretto rende l’idea in modo facilmente comprensibile a tutti.
Io posso tessellare un rettangolo e farne una bandiera che sventola, oppure partire da un parallelepipedo per tirare fuori una ferrari. Il primo esempio è sensato, mentre il secondo no. Utilizzerei molto meglio le risorse (è impiegherei meno tempo) se partissi già da una geometria un poco più somigliante a quello che voglio ottenere (aggiungendo al modello di partenza una manciata di poligoni), per rendere il lavoro più snello negli stadi successivi. Questo non vuol dire fare una tessellazione della geometria più leggera o più pesante, ma diciamo più “intelligente”, che comunque è quello che si fa normalmente (o almeno io ho visto sempre fare così).
Ovvio che se prendesse piede un modo di tessellare brutale tipo parallelepipedo->macchina, allora la tipologia hull-domain via sp potrebbe soffrire. Dico potrebbe perché comunque non possiamo (ancora) quantificare la penalità (secondo me comunque bassa) che intercorre nel portare hull e domain negli sp rispetto ai benefici che si ottengono in tutte le altre fasi di shading.
Sul fatto del rallentamento dell’esecuzione e quindi della sottrazione delle risorse mi sembra di aver già detto e spiegato come la penso e quindi mi ripeterei e basta.
Per carità non voglio convincere a forza nessuno, era solo per portare un punto di vista differente, che si può condividere o meno. Ovvio che, siccome sono io che esprimo la mia opinione, la ritengo valida :D

i domain shader presentano un piccolo problema: sono quelli che, di fatto, costruiscono la nuova mesh tessellata e si occupano anche del displacement mapping. Il che significa che devono fare accesso a texture e le latenze schizzano alle stelle, indipendentemente da quello che il programmatore decide di scrivere.
Infine, un'ultima cosa sul test unigine; oltre alla scarsa attendibilità dovuta all'utilizzo di 2 versioni differennti di cui quella usata da nVidia con molto meno overdraw dovuto alla più efficiente gestione delle operazioni di culling, la 5870 ha anche un problema, in quello specifico test, nella gestione degli accessi alla LDS (local data share) durante le operazioni di tessellation in particolare che provoca delle latenze anomale che causano un decadimento prestazionale stimabile tra il 10 ed il 15%. Questo problema è risolvibile via driver ma, mettendo a sistema le due cose (non corretta gestione della LDS e differenti versioni del bench), si può concludere che unigine sia un test tutt'altro che attendibile anche ai fini della valutazione delle performance con la tessellation. Resta solo un bel demo di un posto in cui mi piacerebbe vivere :D

[marco XP2400+]

con questa parte
nVidia ha usato una versione differente, la 1.1, che permette un incremento prestazionale del 30% in quanto riduce l'overdraw dovuto alle superfici nascoste grazie ad un uso più aggressivo delle operazioni di culling. Questo incremento, su un'architettura come quella di fermi che si giova in misuta maggiore, della riduzione di tale overdraw perchè scarica gran parte del lavoro delle unità di shading e ha più risorse da dedicate alla tessellation, può avere anche valori superiori al 30%

ed anche quest'altra parte

Infine, un'ultima cosa sul test unigine; oltre alla scarsa attendibilità dovuta all'utilizzo di 2 versioni differennti di cui quella usata da nVidia con molto meno overdraw dovuto alla più efficiente gestione delle operazioni di culling, la 5870 ha anche un problema, in quello specifico test, nella gestione degli accessi alla LDS (local data share) durante le operazioni di tessellation in particolare che provoca delle latenze anomale che causano un decadimento prestazionale stimabile tra il 10 ed il 15%. Questo problema è risolvibile via driver ma, mettendo a sistema le due cose (non corretta gestione della LDS e differenti versioni del bench), si può concludere che unigine sia un test tutt'altro che attendibile anche ai fini della valutazione delle performance con la tessellation. Resta solo un bel demo di un posto in cui mi piacerebbe vivere :D

penso che sei riuscito a rendere l'idea che sia un test, per l'attuale confronto prestazionale tra le due schede, molto meno attendibile di quanto ci si potesse aspettare!! grazie degli interventi sul forum e dell'articolo (http://www.appuntidigitali.it/7628/parti-funzionali-di-una-gpu-il-tessellator-ii-parte/)...

[Andrea deluxe]

so che non ha alcun valore....

http://img707.imageshack.us/img707/9531/gtx470expreview06.jpg

gtx 470

[Andrea deluxe]

http://www.youtube.com/watch?v=VpZXhR1ibj8

:D

[aledemo]

so che non ha alcun valore....

http://img707.imageshack.us/img707/9531/gtx470expreview06.jpg

gtx 470

continuano a puntare sulla quantita di memoria in piu x risoluzione e aa..

[aaasssdddfffggg]

è confermata questa notizia??? perchè se cosi fosse sarebbe una bella notizia....almeno non c'è da aspettare il respin 475-485 per avere una scheda al 100% senza problemi

Io ormai ho rimandato la spesa delle vga per giugno quindi ben venga se mi ritroverò tra le mani quanto afferma la notizia.:)

[Marscorpion]

Io ormai ho rimandato la spesa delle vga per giugno quindi ben venga se mi ritroverò tra le mani quanto afferma la notizia.:)

Ci credo soltanto se a Giugno vedo ancora in firma le GTX295 ! :D

[aaasssdddfffggg]

Ci credo soltanto se a Giugno vedo ancora in firma le GTX295 ! :D

:asd:

[zorco]

Io ormai ho rimandato la spesa delle vga per giugno quindi ben venga se mi ritroverò tra le mani quanto afferma la notizia.:)
:mano:

[zorco]

Molti si chiedono quale sia la causa del prolungato ritardo di una delle GPU più attese del mercato. Stiamo parlando delle NVIDIA GeForce GTX 480 e 470, basate sulla GPU GF100, conosciuta anche con il nome NVIDIA Fermi.

NVIDIA ha dato una prima risposta a questi ritardi:

“We redesigned GF100 from the ground up to deliver the best performance on DX11. This meant adding dedicated h/w engines in our GPU to accelerate key features like tessellation.

We also made changes on the compute side that specifically benefit gamers like interactive ray-tracing and faster physics performance through things like support for concurrent kernels.

Unfortunately all of these changes took longer than we originally anticipated and that’s why we are delayed.

Do we wish we had GF100 today? Yes. However based on all the changes we made will GF100 be the best gaming GPU ever built. Absolutely.”

Dalle dichiarazioni emerge che NVIDIA sta lavorando duro per avere una scheda che offra le migliori prestazioni in ambiti come la tessellation, il calcolo del ray-tracing e della fisica e a loro detta sarà la migliore GPU per il gaming mai costruita.

Per il momento però tutti gli appassionati vedono solo molte parole ed i ritardi allungarsi di volta in volta, per una storia che ci ricorda molto quanto successo ad ATI con il lancio di R600 (ATI 2900XT). Non ci resta che attendere il lancio ufficiale per scoprire se sono solo parole o se Fermi è veramente la "migliore GPU mai costruita".

http://www.hwstation.net/news/schede_video-4/3033.html

[goten]

spiegami dovrebbe andare di + di una scheda che costa di +???? per carità magari vado di + e spendo di -.
Costa di piu' cosa? Si parlava del fatto che la 470 potesse costare 350€ andando leggermente peggio della 5870. La 5870 ora la si trova a 350€ tranquillamente. Spiegami tu dove sarebbe il vantaggio di andarsi a comprare una scheda che a parità di prezzo con la concorrenza va meno :asd:
Senza considerare prevedibili ribassi della Ati sulle sue schede.
Se la mettono a quel prezzo e per fare concorrenza alla 5870, perciò andrà + o - uguale. Stai tranquillo che se andrà anche solo 2 fps in più della 5870 la vendono a 400 euro.

Lo spero per Nvidia che vada piu' forte della 5870, altrimenti, ripeto, non ha nessun senso.

Alla fine, tolti i fanboy, tutti cerchiamo di comprare la roba piu' performante al prezzo migliore. Se mi metti due schede che vanno praticamente uguale e una costa meno dell'altra è pacifico che l'utenza si orienterà su quella piu' economica. Senza stare neanche a voler considerare i consumi.

[Marscorpion]

Alla fine, tolti i fanboy, tutti cerchiamo di comprare la roba piu' performante al prezzo migliore. Se mi metti due schede che vanno praticamente uguale e una costa meno dell'altra è pacifico che l'utenza si orienterà su quella piu' economica. Senza stare neanche a voler considerare i consumi.

Penso sia la cosa più logica da fare.......

[Horizont]

http://www.youtube.com/watch?v=VpZXhR1ibj8

:D

AHAHAHHAHAHA ormai sto video lo stanno usando per tutti i tipi di lamentele verso un prodotto/persona ahahah

[Pike79]

http://forum.beyond3d.com/showpost.php?p=1405065&postcount=3181

[ghiltanas]

così il 470, come velocita della ram andrebbe a 4000mhz invece di 3200?
mah vedremo :confused:

è decisamente strana l'indicazione delle frequenza delle ram...perchè 2000 e 4000 fra parentesi? :confused:
in caso di gddr5 dovrebbero scrivere 1000 ( a 4000 effettivi quindi)

[ghiltanas]

http://www.expreview.com/img/news/2010/03/10/galaxyfermi/1.jpg

continuano a far vedere unicamente gtx470...di 480 probabilmente ne avranno prodotte 10 se va bene :mbe:

[B|4KWH|T3]

mi hai chiesto tu di immaginare:

"se immagini un'elaborazione di tipo seriale (...) allora toriniamo al concetto di pipeline classica e si perde gran parte del vantaggio degli shader unificati"

e visto che non ne ero convinto, ho immaginato lo scenario prospettatomi e mostrato che in quel caso gli shader unificati sarebbero stati ancora più avvantaggiati e non più penalizzati. tutto qui. Poi se sono stato io ad aver capito male pazienza.



L’esempio dell’antialiasing sarebbe corretto se stessimo valutando l’implementazione via shader del tessellatore e non di hull e domain. MSAA via shader è molto più penalizzante che non domain e hull, perché queste sempre unità programmabili sono.
Sul fatto che i domain possano anche occupare una notevole quantità di risorse non lo metto in dubbio: sono programmabili, e quindi il programmatore può piazzarci un programma arbitrariamente (nei limiti delle scpecifiche) complesso. Ma andare oltre un certo limite non ha senso.
Faccio un esempio che anche se non è molto corretto rende l’idea in modo facilmente comprensibile a tutti.
Io posso tessellare un rettangolo e farne una bandiera che sventola, oppure partire da un parallelepipedo per tirare fuori una ferrari. Il primo esempio è sensato, mentre il secondo no. Utilizzerei molto meglio le risorse (è impiegherei meno tempo) se partissi già da una geometria un poco più somigliante a quello che voglio ottenere (aggiungendo al modello di partenza una manciata di poligoni), per rendere il lavoro più snello negli stadi successivi. Questo non vuol dire fare una tessellazione della geometria più leggera o più pesante, ma diciamo più “intelligente”, che comunque è quello che si fa normalmente (o almeno io ho visto sempre fare così).
Ovvio che se prendesse piede un modo di tessellare brutale tipo parallelepipedo->macchina, allora la tipologia hull-domain via sp potrebbe soffrire. Dico potrebbe perché comunque non possiamo (ancora) quantificare la penalità (secondo me comunque bassa) che intercorre nel portare hull e domain negli sp rispetto ai benefici che si ottengono in tutte le altre fasi di shading.
Sul fatto del rallentamento dell’esecuzione e quindi della sottrazione delle risorse mi sembra di aver già detto e spiegato come la penso e quindi mi ripeterei e basta.
Per carità non voglio convincere a forza nessuno, era solo per portare un punto di vista differente, che si può condividere o meno. Ovvio che, siccome sono io che esprimo la mia opinione, la ritengo valida :D

Scusami, se ho capito bene il tuo ragionamento si basa su questo assunto:

Separiamo il tempo T di generazione del frame in N+M, con N tempo di shading ed M tempo di tessellation (considerando per semplicità tutte le altre fasi non significative in termini di tempo).
Poichè N>>M, allora l'impatto della latenza maggiore dello svolgimento della tessellation con ALU generiche anziché che con funzioni fisse sul tempo T diventa trascurabile.

Io però ti rovescio il ragionamento: poichè per fare la fase M sottraggo risorse alla fase N che è >>M, allora è proprio l'approccio ATI ad avvantaggiarsi poichè dedica sempre lo stesso numero di risorse alla fase che occupa il maggior tempo nella generazione del frame. Al contrario l'approccio nVidia sottrae risorse proprio alla fase N.

Tu mi rispondi: sì, ma questo è compensato dal fatto che nella fase N ho più risorse a parità di DIE poichè al posto delle funzioni fisse ho messo unità che possono svolgere shading (fase N) oltre a tessellation (fase M)


Quindi l'invito che faccio è: dovete spostare il ragionamento su come viene bilanciato il lavoro e fare qualche conticino. Per lo meno con la serie ATI 5*** e poi fare una stima su GTX4**
La chiave dovrebbe essere lì.


EDIT: Aggiungo per specificare meglio: la chiave dovrebbe essere l'efficienza nello shading fra sp di ATI e sp di nVidia

[appleroof]

Scusami, se ho capito bene il tuo ragionamento si basa su questo assunto:

Separiamo il tempo T di generazione del frame in N+M, con N tempo di shading ed M tempo di tessellation (considerando per semplicità tutte le altre fasi non significative in termini di tempo).
Poichè N>>M, allora l'impatto della latenza maggiore dello svolgimento della tessellation con ALU generiche anziché che con funzioni fisse sul tempo T diventa trascurabile.

Io però ti rovescio il ragionamento: poichè per fare la fase M sottraggo risorse alla fase N che è >>M, allora è proprio l'approccio ATI ad avvantaggiarsi poichè dedica sempre lo stesso numero di risorse alla fase che occupa il maggior tempo nella generazione del frame. Al contrario l'approccio nVidia sottrae risorse proprio alla fase N.

Tu mi rispondi: sì, ma questo è compensato dal fatto che nella fase N ho più risorse a parità di DIE poichè al posto delle funzioni fisse ho messo unità che possono svolgere shading (fase N) oltre a tessellation (fase M)


Quindi l'invito che faccio è: dovete spostare il ragionamento su come viene bilanciato il lavoro e fare qualche conticino. Per lo meno con la serie ATI 5*** e poi fare una stima su GTX4**
La chiave dovrebbe essere lì.


EDIT: Aggiungo per specificare meglio: la chiave dovrebbe essere l'efficienza nello shading fra sp di ATI e sp di nVidia

considerando che l'architettura Nvidia è più efficiente (tra l'altro se non sbaglio gli sp possono fare un'operazione per ciclo di clock, ma per questo il clock dell'architettura Nvidia è maggiore che quello dell'Ati) mi pare che tu abbia colto il punto;

cmq credo di essere facile profeta se dico che tutto dipenderà da come i giochi verranno sviluppati, e che come al solito nessuna delle due soluzioni prevarrà sull'altra in maniera netta

sarà piuttosto curioso vedere come Ati implementerà la tasselletion su NI, che in quanto architettura totalmente nuova da quella attuale derivata da R600, potrebbe avere novità anche da questo punto di vista (a differenza di Nvidia che per qualche tempo si affiderà all'architettura vista in Fermi...almeno pare)

[Bramino]

è decisamente strana l'indicazione delle frequenza delle ram...perchè 2000 e 4000 fra parentesi? :confused:
in caso di gddr5 dovrebbero scrivere 1000 ( a 4000 effettivi quindi)

Per confondere meglio la clientela. :D

[PConly92]

una notizia interessante:(
http://www.tomshw.it/cont/news/physx-nvidia-compra-gli-sviluppatori-amd-furiosa/24364/1.html
:doh:

[Bramino]

una notizia interessante:(
http://www.tomshw.it/cont/news/physx-nvidia-compra-gli-sviluppatori-amd-furiosa/24364/1.html
:doh:

Qualcuno ha avuto il coraggio di scrivere quello che già si sapeva da anni. :(

[Horizont]

continuano a far vedere unicamente gtx470...di 480 probabilmente ne avranno prodotte 10 se va bene :mbe:

sbaglio o leggo MINUMUM 550W PSU???

[ghiltanas]

sbaglio o leggo MINUMUM 550W PSU???

di quello nn c'è da stupirsi, basti pensare che per la 5850 minimum 500w...è un dato che di per se nn dice molto, bisogna vedere quanti ampere sulla 12v chiederà effettivamente

[viper-the-best]

sbaglio o leggo MINUMUM 550W PSU???

devono stare larghi, solitamente chi ha queste schede di fascia alta ha anche altri processori e componenti di fascia alta (vedi es. i7 che consuma abbastanza) ma imho se si ha un penryn o un i5, un buon 480w ce la fa senza problemi

[egounix]

sbaglio o leggo MINUMUM 550W PSU???

anche nella 275gtx c'è scritto
comunque dipende sempre dalla qualità dell'ali, ma come già detto chi compra queste schede ha alimentatori di qualità, perchè ha già un sistema di fascia alta

può succedere, e c'è un post aperto, che qualcuno compri o riceva una vga di fascia alta o medio-alta e abbia un alimentatore non adeguato anche se questi sia di 500-550w o superiore ai w consigliati

dovrebbero essere più chiari e scrivere la qualità della linea cui necessitano queste schede
se lo facessero, però, rischierebbero di non non vendere a chi magari fa gola una scheda simile, ma che non ha, perchè non conosca, un sistema adeguato

[skizzo99999999]

Scusami, se ho capito bene il tuo ragionamento si basa su questo assunto:

Separiamo il tempo T di generazione del frame in N+M, con N tempo di shading ed M tempo di tessellation (considerando per semplicità tutte le altre fasi non significative in termini di tempo).
Poichè N>>M, allora l'impatto della latenza maggiore dello svolgimento della tessellation con ALU generiche anziché che con funzioni fisse sul tempo T diventa trascurabile.

Io però ti rovescio il ragionamento: poichè per fare la fase M sottraggo risorse alla fase N che è >>M, allora è proprio l'approccio ATI ad avvantaggiarsi poichè dedica sempre lo stesso numero di risorse alla fase che occupa il maggior tempo nella generazione del frame. Al contrario l'approccio nVidia sottrae risorse proprio alla fase N.

Tu mi rispondi: sì, ma questo è compensato dal fatto che nella fase N ho più risorse a parità di DIE poichè al posto delle funzioni fisse ho messo unità che possono svolgere shading (fase N) oltre a tessellation (fase M)


Quindi l'invito che faccio è: dovete spostare il ragionamento su come viene bilanciato il lavoro e fare qualche conticino. Per lo meno con la serie ATI 5*** e poi fare una stima su GTX4**
La chiave dovrebbe essere lì.


EDIT: Aggiungo per specificare meglio: la chiave dovrebbe essere l'efficienza nello shading fra sp di ATI e sp di nVidia

Non è la differenza di efficienza tra gli sp dei due rivali a stabilire quale sia l'approccio migliore. Il confronto si dovrebbe fare tra due schede identiche, una con hull e domain tramite unità dedicate ma con meno sp (un Fermi virtuale) e l'altra con il Fermi attuale. Inoltre bisognerebbe considerare che se ci fossero unità dedicate a hull e domain probabilmente in fermi non si sarebbe optato per l'enorme complicazione portata dalla frammentazione con potenziamento del polymorph engine per "avvicinare" il tessellatore allo shader core, in modo da diminuire le risorse necessarie al travaso di dati fra gli elementi. Questo avrebbe portato sicuramente ad una diminuzione dell'area occupata da queste unità, capace magari di alzare il numero di sp e probabilmente di avvicinarne il numero di quelli presenti nella configurazione attuale.
Quindi fare calcoli precisi è praticamente impossibile, anche investendoci una quantità elevata di tempo. Quello che voglio sottolineare è comunque che non si sottrae niente, perchè gli sp generici che uso per hull e domain non ci sarebbero potuti essere se si fosse optato per unità dedicate.
se non li hai letti e hai pazienza leggiti questi due post precedenti, in cui ho messo dei numeri fittizzi per rendere meglio l'idea (soprattutto nel secondo)

http://www.hwupgrade.it/forum/showpost.php?p=31180044&postcount=23307
http://www.hwupgrade.it/forum/showpost.php?p=31182230&postcount=23328

Tutto sta a vedere quanto si perde in efficienza a far fare le operazioni di hull e domain a sp generici. Visto i precedenti tra pixel+vertex uniti in unità generiche (e nessuno è tornato indietro) mi sento di ipotizzare che l'approccio unificato dovrebbe essere quello migliore, ma ovviamente non è detto. Certo che se NVIDIA ha deciso di sbattersi in quel modo con il polymorph engine penso che due conti li abbia fatti. Poi può averli sbagliati non ponderando adeguatamente tutte le variabili in gioco. Chi mastica l'inglese può guardare quello scritto dal buon derek (abbastanza semplificato da essere facilmente comprensibile):
http://www.anandtech.com/video/showdoc.aspx?i=3507&p=1
e vedere il "dramma" progettuale del polymorph engine frammentato. Certo, si potrebbe dire che anche ATI avrà fatto le sue valutazioni (avendo già una architettura senza hull e domain) per scegliere diversamente. Ma è possibile che abbia valutato troppo complesso (+tempo di progettazione) fare una scelta simile al polymorph engine oppure che visto il sistema simil VLIW delle sue sp il tutto era troppo penalizzante, mentre nel sistema NVIDIA la penalità è risultata minore in misura tale da rendere redditizio quel sistema. Anche se per ATI avesse prevalso solo il fattore della semplicità progettuale, visto la situazione attuale con milioni di schede già vendute e NVIDIA con il cerino in mano chi può dirgli niente?

Bisogna considerare anche che con l'uso sempre più generalizzato di motori deferred la fase geometrica è non dico trascurabile, ma è molto meno importante in termini di risorse/tempo impiegato rispetto a tutto il resto della pipeline di rendering. Gli algoritmi di illuminazione e post processing sempre più realistici agiscono ormai sempre a livello di fragment e non di vertex, per cui è richiesta una enorme potenza di fragment shader. Per cui anche se perdessi in efficienza durante la tessaellazione per un fattore moderatamente elevato (non dico tempi più elevati, perchè con l'approccio unificato il tempo dipende soltanto da quanti sp gli dedico, è l'efficienza dell'uso degli stessi che diminuisce rispetto ad averli dedicati), avere risorse maggiori anche solo del 5-10% per il fragment shading potrebbe portare a diminuire il tempo totale di generazione del frame.

[Greifi Grishnackh]

http://forum.beyond3d.com/showpost.php?p=1405065&postcount=3181
ottimo....quindi venerdi si vedrà qualcosa ;)

[Greifi Grishnackh]

**fixed**

:asd: :asd: :asd: ....beh il "forse" e il "presumibilmente" è d'obbligo sempre

[luX0r.reload]

L'hai detto tu che i rumors parlano di prestazioni sconvolgenti del tessellator, non io. Non c'è alcun rumor al riguardo, solo notizie ufficiali (sì, ufficiali) non replicabili in un sistema di test e il rumor sul 5%. Il rumor che dici te lo sei inventato.
Fino ad una settimana fa di ufficiale non c'era niente... il thread al 90% è composto da rumors e tu ora mi dici che non c'è nessun rumors a riguardo :D :sofico:

... hai ragione... "then you win"!

[eXeS]

Infine, un'ultima cosa sul test unigine; oltre alla scarsa attendibilità dovuta all'utilizzo di 2 versioni differennti di cui quella usata da nVidia con molto meno overdraw dovuto alla più efficiente gestione delle operazioni di culling, la 5870 ha anche un problema, in quello specifico test, nella gestione degli accessi alla LDS (local data share) durante le operazioni di tessellation in particolare che provoca delle latenze anomale che causano un decadimento prestazionale stimabile tra il 10 ed il 15%.
Questo problema è risolvibile via driver ma

E che aspetta AMD a risolverlo, visto che Unigine è stato preso da chiunque in modo proprio o improprio come il bench definitivo, per valutare le prestazioni delle schede DX11 con tessellation attiva.

, mettendo a sistema le due cose (non corretta gestione della LDS e differenti versioni del bench), si può concludere che unigine sia un test tutt'altro che attendibile anche ai fini della valutazione delle performance con la tessellation. Resta solo un bel demo di un posto in cui mi piacerebbe vivere :D
Quindi, quando AMD avrà sistemato lato driver gli accessi alla LDS, e la 1.1 sarà pubblica i risultati saranno più indicativi, o Unigine continuerà ad essere ancora un bench favorevole a Fermi ?

Ma poi, favorevole perchè ?

Ci sono forse dati che dicono che l'operazione di tessellation, e non gli effetti collaterali derivanti dall'aumento della complessità delle geometrie, è l'operazione che nel tempo complessivo necessario alla rasterizzazione del singolo frame, ha maggior peso ?

Oppure qualcuno ha fatto un profiling dell'uso delle alu su Fermi, ed ha rilevato che in Unigine le alu sono impegnate soprattutto a tessellare ?

[yossarian]

E che aspetta AMD a risolverlo, visto che Unigine è stato preso da chiunque in modo proprio o improprio come il bench definitivo, per valutare le prestazioni delle schede DX11 con tessellation attiva.



un bench definitivo basato su versioni differenti? I risultati del 3dmark2001 e quelli del 3dmark2003 sono comparabili? La versione 1.0 ha chiari problemi di overdraw, per ammissione degli stessi sviluppatori di unigine.


Quindi, quando AMD avrà sistemato lato driver gli accessi alla LDS, e la 1.1 sarà pubblica i risultati saranno più indicativi, o Unigine continuerà ad essere ancora un bench favorevole a Fermi ?

Ma poi, favorevole perchè ?


dove ho scritto che è un bench favorevole a fermi?



Ci sono forse dati che dicono che l'operazione di tessellation, e non gli effetti collaterali derivanti dall'aumento della complessità delle geometrie, è l'operazione che nel tempo complessivo necessario alla rasterizzazione del singolo frame, ha maggior peso ?


ci sono dati che dicono che lo stesso test ripetuto a diverse risoluzioni dà, qualitativamente, gli stessi risultati; il che significa che il calo di prestazioni se è imputabile all'aumento della complessità poligonale in seguito alla tessellation lo è solo in minima parte.



Oppure qualcuno ha fatto un profiling dell'uso delle alu su Fermi, ed ha rilevato che in Unigine le alu sono impegnate soprattutto a tessellare ?

se fossero impegnate solo a tessellare le prestazioni di fermi sarebbero ben misere. Tanto varrebbe fare un test in wireframe :D

[Rsdj]

Ancora a perdere tempo con l'Unigine? :D

E' vero è molto bello ma come già detto e ridetto la tessellation non sarà mai applicata in quel modo nei giochi, ovvero negli oggetti in lontanza dove non serve... si andrebbe contro il principio stesso della tessellation, che non è nata per essere applicata ovunque, ma solamente dove è tangibile la differenza cercando di limitare l'utilizzo di risorse.

[persa]

http://www.pctunerup.com/up/results/_201003/20100310221345_HAWX_25_8aa.jpg

[persa]

ancora con sto catalytic http://www.pctunerup.com/up//results/_201003/20100310221438_icon_confused.gif

[persa]

infatti.. anche a me interessano di + i test @ 1920x1200.

[persa]

Probabilmente questi recensori sono un po' catatonic :asd:

:asd:

[Rsdj]

Infatti hanno rotto co sti Catalityc :asd:

[aaasssdddfffggg]

Si vedono solo leak (veri o falsi che siano) in cui Cypress è bandwidth limited... sarà molto interessante vedere i test in semplice FullHD...

Come già dicevo da gennaio, si vedranno finalmente le recensioni con AA8x, da tutte quelle redazioni che seguiranno pedissequamente la review guide di nVIDIA.

Non vedo l'ora di leggere la review di Anand :asd:

Vedo che per la NVIDIA sono stati usati i 196.78 ,ovvero i driver successivi al famoso bug driver (196.75)che ha fatto fuori diverse vga tra gli utenti.:)

[aaasssdddfffggg]

Probabilmente non sarà comunque la versione di lancio... vedremo...

Si ne sono quasi certo anche io che non saranno quelli...magari al lancio vedremo un bel pacchetto driver siglato 200 giusto per marcare l'entrata di Fermi...:D

[aaasssdddfffggg]

Ecco appunto la news dei 196.78 :

"It was found out that a beta driver by NVIDIA, GeForce 196.78 supports GeForce 400 series accelerators, and was able run a qualification sample of GeForce GTX 470. The card was using A3 revision GF100 silicon. The driver's System Information dialog revealed that the card indeed has 448 CUDA cores (SIMD units). Further, it has 1280 MB of memory, and a 320-bit wide memory interface. NVIDIA also changed the way it represents memory clock speeds. Since it is using GDDR5 memory, while the memory has an actual clock speed of 1000 MHz, the data rate (DDR speed) is represented first, as 2000 MHz, and "effective speed" next, which is 4000 MHz. "

http://www.techpowerup.com/117181/GeForce_196.78_Beta_Driver_Runs_GeForce_GTX_470.html

[Jackaos]

Non ho capito come mai hanno cambiato il valore base di velocità delle memorie, chi me lo spiega? Plz.

[Kharonte85]

Si vedono solo leak (veri o falsi che siano) in cui Cypress è bandwidth limited... sarà molto interessante vedere i test in semplice FullHD...

Come già dicevo da gennaio, si vedranno finalmente le recensioni con AA8x, da tutte quelle redazioni che seguiranno pedissequamente la review guide di nVIDIA.

Non vedo l'ora di leggere la review di Anand :asd:
Figurati che io aspetto di vedere i risultati @1680 :fagiano:

Probabilmente si vedranno anche più recensioni coi FPS minimi dato che quel dato :D sta diventando ricorrente...se anche questo bench fosse vero a quella risoluzione avere una oscillazione di FPS compresa fra 40 e 55 è a dir poco ottimo...e non dimentichiamoci che quel test fino ad ora ha tendenzialmente favorito AMD/ATI

[ghiltanas]

Ecco appunto la news dei 196.78 :

"It was found out that a beta driver by NVIDIA, GeForce 196.78 supports GeForce 400 series accelerators, and was able run a qualification sample of GeForce GTX 470. The card was using A3 revision GF100 silicon. The driver's System Information dialog revealed that the card indeed has 448 CUDA cores (SIMD units). Further, it has 1280 MB of memory, and a 320-bit wide memory interface. NVIDIA also changed the way it represents memory clock speeds. Since it is using GDDR5 memory, while the memory has an actual clock speed of 1000 MHz, the data rate (DDR speed) is represented first, as 2000 MHz, and "effective speed" next, which is 4000 MHz. "

http://www.techpowerup.com/117181/GeForce_196.78_Beta_Driver_Runs_GeForce_GTX_470.html

ricapitolando:
gtx470 -> 448sp 1280MB 320bit gddr5 @1Ghz (4Ghz effettivi) revision A3

le memorie mi sembrano un pò conservative, però il bus è piuttosto ampio. La revision quindi è A3, per i volumi credo bisognerà attendere B1..

[ghiltanas]

Figurati che io aspetto di vedere i risultati @1680 :fagiano:

Probabilmente si vedranno anche più recensioni coi FPS minimi dato che quel dato :D sta diventando ricorrente...se anche questo bench fosse vero a quella risoluzione avere una oscillazione di FPS compresa fra 40 e 55 è a dir poco ottimo...e non dimentichiamoci che quel test fino ad ora ha tendenzialmente favorito AMD/ATI

io ti consiglierei anche un upgrade del monitor se prendi una scheda cosi, dalla 5850 in su imho un bel fullhd ci sta proprio bene, cosi sfrutti la scheda :)

[Kharonte85]

io ti consiglierei anche un upgrade del monitor se prendi una scheda cosi, dalla 5850 in su imho un bel fullhd ci sta proprio bene, cosi sfrutti la scheda :)
Non ci penso neanche lontanamente :D sono ultra soddisfatto del mio Asus pg221 da 22" :)

Non ho capito come mai hanno cambiato il valore base di velocità delle memorie, chi me lo spiega? Plz.
Sostanzialmente significa che prima se nvidia indicava 2000Mhz sulle memorie ddr3 erano 2000Mhz effettivi; mentre adesso con le Gddr5 indica 1000Mhz che significano 4000Mhz effettivi.

[ertruffa]

infatti.. anche a me interessano di + i test @ 1920x1200.

infatti anch'io aspetto bench in fullhd,ovviamente nemesis escluso:D

[Jackaos]

cut


Sostanzialmente significa che prima se nvidia indicava 2000Mhz sulle memorie ddr3 erano 2000Mhz effettivi; mentre adesso con le Gddr5 indica 1000Mhz che significano 4000Mhz effettivi.

Grazie, avevo capito proprio male la frase in inglese, pensavo intendesse che essendo GDDR5 gli effettivi fossero 4000 ma che per qualche ragione la base fosse stata rappresentata con 2000.

[DVD2005]

ricapitolando:
gtx470 -> 448sp 1280MB 320bit gddr5 @1Ghz (4Ghz effettivi) revision A3

le memorie mi sembrano un pò conservative, però il bus è piuttosto ampio. La revision quindi è A3, per i volumi credo bisognerà attendere B1..

ma a parte i volumi, fra A3 e B1 le prestazioni saranno equivalenti ?

[ghiltanas]

ma a parte i volumi, fra A3 e B1 le prestazioni saranno equivalenti ?

le prestazioni nn dovrebbero subire variazioni tra uno step e l'altro...Al + si riduco consumi e calore.
Generalmente si ottengono anche margini di frequenza + ampi, quindi se intendi in questo senso ok

[DVD2005]

le prestazioni nn dovrebbero subire variazioni tra uno step e l'altro...Al + si riduco consumi e calore.
Generalmente si ottengono anche margini di frequenza + ampi, quindi se intendi in questo senso ok

ok, grazie.

[halduemilauno]

ma a parte i volumi, fra A3 e B1 le prestazioni saranno equivalenti ?

a pari condizioni si. ma le condizioni dovrebbero cambiare e quindi con esse anche le prestazioni.

[Pat77]

a pari condizioni si. ma le condizioni dovrebbero cambiare e quindi con esse anche le prestazioni.

Appunto, la ram non doveva essere a 800mhz e ora è a 1Ghz?

[aledemo]

secondo me stanno ritardando e potenziando perche si erano caccati sotto dalle prestazioni della 5870 con i nuovi driver 10.3 :D

[ghiltanas]

Appunto, la ram non doveva essere a 800mhz e ora è a 1Ghz?

magari 800 era per l'a2, mentre con l'a3 si sono potuti permettere il ghz..oppure può essere il valore della 480...di possibilità ce ne sono parecchie, cmq sia sembra definitivo il ghz per la 470

[Kharonte85]

Oh beh, anche io ho un monitor 1680x, ma vista la fascia delle schede direi che l'ambito di utilizzo più adeguato è il fullhd...
Sì sono d'accordo che quella sarebbe la risoluzione più adeguata...ma dico solo che 1680 mi sembra tuttora una risoluzione più che decente accoppiata ad un 22"...al massimo si filtra a paletta e rimanendo legati a quella risoluzione si ha una scheda video più longeva ;)

I minimi che tocca la 5870 a quei settings si spiegano solo con l'esaurimento del framebuffer o con un raggiunto limite di banda. E fin'ora si son visti solo leaks così (ammesso che siano veri), cosa ababstanza sospetta. Attendo recensioni esaustive, in particolare Anandtech, ma anche [H]ard|OCP per il tipo di recensione molto particolare che fanno ogni volta.
Potrebbe essere...ma anche no, del resto non mi pare che stiamo parlando di impostazioni che ti fanno fare 20fps medi, ovviamente aspetterò le recensioni (ma non quelle di Anand e HardOCP che di solito non guardo :fagiano: ) per sapere se effettivamente i valori minimi saranno molto più costanti (magari è un risultato che deriva proprio dal tipo di architettura) e comunque è incoraggiante vedere che la scheda fa quei FPS a quelle risoluzioni...certamente alle risoluzioni più basse la scheda farà più FPS.


Penso si riferisse al fatto che sulla scatola della 470 c'è scritto 800MHz.

L'unica spiegazione che mi viene in mente è che si tratta di un test fatto con memorie overclockate (poco indicativo quindi) o con una 480. L'alternativa è ovviamente che si tratti di un fake :)

No non si riferiva a quello...per quanto riguarda quello bisognerà aspettare le specifiche finali (anche se non credo che possa fare molta differenza dato che comunque avrà una banda passante più che sufficiente)

[halduemilauno]

Appunto, la ram non doveva essere a 800mhz e ora è a 1Ghz?

la ram credo che con lo step B1 centri nulla.

[gianni1879]

secondo me stanno ritardando e potenziando perche si erano caccati sotto dalle prestazioni della 5870 con i nuovi driver 10.3 :D

ma che commento è?....

[zorco]

ma che commento è?....
commento del menga...

[Rsdj]

ma che commento è?....

:asd: :asd:

[Jackaos]

Stavo pensando: se questi leak sono veri, e credo che lo siano a questo punto della vicenda, è plausibile che il framerate minimo alto, o comunque non così distante dal massimo come sulla ATi, possa dipendere da una maggiore flessibilità nei calcoli da parte di Fermi coi suoi generici CUDA cores?

P.S.
Era anche l'ipotesi di skizzo9periodico se non sbaglio.

P.P.S.
Lui aveva incentrato il discorso sulla tesselation, ma appunto io mi chiedevo se valga anche per il resto.

[Andrea deluxe]

Stavo pensando: se questi leak sono veri, e credo che lo siano a questo punto della vicenda, è plausibile che il framerate minimo alto, o comunque non così distante dal massimo come sulla ATi, possa dipendere da una maggiore flessibilità nei calcoli da parte di Fermi coi suoi generici CUDA cores?

P.S.
Era anche l'ipotesi di skizzo9periodico se non sbaglio.

i test che stanno adesso in giro sono tutti "extreme bandwidth" .....

dove si hanno frame minimi e medi alti sulle sk con bus e memoria piu' elevata...


deduci tu le conclusioni....

[halduemilauno]

Stavo pensando: se questi leak sono veri, e credo che lo siano a questo punto della vicenda, è plausibile che il framerate minimo alto, o comunque non così distante dal massimo come sulla ATi, possa dipendere da una maggiore flessibilità nei calcoli da parte di Fermi coi suoi generici CUDA cores?

P.S.
Era anche l'ipotesi di skizzo9periodico se non sbaglio.

P.P.S.
Lui aveva incentrato il discorso sulla teselation, ma aapunto io mi chiedevo se valga anche per il resto.

a quella ris. credo che intervengano maggior ram e in misura minore anche la maggior banda passante rispetto alla controparte.

[yossarian]

Stavo pensando: se questi leak sono veri, e credo che lo siano a questo punto della vicenda, è plausibile che il framerate minimo alto, o comunque non così distante dal massimo come sulla ATi, possa dipendere da una maggiore flessibilità nei calcoli da parte di Fermi coi suoi generici CUDA cores?

P.S.
Era anche l'ipotesi di skizzo9periodico se non sbaglio.

P.P.S.
Lui aveva incentrato il discorso sulla tesselation, ma appunto io mi chiedevo se valga anche per il resto.

a quella ris. credo che intervengano maggior ram e in misura minore anche la maggior banda passante rispetto alla controparte.

esatto

[Jackaos]

OK..:) .