[THREAD UFFICIALE] Aspettando Nvidia GTX 480 e GTX 470

[DVD2005]

Originariamente inviato da supersalam

Scusate ma "tesselatore" non si può sentire proprio

sei più per la versione anglosassone ?

[devAngnew]

Originariamente inviato da supersalam

Scusate ma "tesselatore" non si può sentire proprio

Allora tappati le orecchie.........

[gervi]

Originariamente inviato da devAngnew

Ma l'hai letto da qualche parte (link ).
Perchè se non hai fonti anche l'ipotesi di mancanza hardware di un tesselatore ci può stare basti che usi hull shader e domain shader e il tessellatore è servito e se sarà fatto tutto da eventuali shader unificati avremo una tesselation unit molto flessibile come lo sono ora le unità di shader per operazioni di pixel e vertex shader ecc.

non ne ho la certezza , mi sembrava che qualcuno lo abbia detto nel topic della 5870.

Ma potrei sbagliarmi.

[michelgaetano]

Originariamente inviato da Ywes

Guarda qua il massimo raggiunto con 925Mhz Gpu + 5400Mhz Ram, Crysis WarHEAD passa da 45 a 48 Fps vale a dire 6,6% periodico... certo più del 5% ma non abbastanza da avvicinare le performance della gtx 295 in oc che arriva anche a più del 14% (da 49 a 56):

Link HD 5870 OC:
http://www.guru3d.com/article/radeon...review-test/26

Link Gtx 295 OC:
http://www.guru3d.com/article/geforc...-review-bfg/21
http://www.guru3d.com/article/asus-g...ew-engtx295/21

Stando sulla carta la G300 a default dovrebbe essere superiore alla GTX 295 quindi il divario in OC sarebbe ben superiore...

Non è questo il posto adatto e sarà meglio continuare nel thread sulla 5870, ma credo di aspettare veri riscontri (utenti) per l'OC.

