[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[yossarian]

Originariamente inviato da Ren

Yoss, volevo chiederti una cosa slegata dal discorso fermi.

Vedo che le moderne GPU possono indirizzare solo 16 vertici per ciclo di clock.

Quante unità simd possono essere allocate per il calcolo dei vertex ?

Mi verrebbe spontaneo pensare che al massimo un solo stream cluster possa essere allocato, dato che ogni vettore fp32 gestisce un triangolo.

Le animazioni impegnano i geometry o i vertex shader ?
In che misura rispetto alla mera generazione della scena tridimensionale ?

Scusa OT.

in realtà questo limite è già stato superato; dalle dx10.1, infatti, è possibile indirizzare fino a 32 vertici. Solitamente i calcoli geometrici fanno uso di vettori completi (quindi a 4 componenti), per cuiad esempio, un cluster di 16 unità scalari potrà occuparsi, al massimo, di elaborare 4 vertici per ciclo. Per operare su 16 vertici per ciclo avrai bisogno di 64 alu scalari solo per le operazioni di vertex shading

[Kharonte85]

Originariamente inviato da A.L.M.

C'è anche una terza via...
Ci sono già in pipeline diversi giochi che sfrutteranno almeno in parte la tessellation (che ricordo è una feature delle DX11, non certo uno sghiribizzo di ATI)... I first movers comprano Fermi (a marzo), si accorgono che le prestazioni con la tessellation fanno pena, nessuno più compra dette schede e Fermi fa la fine di NV30, EOL dopo pochi mesi.
E non la vedo come un'opzione così remota....
Non è che all'epoca della FX nessuno usò più giochi DX9 o li programmava come voleva JHH solo perchè NV30 faceva pena in quei frangenti. Così come non è che perchè NVidia dice che PhysX è bello diventerà lo standard.
Semplicemente chi comanda in NVidia ha un complesso di inferiorità vs chi davvero comanda nel mercato (leggi MS e Intel) e spera di poter fare lo stesso: basta leggere come JHH parla di Intel nell'articolo sgrammaticato postato prima. Mi pare ovvio che il tizio non abbia capito un razzo di come gira il mercato.

Onestamente mi sembra uno scenario poco credibile...come anche il paragone fatto da JHH con nv30, puramente dettato dal fatto che gli hanno fatto una domanda su quello e lui voleva parlare di fermi.

Nv30 aveva il problema di "essere" dx8 quando i giochi cominciavano a diventare tutti in dx9 (in open GL viaggiavano una meraviglia uguale in dx8.1), in questo momento la situazione è diversa perchè fino a che non ci leviamo di torno le console la maggior parte dei giochi rimarrà in dx9.

Al momento (ma probabilmente anche in futuro) i giochi dx10, dx10.1, dx11 e dx11 con tesselatore rappresenteranno solo una minoranza assoluta. Ecco perchè è impossibile che si ripeta l'ecatombe della serie fx. (a meno che GF100 sia dx8 )

Originariamente inviato da yossarian

e cosa gliene frega ai programmatori; loro devono solo continuare a scrivere il codice come hanno fatto finora dando istruzioni sul tipo di superficie che la gpu deve emulare. Anzi, l'uso del tessellator può semplificare loro la vita. Puoi anche partire da superfici meno complesse delle solite e lasciare al tessellator il compito di creare i vertici mancanti (il che comporta anche un bel risparmio di banda passante)

insomma, a vedere dall'unico benchmark in dx11 prendendo l'esempio delle scale non direi, cioè dubito fortemente che un programmatore possa lasciare le scale lisce in un gioco che dovrebbe girare anche su una GF6600 solo perchè "tanto con il tesselatore poi le vede"...finche' è un benchmark puo' farlo ma quando è un gioco ne dubito

[Ren]

Quindi non più di un cluster di alu Ati,(80alu) può essere indirizzato alla volta per mancanza di dati da processare(causa il setup triangle) per ciclo di clock. Le altre alu rimangono in attesa che il dato venga restituito al rasterizer per poi proseguire con i pixel shader.
In poche parole gli altri 18-19 cluster di cypress rimangono in standby per ogni ciclo di clock dedicato alla geometria...
Stesso discorso, ma con proporzioni diverse per le nvidia.

Sto dicendo una fesseria ?

[Kharonte85]

Originariamente inviato da leoneazzurro

Non so, non c'è nemmeno un accenno a quanti fps "faccia" GF100, le speculazioni sono tutte sul lato delle prestazioni teoriche (quanti FLOPs, quanti texel, il fill rate, ecc.) che come sappiamo spesso non si traducono in prestazioni pure. Per esempio, lo SLI di GTX285 avrà sempre più banda passante e più triangoli/s rispetto a GF100. Se si tende ad essere limitati da questi fattori ci si ritrova esattamente nella situazione della 5870 rispetto alla 4870x2. Per il tessellatore, basta che si rispettino le chiamate dell'API.

Quello è chiaro pero' nell'articolo a differenza di quelli passati (dove si parlava di calcolo) si concentra esplicitamente sulle capacità grafiche (teoriche giustamente ).

Se è come dici allora gf100 potrebbe dichiararsi dx11 senza avere un tesselatore hardware...ma emulare il tesselatore secondo me sarebbe un suicidio (a vedere quanto calano le prestazioni sulle schede HD5xx0), praticamente equivarebbe a non averlo...e sarebbe un peccato perchè a quel punto in pochissimi sarebbero incoraggiati spontaneamente ad utilizzarlo.

[pandyno]

Originariamente inviato da Kharonte85

Se è come dici allora gf100 potrebbe dichiararsi dx11 senza avere un tesselatore hardware...ma emulare il tesselatore secondo me sarebbe un suicidio (a vedere quanto calano le prestazioni sulle schede HD5xx0), praticamente equivarebbe a non averlo...e sarebbe un peccato perchè a quel punto in pochissimi sarebbero incoraggiati spontaneamente ad utilizzarlo.

E questo è allarmante. Spero davvero che tirino fuori qualcosa.

[Andrea deluxe]

Originariamente inviato da Kharonte85

Quello è chiaro pero' nell'articolo a differenza di quelli passati (dove si parlava di calcolo) si concentra esplicitamente sulle capacità grafiche (teoriche giustamente ).

Se è come dici allora gf100 potrebbe dichiararsi dx11 senza avere un tesselatore hardware...ma emulare il tesselatore secondo me sarebbe un suicidio (a vedere quanto calano le prestazioni sulle schede HD5xx0), praticamente equivarebbe a non averlo...e sarebbe un peccato perchè a quel punto in pochissimi sarebbero incoraggiati spontaneamente ad utilizzarlo.

ho visto un video di dirt2 dove venivano comparate de diff con tassellatore e non, ma ho notato che viene usato come lo zafferano nel risotto.....(poco)

se si eccede con il tassellatore, si perde troppo con ati e penso pure con nvidia....

[A.L.M.]

Originariamente inviato da Kharonte85

Quello è chiaro pero' nell'articolo a differenza di quelli passati (dove si parlava di calcolo) si concentra esplicitamente sulle capacità grafiche (teoriche giustamente ).

Sinceramente mi sfugge di che tipo di capacità grafiche puoi parlare se le uniche cose che si sanno sono di carattere computazionale. Sappiamo molto sugli shaders e sulle caratteristiche generali del chip, ma poco sul resto...

[yossarian]

Originariamente inviato da Ren

Quindi non più di un cluster di alu Ati,(80alu) può essere indirizzato alla volta per mancanza di dati da processare(causa il setup triangle) per ciclo di clock. Le altre alu rimangono in attesa che il dato venga restituito al rasterizer per poi proseguire con i pixel shader.
In poche parole gli altri 18-19 cluster di cypress rimangono in standby per ogni ciclo di clock dedicato alla geometria...
Stesso discorso, ma con proporzioni diverse per le nvidia.

Sto dicendo una fesseria ?

stai ragionando come si faceva per i chip a shader dedicati
Con gli shader unificati tutti i cluster caricano istruzioni relative sia alle geometrie che al rendering e le eseguono in contemporanea solo dopo che sono stati riempiti tutti i registri costanti (diverse migliaiaa9 e gli instruction buffer. Ogni thread di tipo geometrico ne genera n per i pixel shader che vengono eseguiti mentre si continua a lavorare su altri thread geometrici.
Insomma, quello dei 16 vertici (o 32) caricati per ciclo non costituisce un limite.

[Kharonte85]

Originariamente inviato da A.L.M.

Sinceramente mi sfugge di che tipo di capacità grafiche puoi parlare se le uniche cose che si sanno sono di carattere computazionale. Sappiamo molto sugli shaders e sulle caratteristiche generali del chip, ma poco sul resto...

Non sono io che ho scritto l'articolo:

Rough performance estimates

Given everything we talked about above, we can start to draw some rough comparisons from GF100 to GT200 and RV870—and maybe estimate performance. We've got a clock estimate we're pretty confident in, and we've puts flags in the ground for the graphics-specific units, in terms of counts, so here goes nothing.

We'll consider Radeon HD 5870 for the RV870 implementation and the GeForce GTX 285 for the GT200 product. Obviously, GT200's SP rate is for MADD, since it doesn't have support for SP FMA.



The GF100's architecture means the SKU we've described (the GeForce GTX 380, possibly) comfortably outruns the GeForce GTX 285 in every way, to the point that (and we really generalize here, sorry) it should usually be at least twice as fast. Of course, you can engineer situations, usually in the middle of a frame, where the GF100 won't outpace the GT200 all that much, but in the main, it should be a solid improvement. The GF100 will outpace the Radeon HD 5870 as the top single-chip graphics product of all time, assuming AMD doesn't release anything else in the interim, between now and January. Look for the margins there to be a bit more slender, and we refer you to our Radeon HD 5870 review for the figures that'll let you imagine performance versus AMD's product.

http://techreport.com/articles.x/17815/4

[DukeIT]

Originariamente inviato da Kharonte85

emulare il tesselatore secondo me sarebbe un suicidio (a vedere quanto calano le prestazioni sulle schede HD5xx0)

Probabilmente non ho capito bene io, ma il tessellatore non dovrebbe far migliorare le prestazioni a parità di rappresentazione grafica?

[Ren]

tai ragionando come si faceva per i chip a shader dedicati
Con gli shader unificati tutti i cluster caricano istruzioni relative sia alle geometrie che al rendering e le eseguono in contemporanea solo dopo che sono stati riempiti tutti i registri costanti (diverse migliaiaa9 e gli instruction buffer. Ogni thread di tipo geometrico ne genera n per i pixel shader che vengono eseguiti mentre si continua a lavorare su altri thread geometrici.
Insomma, quello dei 16 vertici (o 32) caricati per ciclo non costituisce un limite.

Pensavo si dovesse generare l'intera geometria del frame, non solo alcuni elementi per poi rasterizzare/renderizzare...

[kiriranshelo]

Originariamente inviato da DukeIT

Probabilmente non ho capito bene io, ma il tessellatore non dovrebbe far migliorare le prestazioni a parità di rappresentazione grafica?

no. serve per migliorare la qualità grafica, a discapito delle prestazioni talvolta, se non sbaglio

[DukeIT]

Originariamente inviato da kiriranshelo

no. serve per migliorare la qualità grafica, a discapito delle prestazioni talvolta.

Eppure pensavo che fosse l'esatto contrario

[The_SaN]

Originariamente inviato da kiriranshelo

no. serve per migliorare la qualità grafica, a discapito delle prestazioni talvolta, se non sbaglio

Puoi fare tutte e 2.
O migliori la qualitá (con un impatto prestazionale ridotto rispetto ai metodi tradizionali), o mantieni lo stesso dettaglio migliorando le prestazioni.

(che poi diciamocelo, é la stessa cosa, da 2 punti di vista diversi)

[Judicator]

Originariamente inviato da DukeIT

Probabilmente non ho capito bene io, ma il tessellatore non dovrebbe far migliorare le prestazioni a parità di rappresentazione grafica?

A parità di numero di triangoli, si, c'è una lieve differenza.
Ma bisogna pensare che al crescere del numero delle facce aumentano il numero dei triangoli che compongono gli oggetti. Quindi illuminazione ed ombreggiatura devono essere calcolati sulla base di un dettagliio geometrico maggiore.

[Ren]

Eppure pensavo che fosse l'esatto contrario

Rimane sempre un algoritmo di generazione dei poligoni. Un tuning a mano dei modelli poligonali è sicuramente di maggior qualità rispetto ad una serie di formule matematiche, anche se si scontra con i limiti di banda passante.

Quindi i modelli poligonali rimangono gli stessi, ma si applica un effetto che aumenti i poligoni matematicamente e non secondo l'idea del modellatore.

Diciamo che è un effetto che aumenta la qualità generale dei modelli come può essere un parallax mapping, ma con reale generazione dei poligoni ed il vantaggio della scalabilità del motore 3D.

Se guardi il drago postato precedentemente, l'aumento di poligoni è mostruoso, ma la qualità del prodotto finito non è poi così eclatante. (guarda i video)
Alcune superfici più semplici come i mattoni o le corde, mostrano invece uno stacco maggiore dal punto di vista qualitativo.

[yossarian]

Originariamente inviato da Ren

Pensavo si dovesse generare l'intera geometria del frame, non solo alcuni elementi per poi rasterizzare/renderizzare...

si può procedere anche in contemporanea a condizione che non ci siano istruzioni tra loro dipendenti. Ad esempio, ovviamente, non si può renderizzare una superficie i cui dati geometrici non siano ancora stati processati ma si può renderizzare una superficie già calcoltata mentre in contemporanea si sta lavorando sul calcolo di altre superfici.
Considera che dopo l'avvio dell'elaborazione, man mano che si rpocede, i buffer e i registri contenenti istruzioni e dati si vanno svuotando e devono essere di nuovo riempiti. Per questo, l'unità centrale (il thread processor) riceve dei feedback da tutti i processi completati e decide, di conseguenza, cosa andare a caricare.
Anche nell'ipotesi di dover completare prima un intero frame, il limite dei 16 vertici per ciclo non rappresenterebbe un collo di bottiglia, perchè questo avverrebbe solo all'inizio dell'elaborazione del primo frame; in seguito, possono essere caricate anche istruzioni relative alle geometrie dei frame successivi mentre si sta ancora renderizzando il frame precedente.

[yossarian]

Originariamente inviato da Ren

Rimane sempre un algoritmo di generazione dei poligoni. Un tuning a mano dei modelli poligonali è sicuramente di maggior qualità rispetto ad una serie di formule matematiche, anche se si scontra con i limiti di banda passante.

Quindi i modelli poligonali rimangono gli stessi, ma si applica un effetto che aumenti i poligoni matematicamente e non secondo l'idea del modellatore.

Diciamo che è un effetto che aumenta la qualità generale dei modelli come può essere un parallax mapping, ma con reale generazione dei poligoni ed il vantaggio della scalabilità del motore 3D.

Se guardi il drago postato precedentemente, l'aumento di poligoni è mostruoso, ma la qualità del prodotto finito non è poi così eclatante. (guarda i video)
Alcune superfici più semplici come i mattoni o le corde, mostrano invece uno stacco maggiore dal punto di vista qualitativo.

in realtà è il modellatore che decide secondo quale algoritmo devono essere "inseriti" i nuovi vertici. In pratica, si danno nistruzioni sul tipo di superficie da generare, fornendone i parametri.

[Ren]

Finalmente ho capito!

Grazie.

[Ren]

in realtà è il modellatore che decide secondo quale algoritmo devono essere "inseriti" i nuovi vertici. In pratica, si danno nistruzioni sul tipo di superficie da generare, fornendone i parametri.

Si, lo avevo capito, ma non sempre i risultati mi sembrano eccellenti su tutti i modelli... (ovviamene mi riferisco al benchmark che circola)