Cioè se prendo TechPowerUp, il loro sample sale poco, 5 % su core e 6 % su memorie (mentre altri hanno fatto oltre il doppio). Con questi aumenti, hanno avuto un +5 % (4.9 % per l'esattezza) di prestazioni, cioè allineato.

Insomma, prima di asserire con certezza a riguardo preferisco aspettare, perchè si rischia solo di dare giudizia sbagliati al momento.

[devAngnew]

Originariamente inviato da gervi

non ne ho la certezza , mi sembrava che qualcuno lo abbia detto nel topic della 5870.

Ma potrei sbagliarmi.

Bha ho provato a fare una ricerca sul thread della 5870 ma niente..

[yossarian]

Originariamente inviato da devAngnew

Ma l'hai letto da qualche parte (link ).
Perchè se non hai fonti anche l'ipotesi di mancanza hardware di un tesselatore ci può stare basti che usi hull shader e domain shader e il tessellatore è servito e se sarà fatto tutto da eventuali shader unificati avremo una tesselation unit molto flessibile come lo sono ora le unità di shader per operazioni di pixel e vertex shader ecc.

a cosa ti servono hull shader e domain shader se non hai un'unità di tessellation fisica?

[devAngnew]

Originariamente inviato da yossarian

a cosa ti servono hull shader e domain shader se non hai un'unità di tessellation fisica?

Io ho ipotizzato che anzichè avere un unità tesselation fissa quindi un pezzo di silicio che effettui hull e domain shader c'è ne possano essere 480/512 shader capaci dinamicamente di eseguire pixel, vertex , hull , geometry e domain shader spero di essere stato chiaro.

del resto le prime architetture sia Ati che nvidia usavano archietture a shader separati e poi si è visto dove siamo arrivati ........

[yossarian]

Originariamente inviato da devAngnew

Io ipotizzato che anzichè avere un unità tesselation fissa quindi un pezzo di silicio che effettui hull e domain shader c'è ne possano essere 480/512 shader capaci dinamicamente di eseguire pixel, vertex , hull , geometry e domain shader spero di essere stato chiaro.

del resto le prime architetture sia Ati che nvidia usavano archietture a shader separati e poi si è visto dove siamo arrivati ........

su RV770 non ci sono hull e domin shader e sono sostituiti da vertex e geometry shader. C'è, però, l'unità di tessellation fixed function.
La pipeline dx11 prevede l'utilizzo di hull shader e domain shader; questo è l'unico motivo per cui il tessellator di RV770 non è dx11 fully compliant, pur essendo ugualmente programmabile.

Le ROP's e le TMU fanno ancora uso di fixed function e unità dedicate.

Una unità dedicata è più veloce nell'eseguire un determinato task rispetto ad una generica: quindi un'unità di tessellation dedicata è sicuramente più veloce di un gruppo di unità di shading che eseguano lo stesso compito.
Il vantaggio delle architetture a shader unificati sta nella maggior efficienza dell'intera architettura non in quella della singola unità o del singolo blocco funzionale.

[devAngnew]

Originariamente inviato da yossarian

su RV770 non ci sono hull e domin shader e sono sostituiti da vertex e geometry shader. C'è, però, l'unità di tessellation fixed function.
La pipeline dx11 prevede l'utilizzo di hull shader e domain shader; questo è l'unico motivo per cui il tessellator di RV770 non è dx11 fully compliant, pur essendo ugualmente programmabile.

Le ROP's e le TMU fanno ancora uso di fixed function e unità dedicate.

Una unità dedicata è più veloce nell'eseguire un determinato task rispetto ad una generica:

quindi un'unità di tessellation dedicata è sicuramente più veloce di un gruppo di unità di shading che eseguano lo stesso compito.

Certamente hai ragione. Io non ho parlato di efficienza ma di flessibilità.

Il vantaggio delle architetture a shader unificati sta nella maggior efficienza dell'intera architettura non in quella della singola unità o del singolo blocco funzionale.

Penso che ti stai sbagliando infatti il vantaggio delle architetture a shader unificati è la flessibilità infatti inizialmente la gpu deve scegliere quante unità destinare ai vertex sharer e quanti ai pixel shader ecc. e questo è un overhead di cui tener conto quando si progetta una gpu con tali capacità rispetto ad un'architettura a shader fissi come erano le vecchie generazioni
pre 8800 per capirci.(ergo le unità fisse sono più efficienti di quelle programmabili e lo hai detto tu stesso).
Tornado al ragionamento Il vantaggio si ha dopo la scelta del bilanciamento delle unità di shader ; infatti se ho bisogno di molti calcoli vertex rispetto che di pixel allora le unità saranno programmate per realizzare più calcoli di vertex shader pittosto che pixel e cosi via......

[Pihippo]

Originariamente inviato da Ywes

Voglio farti presente due cose mettendo in contro che parliamo solo di aria fritta (in quanto di cose certe ancora non si sa nulla e si parla solo di rumors) pero analizzando le specifiche venute fuori da rumors avrei due cose da dire.

Primo, la 5870 non supera mai il 7% anche se overclockata a 950Mhz GPU e 5400Mhz Ram (e questa è una costa certa non un rumor basta che fai una ricerca in rete e vedrai tu stesso).

Secondo, non metto in dubbio che la 5870 sia ben proporzionata ma che la G300 sia superiore sempre stando alle voci dei rumors:

HD 5870
GPU 850Mhz
1600 Shader(simil shader)
Ram 4800Mhz 256bit

G300
GPU 700-750Mhz
480 o 512 Shader
Ram 4000Mhz 512Bit o Ram 4400Mhz 384bit

Sappiamo bene che 240 shader nVidia siano superiori a 800 shader Ati, quindi possiamo dedurre che 480 shader saranno superiori ai 1600 di ati se poi pensi al fatto che forse saranno più di 480 questo non fa che aumentare il vantaggio di g300. Stessa cosa sulle ram sia la versione da 4000Mhz 512Bit sia la versione da 4400Mhz 384bit sono superiori ai 4800Mhz 256bit di Ati.

Ciao.
Mettiamola cosi Hd5870 320 shader, ovvero alu a 5 lane, spero di non dire cacchiate, contro gli ipotetici 512 di g300. Il 1600 è un numero di marketing, dovuto dal fatto che su lo stesso pezzo di dato il singolo sp da r600 in poi puo eseguirci 5 operazioni, quindi 320x5= 1600.
Edit:
Chiedo anche qui, qualcuno sa se nelle gpu c'è una unità specifica che calcola gli indirizzi di memoria come nelle cpu(una agu)?
Inoltre come li trovano gli operandi? Scusatemi ma sono molto curioso

[yossarian]

Originariamente inviato da devAngnew

Certamente hai ragione. Io non ho parlato di efficienza ma di flessibilità.

la flessibilità si traduce in efficienza architetturale, altrimenti resta un parametro fine a sé stesso e, pertanto, inutile. Non mi interessa avere un'architettura flessibile se è più lenta di una meno flessibile. Ad esempio, i chip ATi sono più flessibili di quelli nVidia perchè l'ILP è gestito dal compilatore e non in run time, ma questa maggior flessibilità si traduce in una minor efficienza architetturale. Il vantaggio è stato quello di aver potuto mettere tanti transistor in poco spazio e di aver potuto adottare versioni diverse di API (DX10, 10.1 e 11) senza grandi stravolgimenti architetturali.

Originariamente inviato da devAngnew

Penso che ti stai sbagliando infatti il vantaggio delle architetture a shader unificati è la flessibilità infatti inizialmente la gpu deve scegliere quante unità destinare ai vertex sharer e quanti ai pixel shader ecc. e questo è un overhead di cui tener conto quando si progetta una gpu con tali capacità rispetto ad un'architettura a shader fissi come erano le vecchie generazioni
pre 8800 per capirci.(ergo le unità fisse sono più efficienti di quelle programmabili e lo hai detto tu stesso).
Tornado al ragionamento Il vantaggio si ha dopo la scelta del bilanciamento delle unità di shader ; infatti se ho bisogno di molti calcoli vertex rispetto che di pixel allora le unità saranno programmate per realizzare più calcoli di vertex shader pittosto che pixel e cosi via......

vedi sopra; in un'architettura a shader dedicati ogni unità sa ciò che deve fare e lo fa molto più velocemente; in una a shader unificati ogni unità deve "pensare" a ciò che deve fare o meglio (le cose sono piuttosto complesse e ogni unità ha migliaia di registri su cui carica dati sia di tipo geometrico che non e di volta in volta deve "scegliere" su quali moperare), c'è un thread processor (arbiter + sequencer) che lo fa per lei e spreca cicli per fare questa operazione. Cicli che l'altra impiega per fare calcoli, invece.
Lo svantaggio degli shader dedicati è che è praticamente impossibile avere tutte le unità a pieno regime anzi, spesso, quando un blocco è in full l'altro è in idle. Oltre a ciò c'è la possibilità, di cui hai parlato, di poter effettuare ottimizzazioni sui carichi di lavoro a seconda di ciò che serve; entro certi limiti, però: le DX10, ad esempio, prevedono che non sia possibile fare più di 16 vertex fetch contemporanei, quindi le unità che fanno vertex shading potranno caricare solo 16 vertici per volta (come con le dx9); con le dx10.1 e le 11 si è passati a 32. Questo si traduce in efficienza architetturale globale (e non della singola unità)
Resta comunque il fatto che un'unità dedicata, di tipo fixed function, è più veloce di una generica e, quindi, un tessellator di tipo hardware è preferibile che sia implementato tramite fixed function, in quanto deve fare sempre e solo la stessa cosa (aggiungere vertici) mentre è l'hull shader (o i vertex shader, a seconda dell'implementazione scelta) a dirgli dove deve aggiungerli, a seconda del tipo di funzione scelta.

[appleroof]

Originariamente inviato da yossarian

su RV770 non ci sono hull e domin shader e sono sostituiti da vertex e geometry shader. C'è, però, l'unità di tessellation fixed function.
La pipeline dx11 prevede l'utilizzo di hull shader e domain shader; questo è l'unico motivo per cui il tessellator di RV770 non è dx11 fully compliant, pur essendo ugualmente programmabile.

cut

domanda interessata : insomma, un gioco che preveda l'utilizzo della tecnica della tasselazione, "gira" su rv770 come girerebbe su rv870, sia pure ovvio con minori prestazioni a parità di impostazioni?

[ippo.g]

Originariamente inviato da appleroof

domanda interessata : insomma, un gioco che preveda l'utilizzo della tecnica della tasselazione, "gira" su rv770 come girerebbe su rv870, sia pure ovvio con minori prestazioni a parità di impostazioni?

se ho capito qualcosa, in DX11 non dovrebbe funzionare

[Pihippo]

Originariamente inviato da yossarian

la flessibilità si traduce in efficienza architetturale, altrimenti resta un parametro fine a sé stesso e, pertanto, inutile. Non mi interessa avere un'architettura flessibile se è più lenta di una meno flessibile. Ad esempio, i chip ATi sono più flessibili di quelli nVidia perchè l'ILP è gestito dal compilatore e non in run time, ma questa maggior flessibilità si traduce in una minor efficienza architetturale. Il vantaggio è stato quello di aver potuto mettere tanti transistor in poco spazio e di aver potuto adottare versioni diverse di API (DX10, 10.1 e 11) senza grandi stravolgimenti architetturali.



vedi sopra; in un'architettura a shader dedicati ogni unità sa ciò che deve fare e lo fa molto più velocemente; in una a shader unificati ogni unità deve "pensare" a ciò che deve fare o meglio (le cose sono piuttosto complesse e ogni unità ha migliaia di registri su cui carica dati sia di tipo geometrico che non e di volta in volta deve "scegliere" su quali moperare), c'è un thread processor (arbiter + sequencer) che lo fa per lei e spreca cicli per fare questa operazione. Cicli che l'altra impiega per fare calcoli, invece.
Lo svantaggio degli shader dedicati è che è praticamente impossibile avere tutte le unità a pieno regime anzi, spesso, quando un blocco è in full l'altro è in idle. Oltre a ciò c'è la possibilità, di cui hai parlato, di poter effettuare ottimizzazioni sui carichi di lavoro a seconda di ciò che serve; entro certi limiti, però: le DX10, ad esempio, prevedono che non sia possibile fare più di 16 vertex fetch contemporanei, quindi le unità che fanno vertex shading potranno caricare solo 16 vertici per volta (come con le dx9); con le dx10.1 e le 11 si è passati a 32. Questo si traduce in efficienza architetturale globale (e non della singola unità)
Resta comunque il fatto che un'unità dedicata, di tipo fixed function, è più veloce di una generica e, quindi, un tessellator di tipo hardware è preferibile che sia implementato tramite fixed function, in quanto deve fare sempre e solo la stessa cosa (aggiungere vertici) mentre è l'hull shader (o i vertex shader, a seconda dell'implementazione scelta) a dirgli dove deve aggiungerli, a seconda del tipo di funzione scelta.

Ciao.
Complimenti per la preparazione tecnica, leggendo i tuoi articoli su appuntidigitali ho capito perfino io come funziona beno o male una gpu. Se non ti rompo vorrei porti una domanda. Le gpu possiedono unità atte a calcolare gli indirizzi di memoria come le agu sulle cpu? Inoltre possiedono unità di load e store? In tutto lo spulciare sulla rete ancora non ho capito come una gpu riesce a gestire queste cose per non parlare di come trova gli operandi.

[yossarian]

Originariamente inviato da Pihippo

Ciao.
Mettiamola cosi Hd5870 320 shader, ovvero alu a 5 lane, spero di non dire cacchiate, contro gli ipotetici 512 di g300. Il 1600 è un numero di marketing, dovuto dal fatto che su lo stesso pezzo di dato il singolo sp da r600 in poi puo eseguirci 5 operazioni, quindi 320x5= 1600.
Edit:
Chiedo anche qui, qualcuno sa se nelle gpu c'è una unità specifica che calcola gli indirizzi di memoria come nelle cpu(una agu)?
Inoltre come li trovano gli operandi? Scusatemi ma sono molto curioso

le gpu lavorano tramite registri (non sempre a dir la verità, eprchè le funzioni memexport e memimport introdotte da ATi con R5x0 permettono l'accesso diretto alla ram da parte delle unità di calcolo). Comunque, gli indirizzi di memoria sono gestiti dall'arbiter del memory controller interno alla gpu; quando un'unità deve accedere a dati contenuti nella vram, inizializza un DMA; la richiesta di acceso è messa in coda all'interno di un buffer gestito dal MC che decide quali richieste evadere prima (funziona in modalità rigorosamente out of order). Invia la richiesta all'indirizzo di ram a cui è destinata e si occupa di indirizzare, successivamente, i dati verso i registri della alu che ha fatto richiesta. Gli indirizzi sono inviati, insieme alle istruzioni, dal thread processor e immagazzinati in speciali registri oppure in cache di tipo n-way set associative o fully associative. Quindi, sia gli operandi che le istruzioni che gli indirizzi sono forniti alle alu tramite set di registri appositi

[Pihippo]

Originariamente inviato da yossarian

le gpu lavorano tramite registri (non sempre a dir la verità, eprchè le funzioni memexport e memimport introdotte da ATi con R5x0 permettono l'accesso diretto alla ram da parte delle unità di calcolo). Comunque, gli indirizzi di memoria sono gestiti dall'arbiter del memory controller interno alla gpu; quando un'unità deve accedere a dati contenuti nella vram, inizializza un DMA; la richiesta di acceso è messa in coda all'interno di un buffer gestito dal MC che decide quali richieste evadere prima (funziona in modalità rigorosamente out of order). Invia la richiesta all'indirizzo di ram a cui è destinata e si occupa di indirizzare, successivamente, i dati verso i registri della alu che ha fatto richiesta. Gli indirizzi sono inviati, insieme alle istruzioni, dal thread processor e immagazzinati in speciali registri oppure in cache di tipo n-way set associative o fully associative. Quindi, sia gli operandi che le istruzioni che gli indirizzi sono forniti alle alu tramite set di registri appositi

Ti ringrazio della risposta molto esauriente.
Da quello che mi pare di capire, per carità non sono un esperto, tutta sta trafila divora bandwidth, dunque niente Load store unit, come cavolo fanno gli shader a non scannarsi per un pezzo di di bandwidth?

[yossarian]

Originariamente inviato da Pihippo

Ciao.
Complimenti per la preparazione tecnica, leggendo i tuoi articoli su appuntidigitali ho capito perfino io come funziona beno o male una gpu. Se non ti rompo vorrei porti una domanda. Le gpu possiedono unità atte a calcolare gli indirizzi di memoria come le agu sulle cpu? Inoltre possiedono unità di load e store? In tutto lo spulciare sulla rete ancora non ho capito come una gpu riesce a gestire queste cose per non parlare di come trova gli operandi.

ho risposto sopra; le gpu lavorano prevalentemente tramite registri di vario tipo; ad esempio, i dati sono caricati su registri costanti che la alu può usare solo in lettura; quando esegue una operazione, ad esempio un'addizione, preleva i due operandi da 2 registri e li somma, mettendo il risultato in un registro temporaneo se deve essere disponibile per una nuova operazione o in un registro di output qualora il risultato sia definitivo e debba essere immagazzinato nel frame buffer. Quindi le operazioni di load e store avvengono dalla vram verso i registri delle alu ed è l'erbiter del memory controller che si occupa dell'operazione di instradamento. Invece è il thread processor a fornire istruzioni e indirizzi di memoria. Ogni cluster di alu ha una instruction cache e un instruction buffer che servono a gestire la coda delle istruzioni. Il thread processo è out of order mentre, una volta arrivate all'instruction buffer, le istruzioni sono eseguite in modalità in order (e si sfrutta il multithreading per mascherare le latenze).

[Pihippo]

Originariamente inviato da yossarian

ho risposto sopra; le gpu lavorano prevalentemente tramite registri vario tipo; ad esempio, i dati sono caricati su registri costanti che la alu può usare solo in lettura; quando esegue una operazione, ad esempio un'addizione, preleva i due operandi da 2 registri e li somma, mettendo il risultato in un registro temporaneo se deve essere disponibile per una nuova operazione o in un registro di output qualora il risultato sia definitivo e debba essere immagazzinato nel frame buffer. Quindi le operazioni di load e store avvengono dalla vram verso i registri delle alu ed è l'erbiter del memory controller che si occupa dell'operazione di instradamento. Invece è il thread processor a fornire istruzioni e indirizzi di memoria. Ogni cluster di alu ha una instruction cache e un instruction buffer che servono a gestire la coda delle istruzioni. Il thread processo è out of order mentre, una volta arrivate all'instruction buffer, le istruzioni sono eseguite in modalità in order (e si sfrutta il multithreading per mascherare le latenze).

Grazie. Scusami, non avevo visto che avevi gia risposto. Grazie ancora.

[yossarian]

Originariamente inviato da appleroof

domanda interessata : insomma, un gioco che preveda l'utilizzo della tecnica della tasselazione, "gira" su rv770 come girerebbe su rv870, sia pure ovvio con minori prestazioni a parità di impostazioni?

cambia solo il tipo di "chiamata"; in dx11 si fa riferimento agli hull shader e ai domain shader, con RV770 si fa riferimento ai vertex e ai geometry shader. Basta implementare due differenti path dello stesso shader. Ovviamente, l'utilizzo delle unità generiche su RV770 provoca un decadimento delle prestazini (anche perchè si tratta di risorse sottartte ad altre elaborazioni) ma, in linea di principio, può funzionare regolarmente. Insomma, se il programmatore, mi si passi il termine, stronzeggia, fa in modo che su RV770 non giri. Se si prende la briga di implementare una differente path (niente di eccessivamente complesso, si tratta solo di scegliere quali unità programmabili scegliere per "spiegare" al tessellator dove deve mettere i vertici in più ) allora gira tranquillamente anche su RV770.

Originariamente inviato da Pihippo

Ti ringrazio della risposta molto esauriente.
Da quello che mi pare di capire, per carità non sono un esperto, tutta sta trafila divora bandwidth, dunque niente Load store unit, come cavolo fanno gli shader a non scannarsi per un pezzo di di bandwidth?

è compito dei memory controller stabilire a chi assegnare la priorità e come gestire la bandwidth. Ci osno alcuni trucchi per ottimizzare l'utilizzo della bandwidth: ad esmepio, ATi, da RV770 in poi, ha iniziato a far uso di cache L2 messa a disposizione dei MC per immagazzinare i dati di più frequente utilizzo. Comunque, la cosa più importante è programmare bene il MC

[appleroof]

Originariamente inviato da ippo.g

se ho capito qualcosa, in DX11 non dovrebbe funzionare

ma infatti rimane un mistero come, a parità di condizioni, rv770 sia dx10.1 e rv870 dx11: "basta" (in estrema ipotesi) che i programmatori scelgano, in ipotesi di programmare in vertex e geometry piuttosto che in hull e domain shaders, e, avendo entrambe le gpu il tasselletor, il gioco è fatto (è proprio il caso di dirlo)

questo spiega anche come siamo polli a rincorrere sempre il software che non cìè con l'hardware che c'è

Originariamente inviato da yossarian

cambia solo il tipo di "chiamata"; in dx11 si fa riferimento agli hull shader e ai domain shader, con RV770 si fa riferimento ai vertex e ai geometry shader. Basta implementare due differenti path dello stesso shader. Ovviamente, l'utilizzo delle unità generiche su RV770 provoca un decadimento delle prestazini (anche perchè si tratta di risorse sottartte ad altre elaborazioni) ma, in linea di principio, può funzionare regolarmente.



cut

ok, rispondo adesso perchè letto dopo: ma quindi, nell'economia del discrso che faccio in questo post, il tasselletor di rv770 potrebbe funzionare, una volta che siano implementati entrambi i path (sò che è un'ipotesi di scuola, dato che mai gli svuluppatori si sbatteranno tanto non avendo tempo e soldi a disposizione, e anche perchè le aziende produttrici di hw, nello specifico Ati, si incacchierebbero non poco )? Anche perchè credo che la potenza di rv770 sia ancora sufficiente a ciò...(intendo far girare un gioco programmato in quel modo in fullhd, magari senza aa)

riedit: mi hai risposto nella parte di post che hai aggiunto...insomma sono convinto: siamo preda del marketing e di sti cacchio di programmatori che a loro volta rispondono ai loro capi...mi si passi la filosofia, ma è veramente uno schifo, d'altra parte da quando "frequento" questo mondo ricordo che è così: in 2 parole, se le vga fossero "sfruttate" come si deve, potrebbero durare tipo 5 anni dando costantemente risultati grafici strabilianti invece il marketing ecc (diciamo il "sistema" per brevità) ci obbliga all'upgrade ogni 2 anni se và bene, facendo girare codice "vecchio" ma in maniera più veloce, o cmq scritto in maniera da "escludere" l'hw "vecchio" su hw che avrebbe ancora tantissimo da dire...

scusate lo sfogo