di  -  mercoledì 31 marzo 2010

Con questa settimana, chiudiamo il discorso sulla tessellation facendo qualche breve considerazione di carattere prestazionale.

Partendo dalla breve disamina sulle architettura proposte da ATi e nVIDIA la volta scorsa, cerchiamo di capire quali siano i vantaggi e gli svantaggi di questo tipo di architettura, partendo dal flusso di dati.

Se pensiamo allo schema: VS->HS->tessellator->DS->GS notiamo che in una pipeline classica, come quella di RV870, dove c’è un’unità dedicata che contiene i tre stadi dedicati alla tesellation, i dati in ingresso debbano, inizialmente, essere trasferiti dai VS agli HS mentre in GF100 questo non avviene perchè le stesse unità si occupano di eseguire le istruzioni relative ad entrambi i tipi di shader; però abbiamo l’input assembler contenuto nel polymorph engine, ossia nello stadio di tipo fixed function della pipeline geometrica di Fermi.

Un trasferimento di dati comporta sempre un aumento di latenze e sarà necessario valutare l’impatto di questi due tipi di trasferimento e il modo in cui AMD e nVIDIA hanno provveduto a mascherare le latenze. Nel prosiequo dell’elaborazione, in RV870 i dati seguono un percorso interno all’unità di tessellation ed escono quando sono pronti per essere inviati ai GS.

In Fermi, al contrario, dai VS vengono inviati al polymorph engine dove sono sottoposti a tessellation e, di li, di nuovo allo shader core per le operazioni di DS e GS. Anche in questa fase avviene un trasferimento per parte ma a livelli differenti e valgono le considerazioni fatte in precedenza.

Con i chip DX11, allo shader core è affidato anche il compito di effettuare le operazioni di texture blending, ossia quelle operazioni necessarie ad applicare filtri come l’AF. Lo scopo di questa digressione è di puntualizzare un altro elemento che può costituire un punto di forza ma anche un punto debole della scelta di nVIDIA.

Lo shader core è chiamato a svolgere le operazioni di VS, PS, GS e quelle di texture filtering; in GF100 devono anche occuparsi di sosittuire HS e DS. Se da un lato questa scelta permette di avere una miglior granularità, ossia di avere più potenza quando serve, riducendo al minimo l’hardware dedicato alla tessellation, dall’altro ripropone il solito dilemma: meglio unità dedicate, specializzate e, quindi, più veloci nell’eseguire un particolare compito, oppure meglio unità generiche che possano essere riutilizzate anche per fare altro?

Da un lato, l’unità dedicata di ATi, qualora non si ricorra all’uso di Higher Order Surface, resta del tutto inattiva; dall’altro le unità di shading di nVIDIA, nel momento in cui parte un’operazione di tessellation, si trivano, per forza di cose, a rallentare le altre elaborazioni dovendosi dedicare, almeno in parte, alle operazioni di hull e domain shading.

E a quelli che pensano che il maggior peso dell’operazione di generazione di HOS gravi sul tessellator, consiglio di leggere questa interessante analisi delle prestazioni in game di Cypress (aka RV870) nella cui ultima parte si stabilisce che le operazioni che hanno il maggior impatto sulle prestazioni, durante e dopo la tessellation, sono quelle di Hull Shading e di Rasterization, mentre il tessellator occupa una parte minima del tempo della GPU. In basso, riporto la “torta” con le varie fasi dell’elaborazione

dove lo spicchio blu e quello arancione sono  relativi alle due suddette operazioni mentre il giallo è dovuto ad un bug dei driver ATi nella gestione del LDS (ossia della memoria locale interna ad ogni cluster).

Il fatto che gli hull shader abbiano un grande impatto sulle prestazioni non deve stupire, in quanto in questa fase, come si ricorderà, ci si occupa anche delle operazioni di displacement mapping che richiedono accessi a texture (che equivalgono ad enormi latenze). Per quanto riguarda la rasterizzazione, c’è da tener conto che le operazioni di tessellation generano un gran numero di triangoli che vanno colorati e rivestiti (altri accessi a texture oltre alle operazioni di pixel shading).

Se poi il motore grafico, analogamente a quello del tool usato nel test (Unigine Heaven 1.0) causa un notevole overdraw di poligoni nascosti, è chiaro che il peso della rasterizzazione è destinato ad aumentare, in quanto la GPU renderizzerà anche quelle superfici che, non essendo visibili, sono destinate ad essere eliminate nell’ultima fase dello z-test all’interno delle RBE.

Concludiamo questa breve analisi prestazionale col dire che è difficile stabilire, a priori, quale tra le due implementazioni darà migliori risultati in game. Quella di nVidia sembra farsi preferire dal lato delle pure e semplici operazioni di tessellation ma potrebbe incidere negativamente sulle prestazioni nel momento in cui lo shader core fosse chiamato a compiere altre elaborazioni altrettanto onerose.

Inoltre, passando a chip di fascia inferiore, al diminuire delle unità di calcolo, mentre il tessellator di ATi può restare invariato (e quindi anche un chip di fascia bassa potrebbe avere la stessa capacità di eseguire questo tipo di operazioni di uno di fascia alta), nel caso di nVidia, al diminuire del numero dei PE e dei RE diminuisce anche la potenza di calcolo che il chip può dedicare alla tessellation ed il numero di vertici che possono essere gestiti dall’input assembler per ogni ciclo. A titolo di confronto, la seguente tabella mostra le prestazioni relative ad operazioni di tessellation con displacement mapping, in diversi casi:

Da questa tabella si può vedere come la soluzione nVIDIA sia sempre in vantaggio, mostrando una miglior propensione ai calcoli geometrici in generale (che non è argomento di questo articolo) e nella tessellation in particolare. Il vantaggio massimo lo raggiunge nel caso di utilizzo di tessellation ultra unità a displacement mapping.

Come avrete notato, la tabella riporta più voci relative alla tessellation ed il motivo risulterà chiaro a breve. Posso, comunque, anticipare il fatto che esistono due modi di fare tessellation, uno detto continuous mode ed uno adaptive mode, di cui parlerò tra poco e che dove è riportata la dicitura “tessellation” si fa riferimento al continuos mode mentre l’altra voce è, chiaramente, riferita all’adaptive mode.  Entrambe le forme sono applicate facendo uso di due modalità con differente peso a livello di elaborazione.

Molto probabilmente, come sempre più spesso, purtroppo, avviene, si assisterà a situazioni che varieranno moltissimo da un titolo all’altro favorendo ora questo ora quel tipo di implementazione a seconda delle ottimizzazione di quello specifico software. Anche in questo caso, riporto due esempi di due giochi che fanno uso di tessellation e che danno risultati differenti con tessellation attiva: da un lato abbiamo Aliens vs Predator in cui è in vantaggio AMD

e per completezza riporto anche il risultato con MSAA attivo in cui la situazione si ribalta a favore di nVIDIA ma esclusivamente perchè le VGA con chip ATi vedono dimezzato, di fatto, il frame rate, a causa, molto probabilmente, di una non ottimale gestione della cache L2 (la stessa cosa accade anche a basse risoluzioni)

dall’altro Metro 2033 che, pur risultando, con i settaggi riportati in questa comparativa, ingiocabile con entrambe le soluzioni, vede un chiaro vantaggio per nVIDIA soprattutto se si fa riferimento al frame rate minimo, ma, in questo caso, il vantaggio pare determinato dal fatto che la soluzione proposta da ATi risulta frame buffer limited.

e, comunque, anche a risoluzioni inferiori, il vantaggio di Fermi appare piuttosto chiaro

Coma anticipato quanche riga più in alto, esistono, fondamentalmente, due modi di fare tessellation, ovvero i già citati continuous mode e adaptive mode. Per questo, vorrei proporre, in conclusione, un altro tipo  di analisi prestazionale che, stavolta, non mette a confronto due scelte così radicalmente differenti come quelle operate da ATi e nVIDIA quanto, piuttosto, le due suddette implementazioni di tessellation, provate sulla stessa architettura.

Come i più smaliziati avranno capito, al termine adaptive corrisponde sempre una scelta che, lungi dall’andare nella direzione della qualità assoluta, cerca di conciliare, piuttosto, qualità (magari un po’ inferiore) con prestazioni. In effetti, come per l’AF e l’antialiasing, lo stesso vale per la tessellation.

Il continuous mode si basa su un unico livello di tessellation per ogni chiamata (quindi per ciascuna mesh o gruppo di mesh); questo significa che una mesh che presenta un determinato LoD avrà tutti i suoi poligoni con lo stesso livello di tessellation e che una mesh il cui LoD sia di poco inferiore sarà uniformemente tessellata (brutta italianizzazione del termine) con un livello di poco inferiore a quello della precedente.

Il risultato è che ciascuna mesh o gruppo di mesh che abbianno lo stesso LoD presentano una tessellation di tipo omogeneo e dello stesso livello mentre le trnsizioni tra mesh con LoD differenti saranno, comunque, sfumate; ciò si traduce in transizioni dolci nelle curvature degli oggetti e in una tessellation di tipo uniforme su interi oggetti. Questo tipo di procedura impegna molte risorse e comporta lo stesso livello di tessellation anche su superfici che, all’interno del frame, risultano poco evidenti e in scarsamente in risalto.

Contrapposto a questo metodo, c’è l’adaptive mode che prevede la possibilità di avere differenti livelli di tessellation per ogni edge o spigolo della mesh. In tal modo è possibile adattare il livello di tessellation non solo sulla base dei valori del LoD ma anche in funzione delle superfici che risultano più visibili (un esempio banale è una superficie completamente in ombra ma molto vicina al punto di osservazione).

Nell’adaptive mode è necessario specificare un livello massimo ed uno minimo di tessellation e, poichè si tratta di un metodo che prevede un’analisi di tipo dinamica, si deve calcolare, per ogni frame (at render time) il tessellator edge factor. Questo tipo di operazione avviene come operazione preliminare all’inizio di ogni frame e richiede un passaggio di rendering supplementare ma permette di ridurre notevolmente il numero di poligoni generati e il conseguente impatto delle operazioni di displacement mapping e rendering. A titolo di esempio, vi invito a guardare la seguente tabella

da cui risulta evidente come, a fronte di una qualità di’mmagine leggermente inferiore, l’adaptive tessellation di tipo dinamico permette di ottenere prestazioni quasi allineate a quelle raggiungibili con l’immagine priva di tessellation, soprattutto nella vista da lontano; questo perchè, ovviamente, nella vista da vicino aumenta il LoD e, di conseguenza, Na si avvicina al valore di Nt molto di più di quanto non avvenga con la visuale da lontano (in cui il valore è molto più prossimo a quello di Nl).

Concludiamo questa breve trattazione sulla tessellation con un altro dei vantaggi che questa tecnologia offre: il risparmio di risorse. Nella demo di froblins si fa uso di un modello in bassa risoluzione sottoposta a tessellation e displacement mapping in modo analogo a quanto indicato in figura

Nella tabella in basso si può apprezzare la differenza, a livello di occupazione dei memoria, tra il modello in “bassa risoluzione” ed il modello con “dettaglio elevato”

Nella seconda riga sono riportati i valori dell’occupazione di memoria equivalente qualora, anzichè ricorrere alla tessellation ed al displacemente mapping, si fosse fatto uso di un modello originario della stessa complessità di quello ottenuto al termine delle operazioni di tessellation stesse.

Da una parte abbiamo pochi KB di occupazione dovuti ai dati relativi ai vertici trasferiti dalla CPU alla VRAM e da quest’utlima ai vertex shader e i 10 MB dovuti alla texture a 16 bit usata per il displacement mapping; dall’altra i circa 450 MB occupati dai dati di tipo geometrico, corrispondenti agli oltre 15 milioni di poligoni che la CPU doveva generare e trasferire, attraverso il bus, alla VRAM.

Quindi, oltre che per aumentare il dettaglio poligonale, il tessellator può tornare utile per ottenere un notevole risparmio di banda e di memoria occupata; inoltre, altro vantagio non trascurabile, il fatto di poter operare questa “miracolosa” moltiplicazione dei poligoni on chip, invece di dover caricare quantità enormi di dati dalla vram, sommata agli atri due vantaggi precedentemente enunciati, permette di conseguire i vantaggi visti a livello di qualità d’immagine, oppure di avere prestazioni nettamente superiori a parità dei dettaglio.

Con questo, concludo, sperando di aver fatto cosa gradita a tutti coloro che, soprattutto, in questi giorni, con l’avvento delle DX11, stanno dibattendo sui forum di tutto il mondo se sia più efficace la tessellation si ATi o quella di nViDIA e su quanti e quali vantaggi questa feature possa portare.

27 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    Giulio
     scrive: 

    Posso dire che al momento la soluzione messa in pratica da Nvidia (che poi ricalca quanto già visto in R600 e RV770) sembra andare meglio? Nei titoli DX11 si avvicina (molto) alla 5970 e, di fatto, rende giocabile titoli (Metro 2033) dove RV870 sembra proprio morire. Insomma al momento non sembra proprio che l’occupazione degli shader sia un problema.

    Yoss sbaglio o l’architettura Nvidia ha una marcia in più proprio con le dx11 e i compute shader?

    Spero di non aver detto castronate.

  • # 2
    Fabio
     scrive: 

    Grazie sempre interessante come al solito(anche se come al solito ho capito un quarto di quello che hai scritto ma non per colpa tua) anche se alle luce dei mostruosi consumi(e delle temperature) di Fermi anche se una delle 2 soluzioni fosse superiore all’altra per me diventa improponibile(Carbonia sud-ovest Sardegna qua d’estate si vedono pure i cammelli passeggiare fra un po’).

  • # 3
    yossarian (Autore del post)
     scrive: 

    @ Giulio
    non sbagli, ma ci sono da fare alcune considerazioni.
    Dai test sulla tessellation in tabella, risulta che fermi si avvantaggia soprattutto nei casi di tessellation di tipo continuous mode che è un tipo di implementazione che avrà difficilmente spazio nei giochi o in altri tipi di SW perchè l’hit prestazionale non giustifica i miglioramenti a livello di IQ. Il caso di Metro 2033 è un caso limite, in quanto il gioco è stato sviluppato in collaborazione con nVIDIA e fa uso di feature che tendono a penalizzare le vga con chip ATi. Uno di questi casi è quello illustrato nell’esempio, in cui il frame rate minimo (che incide anche su quello medio) è determinato dall’utilizzo del frame buffer.
    Per quanto riguarda i direct compute, è presto per trarre conclusioni; una cosa che si è evidenziata e che i chip ATi hanno, in alcuni casi problemi a gestire le memorie locali e questo incide non poco sulle prestazioni. Si tratta, comunque, di un problema risolvibile a livello di driver.
    Per quanto riguarda le prestazioni con dx11 (se possiamo parlare di dx11) guardando le varie recensioni, emergono dati contrastanti; al di là dei soliti metro e unigine, basta guardare review tipo queste
    http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/30297-nvidia-geforce-gtx-480-review-14.html
    http://www.hardocp.com/article/2010/03/26/nvidia_fermi_gtx_470_480_sli_review/5
    http://www.guru3d.com/article/geforce-gtx-470-480-review/

    per rendersi conto che le prestazioni, anche con tessellation, sono piuttosto allineate e altalenanti (ad esempio in AvP, addirittura vanno meglio le radeon) e che all’aumentare della risoluzione, nonostante la maggior bandwidth e il frame buffer più ampio, le prestazioni della 480 tendono ad allinearsi a quelle della 5870.

  • # 4
    Giulio
     scrive: 

    Quello che volevo dire però, è che indipendentemente dal tipo di implementazione utilizzata (continua o adattiva) Fermi non sembra comunque risentire di “mancanza di shader” mentre RV870 finite le fixed function crolla.
    Non vorrei sembrare ammorbante però se in Metro 33 Fermi gestisce contemporaneamente texturing, filtering, Physx e Tassellation (dimentico altro?) egregiamente vuol dire che prima di diventare “shader bound” ce ne vuole.

    ps. Nei titoli dove Fermi cala (mi vengono in mente Crysis e AvP) non potrebbe essere un problema di driver?
    E le 60 TMU dov’è che potrebbero limitare l’architettura?

    Grazie

  • # 5
    yossarian (Autore del post)
     scrive: 

    @ Giulio

    hai visto il test di metro? A 1920 senza AA c’è un 20% di vantaggio, con MSAA 4x le ati sono fb limited e la cosa non fa testo. Inoltre tu dici che con AvP potrebbe essere una questione di driver; può essere, ma lo stesso potrebbe essere per ati con metro, visto che, per altro, questo titolo è stato sviluppato su indicazioni di nVIDIA a detta degli stessi che lo hanno fatto e di sicuro, fermi, con metro è ottimizzato molto meglio di quanto non sia rv870.
    Le 60 TMU non credo siano un limite in assoluto perchè l’architettura è differente rispetto a quella delle tmu di G80; potrebbero diventarlo solo nella misura in cui le operazioni di texture blending vadano a pesare eccessivamente sullo shader core.
    Infine, non si può fare un’analisi prestazionale dei due chip prendendo solo la tessellation come confronto. Questo è solo uno degli aspetti ma ce ne sono molti altri che possono essere almeno altrettanto determinanti.

  • # 6
    michele
     scrive: 

    competente come pochi.. cmq mi piacerebbe che trattassi la gpu nvidia..cmq che il chip nvidia sia un mostro di “potenza” è chiaro e risalta da tutti i test che ho visto…

    certo che se si gira software ottimizzato per una o l’altra piattaforma i test non valgono..usare titoli “the way nvidia” non è molto oggettivo…però vabbè dati come il consumo(+ di 400w) la temperatura(90° fissi) e i benc mi danno l’idea di due gpu tirate fuori troppo presto quando il mondo dei videogiochi è fissato sulle 9/10 e si trova qua e là qualche implementazione eterogenea e non fondamentale nella scrittura del codice o nell’esperienza del gioco stesso….

    stesso discorso per le gpu o si hanno problemi di driver o di resa produttiva e varie complicanze come consumi e temperature…
    certo è che nvidia ha rincorso…ma mentre rimango convinto che la top sia valida per le soluzioni inferiori con il metodo di castrazione mi lascia dei dubbi (gia la mia gtx260 ha subito una castrazione pesante per poi uscire dopo poco una seconda versione con più cuda core ????? what? come? )…vabbè fino a che non faranno uscire delle versioni abbordabili e tecnicamente ben fatte è puro scontro architetturale…troppo affetto dalle varie ottimizzazioni e penalizzazioni software….

    cmq bell’articolo come gli altri li rileggerò qualche volte per capire bene ma cmq certo è che sei competente

    grazie
    ciao

  • # 7
    Giulio
     scrive: 

    Ok ho capito il discorso su Metro, escludendo i casi limiti la situazione è ancora ben lontana dall’essere definitiva.

    Grazie per le delucidazioni e l’articolo, sono una fonte preziosa per noi ignoranti :)

  • # 8
    yossarian (Autore del post)
     scrive: 

    @ MIchele
    @ Giulio

    intanto vi ringrazio per l’apprezzamento. Poi, vorrei precisare che l’articolo non è un confronto prestazionale tra 480 GTX e 5870 ma si basa solo su considerazioni relative alla tessellation per cui abbiamo pochi test in game, probabilmente poco attendibili a causa delle eccessive ottimizzazioni per l’una o l’altra architettura o della scarsa ottimizzazione dei driver e una techdemo che, come tutte le techdemo, lascia il tempo che trova. Quinndi prenderi, come parametro, il test sintstico indicato in tabella, almeno per il momento, da cui risulta che fermi è in vantaggio con questa feature. Un confronto prestazionale serio, eprò, non può prescindere da un’alisi più approfondita e, ad esempio, i risultati con la stessa tessellation non necessariamente dipendono da una miglior implementazione di questa feature da parte di nVidia; il vantaggio può essere altrove, ad esempio, nell’input assembler distribuito che può essere più efficiente. Di sicuro c’è che dai test sintetici emerge un quadro completamente ribaltato rispetto al passato, con i chip nVidia che si avvantaggiano nelle operazioni geometriche ma vanno sotto nel pixel e nel texel fillrate.

  • # 9
    streamX
     scrive: 

    L’idea di moltiplicare l’input assembler pare sia stata vincente, infatti a basse risoluzioni le nvidia sia allontano di più che alle alte.

    Yossarian sai qualcosa al riguardo del bus interno adottato ?

  • # 10
    yossarian (Autore del post)
     scrive: 

    @ streamX
    dovrebbero trattarsi di 16 canali a 128 bit, per un totale di 2048

  • # 11
    streamX
     scrive: 

    Sbaglio o sono limitati(come al solito) dal bus interno ?
    Adesso capisco la scelta di una frequenza di clock molto conservativa(RAM) ?

    Tanto valeva avere un bus esterno da 256bit…

  • # 12
    yossarian (Autore del post)
     scrive: 

    dai test in overclock fatti su rv870, sembra che il chip sia abbastanza equilibrato e manifesti una limitazione in banda solo in condizioni piuttosto estreme. Fermi ha una bandwidth superiore e non dovrebbe soffrire, a sua volta, di tale limitazione. Anche se i calcoli teorici sembrerebbero indicare che possa esistere una tale limitazione, in realtà non si può dire nulla se non si hanno informazioni sulle reali frequenze di funzionamento dei memory controller

  • # 13
    Nessuno
     scrive: 

    Volevo ringraziare yossarian per un altro articolo professionale. Non ce ne sono molti in giro, e sui “normali” forum si leggono solo ed esclusivamente limitatissime recensioni che fanno riferimento assoluto al numero di FPS senza che vi sia una minima spiegazione di nulla degli andamenti spesso contrastanti che si verificano alla modifica di risoluzione o attivazione di AA o altri effetti.

    Riguardo alla questione della soluzione nvidia di far uso degli shader per fare alcune operazioni della pipeline di tesselizzazione (riusciremo mai a trovare una parola italiana decente per questa cosa?), quale possibilità c’è che lo scheduler interno sia in grado di “sovrapporre” più elaborazioni differenti sugli stessi SM per sfruttare al max gli shader in idle?
    Ovvero, è possibile, a titolo d’esempio, che mentre gli shader in attesa dei dati provenienti dal displacing mapping possano intanto essere usati per fare altro? O che shader liberi non usati dalla tesselizzazione all’interno dello SM possano eseguire un thread parallelo agli altri?
    Come dimostrano le prestazioni, sembra evidente che Fermi non sia shader bounded, quindi implica che vi sia un capacità elaborativa potenziale non indifferente che potrebbe trovare sfogo in futuro alla maturazione dei driver.
    Ultima cosa, questione driver: è possibile sperare che ATI riesca finalmente a fare dei driver decenti che non soffrano di bachi per sfruttare la propria architettura? O dopo oltre sei mesi dal rilascio ufficiale dei nuovi chip uno può credere che il problema della gestione di memorie e in generale OpenCL (alcuni test riportano prestazioni scandalose rispetto ai chip della concorrenza, anche della generazione passata) sia un problema HW insito nel design del chip cui i driver devono mettere una pezza per quanto possibile?
    nvidia non sembra soffrire di questi problemi neanche alla prima versione dei propri diver, che devono sicuramente maturare, ma che già mostrano potenzialità di un HW acerbo non indifferente.

  • # 14
    Nessuno
     scrive: 

    Un’ultimissima richiesta.
    Sarebbe possibile che in testa ai tuoi articoli vi siano i link a quelli precedenti. Sarebbe più comodo andarli a ripescare.
    Grazie mille

  • # 15
    yossarian (Autore del post)
     scrive: 

    @ Nessuno
    Questione scheduler e sovrapposizione delle operazioni. Si, è possibile, anzi è quello che normalmente avviene per mascherare le latenze; ogni alu ha registri dedicati ai diversi tipi di istruzioni (vertex, pixel, geometry, texture e, nel caso di fermi, anche hull e domain shader). Ovviamente lo switching tra elaborazioni differenti non è for free ma richiede cicli di clock. Inoltre il thread switching è possibile solo a condizione che tra le altre istruzioni in coda ce ne siano di indipendenti rispetto a quelle in esecuzione. Uso il plurale perchè, di fatto, anche se ogni alu può eseguire una singola operazione per ciclo (o una combinazione di operazioni relative ad una istruzione, come ad esempio una madd), di fatto si possono avere più thread in circolazione grazie alla presenza di buffer in cui immagazzinare i risultati intermedi delle operazioni in attesa di essere terminate. Quindi, terza condizione perchè si possa fare thread switching è che questi buffer non siano già stati riempiti (da altre operazioni). Comunque il thread switching è la tecnica più comune utilizzata in una gpu per mascherare le latenze come detto. In una gpu ogni cluster di alu esegue, nello stesso ciclo, la stessa istruzione. Quindi la granularità a livello di istruzioni va misurata in base ai cluster e non alle singole alu. In fermi, nVidia ha fatto uso di un doppio warp scheduler per avere un livello più fine di granularità. In pratica, ad ogni ciclo, un cluster di 32 alu può mandare in esecuzione due tipi differenti di istruzioni su ciascuno dei 2 semicluster da 16 alu (ovviamente con dei limiti).
    In quanto all’essere o meno shader bounded di fermi, è presto per trarre conclusioni anche perchè i risultati mostrati con tessellation attiva sono abbastanza discordanti (in AvP pare avvantaggiarsi la soluzione ATi, mentre in metro va meglio nVidia). Di sicuro, nelle operazioni di pura tessellation la soluzione nVidia appare migliore, ma resta l’incognita derivante dalla necessità di caricare troppo gli shader. In ogni caso, come ho già detto, non è possibile fare un’analisi prestazionale basandosi sui dati della sola tessellation in quanto la stessa analisi risulterebbe falsata. Dai test sintetici emerge che fermi è in vantaggio, ad esempio, in tutti i tipi di operazioni geometriche e nelle operazioni di branching, mentre perde il confronto nel texel e nel pixel fillrate. Il problema è vedere come tutti questi tipi di calcoli saranno implementati nelle varie applicazioni e gestiti dai chip.
    Matera driver: i driver ATi hanno ancora qualche problema nella gestione delle cache e delle memorie interne e questo si evidenzia soprattutto in alcuni test come unigine (per quanto possa far testo) ma se fai riferimento ai test mostrati da Anand, allora la risposta è che quei risultati dipendono solo dal fatto che il tool utilizzato non è ottimizzato epr la vettorializzazione delle operazioni. Questo significa che i chip ATi non utilizzano il massimo parallelismo possibile e, in alcuni casi, viagginoa ad 1/5 del loro potenziale.
    In quest’altro esempio (sempre di calcoli gp si tratta) http://www.tweaktown.com/articles/3204/nvidia_geforce_gtx_470_video_card_overclocked/index14.html
    la situazione è completamente ribaltata a favore di ATi.
    In quanto al lavoro sui driver, di fatto nVIdia è da almeno 3 mesi che sta lavorando all’ottimizzazione dei driver per fermi e i problemi emersi, ultimamente, con alcune release di driver (ventole bloccate, impossibilità di salire in freuqenza, problemi con la gestione del multigpu), sono il risultato di esperimenti condotti nel tentativo di ottimizzare i driver per la nuova architettura. Quindi non parlerei, in realtà, di driver così “acerbi”. Di sicuro dei margini di miglioramento ci sono, ma questo vale per entrambe, soprattutto considerando che i chip ATi sono molto più dipendenti dalle ottimizzazioni dei driver e del SW rispetto a quelli nVidia.

  • # 16
    Nessuno
     scrive: 

    Grazie delle risposte.
    Ma perchè dici che i chip ATI sono maggiormente dipendenti dai driver?
    Con il fatto che i chip nvidia fanno ormai quasi tutto tramite shader programmabili, non è più logico aspettarsi che le perfomance dipendano dalle soluzioni/trucchi/ottimizzazioni che i driver implementeranno man mano che matureranno? Dai test si vede che in alcuni frangenti la GTX480 è poco più veloce di una GTX285, pur avendo il doppio degli shader, una migliore gestione della memoria (e maggiore banda) e unità di texturing più efficienti (e in maggior numero, anche se non proporzionalmente uguale). Come si può spiegare questa cosa se non in qualche problema dei driver?
    Poi, riguardo ai driver ATI, scusa se insisto, però sono 4 generazioni (di una architettura pressochè sempre identica a sè stessa) che si avanti con la questione “ottimizzazione alla prossima versione”. Se nvidia ci lavora da 3 mesi su una architettura completmante nuova, quanti anni è che ATI tenta di ottimizzare i driver per sfruttare gli shader con 5 unità di calcolo ciascuno? I miglioramenti ci sono a ogni release (più o meno, quando ogni tanto non tornano indietro nelle prestazioni) eppure i driver sono anche sviluppati da moltissimo tempo. E’ giusto credere che lo sviluppo nvidia dopo 3 mesi sia maturo e richieda solo un tuning?
    E soprattutto, come si concilia questa cosa della mancanza di gestione corretta della memoria, come l’hai descritta tu, dopo oltre 6 mesi di schede presenti sul mercato? (e non è che ATI a sua volta sia partita con lo sviluppo il giorno stesso del lancio).
    Scusa le molte domande ma la questione mi sembra un po’ complessa, e credo con queste problematiche gli sviluppatori non investiranno tanto presto in soluzioni come OpenCL se le prestazioni sulle schede ATI (per problemi di driver/HW o di porting da CUDA) sono quelle finora rilevate.

  • # 17
    yossarian (Autore del post)
     scrive: 

    nei chip nVidia il thread processor si occupa sia del bilancimento dei carichi di lavoro che dell’ILP, in quelli ATi solo del bilanciamento dei carichi di lavoro, mentre l’ILP è affidato al compiler. Per questo motivo sono e saranno sempre pià dipendenti dai driver e dalle ottimizzazioni del SW. Con istruzini vettoriali o vettorializzabili facilmente, i chip ATi sarebbero molto più veloci di quelli nVidia perchè potrebbero sfruttare la meglio tutte le unità di shading. Nella realtà le cose non stanno così e, in molti casi, diventa difficile trovare 5 iatruzioni indipendenti che facciano parte dello stesso thread per ogni alu 5-way vliwdi ATi. Ovviamente, il rovescio della medaglia è che ATi può compensare questa minore efficienza con il fatto che i suoi cluster di alu occupano molto meno spazio di quelli nVidia pur essendo in grado di fare più operazioni in parallelo e può compensare con la quantità.
    In quanto a GF100, è vero che ha molti più shader di GT200, ma le prestazioni non crescono linearmente con il nuermo degli shader; più unità di calcolo vanno anche organizzate e gestite e, infatti, in GF100, nVidia ha introdotto un altro livello di logica di controllo rispetto a gt200 (stessa cosa fatta da ATi in rv870 rispetto ad rv770). Questo comporta cicli di clock in più per fare le stesse cose. Le tmu di gf100 sono differenti da quelle di gt200. Hanno “solo” 64 texture addressing unit e 256 texture sampling unit (mi riferisco alla versione con 512 alu), mentre quelle di gt200 hanno 80 texture sampling e altrettante texture addressing unit. Quindi il rendimento può essere diverso a seconda del tipo di operazione che fa o meno da collo di bottiglia.
    I driver sono sempre migliorabili anche perchè devono fare da interfaccia a sw sempre nuovi che spesso richiedono ottimizzazioni. Da un lato, però, si ha un’architettura che dipende dai driver solo per dele pure e semplici ottimizzazioni (che ossono anche, al limite, comprendere la sostituzione di qualche istruzione con altre più digeribili per quella specifica architettura), dall’altro un’architettura che dipende dai driver anche per il raggiungimento del massimo livello di parallelismo.
    In quanto al discorso OpenCL, come ho già detto, il tool impiegato da Anand è solo uno dei tanti e, epr giunta, poco digeribile per l’architettura ATi (perchè non vettorializzato). Questo non significa che le ATi non vadano con OpenCL, altrimenti, guardando il link che ho postato in precedenza, si potrebbe giungere alla stessa conclusione anche per Fermi.
    Di fatto, invece, tutto dipende da come è ottimizzato il sw e da qual architettura è stata presa come riferimento.

  • # 18
    Nessuno
     scrive: 

    Grazie ancora, sei un pozzo di informazione.
    Riguardo all’OpenCL, mi viene da pensare che nei giochi è possibile (o più probabile) che il linguaggio possa venir usato per calcolare logiche e comportamenti, più che per fare direttamente i conti di qualche effetto grafico altamente parallelizzato (per quello c’è il linguaggio degli shader, no?), non sarebbe dunque una penalizzazione per l’architettura ATI?
    Ultima domanda, poi smetto davvero: ma se ATI dovesse dimostrare di riuscire a ottenere la stessa capacità di calcolo di nvidia (o anche più visto il maggior numero di unità di calcolo che le sue schede possiedono) a cosa servono quel miliardo e rotti di transistor che nvidia ha in più e che ha impiegato così tanto tepo ad aggiungere? Solo a far scaldare il chip come un fornetto?
    Si potrebbe avere un articolo approfondito sulle diverse capacità di calcolo GP delle due architetture?
    Grazie mille

  • # 19
    yossarian (Autore del post)
     scrive: 

    OpenCL servirà per le applicazioni di tipo GPGPU mentre per i giochi si continueranno ad usare prevalentemente le D3D e, marginalmente, le OpenGL. Con le architetture attuali, il calcolo dell’IA è meglio affidarlo alla cpu mentre per la gestione delle fsica una scheda dedicata resta la soluzione migliore; finora la cosiddetta fisica implementata nei giochi è ridotta a 2 effetti in croce che non migliorano l’esperienza di gioco perchè non permettono una vera interazione con l’ambiente circostante e, oltretutto, sono criticabili anche a livello di qualità degli effetti (non si è mai vista, tranne che nei videogame, una vetrata, in seguito all’impatto con un proiettile, rompersi con i vetri che esplodono cadendo all’indietro, ad esempio). Insomma, anche per l’implementazione della fisica si deve seguire una certa logica e non bastano 4 foglietti o 2 bandierine svolazzanti. Il problema è che già così, il peso per le gpu è enorme e far ricorso ad una vera implementazione della fisica metterebbe in ginocchio qualunque chip grafico. Perciò meglio una soluzione dedicata.
    Il miliardo (quasi) di transistor in più serve proprio a rendere il chip meno dipendente dalle ottimizzazioni del SW. Sia i chip ATi che nVidia hanno alu indipendenti capaci, ciascuna, di operare su un singolo thread. Il vincolo per entrambe è che tutte le unità dello steso cluster devono lavorare sulla stessa istruzione (ossia lo stesso tipo di istruzione) nello stesso ciclo. Per ATi esiste un altro vincolo: ogni alu è formata da 5 unità di calcolo e, per ogni thread, ha bisogno di 5 istruzioni indipendenti per tenerle tutte occupate pena il trovarsi ad eseguire una serie di NOP (che sono, per alu vliw, l’equivalente di lasciare in idle delle unità di calcolo). Per fare ciò, è necessario l’intervento del compilatore che deve cercare e raggruppare tutte le istruzioni indipendenti relative allo stesso thread (e deve fare questo per tutti i thread di cui è composta l’applicazione). Grazia la suo milisrdo di transistor in più, invece, i chip nVidia riescono a gestire le alu in maniera differente e non hanno bisogno di tutto questo lavoro di ottimizzazione.
    Per un articolo sul calcolo GP, sto aspettando che ci sia un po’ più di materiale a disposizione.

  • # 20
    Arriba
     scrive: 

    Tecnici dell’esercito della Repubblica Popolare Cinese sono riusciti ad asservire la potenza di un sistema con Opteron e Radeon ai loro voleri, dopo mesi di prove sono riusciti a raggiungere il Petaflop (senza ulteriori precisazioni vuol dire tutto e niente!) con hardware assolutamente economico. Usando un non precisato numero di CPU e GPU, comunque relativamente poche, con firmware della GPU AMD-ATI da loro modificato, sono passati dal 20% di resa elaborativa della GPU ad uno stimato 70%. nel video non si sbilanciano fornendo dettagli “rivelatori”. Senza ricorrere a costosi supercomputer di provenienza americana o comunque straniera hanno raggiunto lo scopo di ottenere un elaboratore ad elevate prestazioni adatto ai loro bisogni. Ovviamente militari! Secondo loro si classifica al 5° posto tra i computer più veloci al mondo. Ma è assai più economico, anche nei costi d’esercizio, e realizzato con componenti di qualità ma di comune reperibilità! Shader delle mie brame, chi ha le alu più potenti del reame?
    http://www.youtube.com/watch?v=Qrh6M_DdmXQ

  • # 21
    streamX
     scrive: 

    Yoss vorrei farti qualche domanda su fermi :

    L’implementazione della programmabilità in “C” ha richiesto un aumento dei transistor ?

    Quanto ha influito sulle performance il fatto di aver minore capacità di texturing rispetto alle ATI ?

    Il consumo fuori controllo può essere dovuto ad un progetto acerbo dei nuovi blocchi di transistors ?

  • # 22
    yossarian (Autore del post)
     scrive: 

    @ streamX
    il ricorso alla programmazione in C è solo uno degli aspetti del tentativo di nVidia di rendere fermi il più possibile assimilabile ad una cpu. Questo ha comportato un notevole aumenot di transistor a livello di logica di controllo e di gestione del chip.

    Questo è uno degli aspetti di cui si dibatterà in futuro. Di sicuro, il dato che salta all’occhio è che la maggior capacità di texturing era dai tempi di G70 appannaggio dei chip NV e, in questa generazione, invece, fermi è sotto cypress. Per fare stime quantitative si devono fare valutazioni per titolo, andando a vedere il comportamento nei giochi che presentano più situazioni di tipo texture bounded. Comunque, in questo tipo di valutazione si dovrà tener conto di altri due aspetti: i limiti imposti dal frame buffer e l’organizzazione delle memorie interne e degli accessi a texture.

    Non credo, il consumo elevato fa pensare ad un funzionamento con tensioni più alte del previsto. La potenza dissipata cresce linearmente con la frequenza ma quadraticamente con la tensione di alimentazione. Molto probabilmente, le tensioni più alte servono a garantire il funzionamento stabile del chip e la possibilità di salire in overclock.

  • # 23
    streamX
     scrive: 

    Sei stato un pochino vago rispetto al solito. (scusa se ti scoccio)

    Quali aggiunte in termini di transistor sono stati necessari per la programmabilità in “C” ? (indovino se dico atomic op e gerarchia delle cache ?)

    Cosa può aver ostacolato la crescita in frequenza rispetto alla vecchia generazione nvidia ?

    La differenza di consumi con la vecchia generazione mi sembra davvero insolita per non essere riconducibile ad un problema fuori controllo…

  • # 24
    yossarian (Autore del post)
     scrive: 

    @ streamX
    indovinato: in particolare l’utilizzo dei 32 bit per i calcoli interi e, soprattutto, l’unificazione dei 3 livelli di memoria (local. shared e global) che ha permesso l’adozione di un unico spazio di indirizzi con relatiivi puntatori mentre prima erano necessari 3 spazi di indirizzamento; con la versione precedente della PTX (1.1) i tre spazi erano logicamente divisi; gli oggetti erano allocati at compile time nella global memory ma questa non poteva essere gestita dinamicamente. In gr100 i tre spazi sono stati unificati ed è stato semplificato il passaggio dall’uno all’altro con un unico gruppo di puntatori e, quindi, dall’allocazione degli oggetti at compile time alla loro gestione at run time. Ovviamente questo ha comportato una modifica della logica di gestione e controllo del chip e, in particolare, dei gruppi di thread (warp).

    Sul discorso frequenze e consumi, l’ipotesi di qualcosa fuori controllo mi lascia scettico. I primi sample funzionanti (pochi) di fermi girano da novembre e in tutto questo tempo, se fosse stato necessario un respin per riorganizzare le metallizzaizoni al fine di ridurre i consumi, ci sarebbe stato il tempo per farlo. Al limite si sarbbe potuto posticipare il chip di un altor mese e farlo uscire con consumi accettabili. Il mio sospetto è che, invece, quelle che sono mancate all’inizio erano proprio le prestazioni e i chip che giravano tra novembre e gennaio (CES) erano più lenti di una 5870. In questi mesi si è cercato un compromesso tra prestazioni e consumi e, con questa architettura e questa revisione del chip, questo è il meglio che si è riusciti a tirare fuori. La mancanza di test prima del lancio, il non aver fatto trapelare niente sulle frequenze (prima di NV30 accadde qualcosa di analogo, ma quella volta ci fu una fuga di notizie sulle frequenze del chip che, però, all’uscita, era stato pesantemente overclockato e ci si era inventata una versione ultra che nVidia si impegnava a vendere, a chi aveva prenotato la liscia, allo stesso prezzo del pre order)il fatto che la dirigenza nVidia abbia sempre cercato di sviare l’attenzione su altro che non fossero le performance (le feature di contorno come physx, CUDA, ecc), l’aver presentato con largo anticipo prima la versione tesla e poi la geforce, il fatto che, fino quasi alla fine, ci sia stato il più stretto riserbo persino sul numero di alu funzionanti sul chip che sarbbe stato lanciato, sono tutti elementi che fanno pensare che dentro nVidia non avessero affatto le idee chiare su come presentare un prodotto con notevole ritardo, senza trovarsi a dover inseguire la concorrenza anche sul piano prestazionale. Il vero chipm pronto (o quasi) per la commercializzazione è quello che equipaggia la 470, infatti anche le tesla, presentate a novembre, hanno 448 alu perchè quello era il numero di unità che nVidia sapeva di potersi garantire e hanno frequenze dell’ordine di quelle dei due chip attuali; segno che già da allora, nVidia sapeva di poter contare su chip con quelle specifiche che, però, non sarebbero stati sufficienti a stare davanti alla 5870 (parliamo di 448 a 700 MHz).
    Nel passaggio dalla vecchia generazione c’è da tener ocnto di un fattore: diminuendo le dimensioni degli elementi circuitali e, in particolare, diminuendo la lunghezza di canale, diminuiscono le resistenze ed aumenta la corrente di leakage. Per contenerla, oltre a ridurre anche la larghezza del canale, si abbassa la tensione di alimentazione (come ho scritto prima, la potenza dissipata varia col quadrato della Vdd). Se si va a toccare la tensione di alimentazione, i consumi schizzano alle stelle; inoltre aumentando la potenza da dissipare, aumentano le temperature e il comportamento delle “resistenze” diventa non lineare (aumenta la resistività facendo calare la corrente e costringendo ad aumentare ancora le tensioni per mantenere stabile il circuito). Insomma, il tipico effetto “cane che si morde la coda”. In questo contesto non ho fatto venno agli accoppiamenti capacitivi di tipo parassita che aumentano anch’essi all’abbassarsi del processo produttivo.

  • # 25
    David
     scrive: 

    yossarian@
    Non sono del tutto d’accordo con quello che hai scritto nell’ultimo post.
    In questi ultimi mesi non mi sembra che NVIDIA sia stata più riservata del solito, anzi, è stata decisamente loquace anche senza andare a ricordare il lancio di G80.

    Credo anchio che il consumo sia riconducibile più al voltaggio, senza dimenticare i 3,2 miliardi di transistor, che ha problemi produttivi, ma non per alzare le frequenze per superare la 5870 ma bensì per la resa insufficente di GPU in grado di lavorare a tensioni più basse.

    L’altro giorno parlando con la persona che si occupa dei prodotti professionali NVIDIA qui in Italia, ho provato a chiedere come andassero le rese di GF100 e la risposta è stata “più o meno come ci aspettavamo”, ho provato ad entrare nel dettaglio chiedendogli se fossero soddisfacenti ricevendo un “soddisfacenti e molto relativo, dicimo che verso maggio avremmo risolto i problemi di disponibilità” “lo sviluppo del pp a 40nm non è andato nel migliore dei modi”.

  • # 26
    yossarian (Autore del post)
     scrive: 

    @ David

    Se i consumi elevati fossero da attribuire alla tensione di alimentazione, allora cis arebbe qualcosa che non quadra sul discorso rese produttive. Anche tenendo conto dei circa 3 miliardi di transistor, se si fa una comparazione con la precednete architettura nVidia dual gpu (la 295) si vede che quest’ultima ha, all’incirca, lo stesso numero di transistor di fermi e consuma, addirittura, qualcosa in meno, pur essendo a 55 nm. L?anomalia sta nel fatto che diminuendo le dimensioni dei componenti circuitali e, in particolare, le lunghezze di canale, diminuiscono le resistenze e, a parità di tensione di alimentazione, aumentano le correnti interne del chip, comprese le componenti parassite. Per tenere sotto controllo queste ultime, diventa necessario diminuire le tensioni di alimentazione e, così facendo, si ottiene l’effetto che, all’affinarsi dei processi produttivi, a parità di architettura o, più grossolanamente, a parità di numero di transistor, le richieste energetiche calino. Con fermi si è verificato l’esatto contrario.
    In quanto al pp in oggetto, ATi nonostante gli errori di valutazione commesi da TSMC sui 40 nm, è riuscita a tirare fuori un chip che ha più che raddoppiato i transostor rispetto alla precedente generazione, arrivando a consumare molto meno in idle e poco più in full. Al di là del grab lavoro di ottimizzazione, la limitazione dei consumi e, per qunto detto, anche in parte merito dei 40 vs 55 nm.
    Sulle rese, era normale che si sarebbero incontrati notevoli problemi: ne ha trovati ATi con un chip notevolmente più piccolo e con cluster ridondanti, a maggior ragione ne ha trovati nVidia con un chip enorme, complesso e senza ridondanze atte proprio a migliorare le rese produttive. Ma, al di là di queste considerazioni, il bilancio energetico di fermi presenta dei punti oscuri che non hanno a che fare con le rese e con il pp a 40 nm.

  • # 27
    David
     scrive: 

    @yossarian

    Infatti, qui hai riportato lo stesso discorso affrontato nei post precedenti e con il quale io ero d’accordo.
    Non so, forse risolveranno il problema più avanti con un respin delle metallizzazioni, forse non potevano più aspettare e hanno deciso di darsi tempo fino agli ultimi di Gennaio e poi andare in mass productions ritenendo il consumo tuttosommato acettabile per una scheda enthusiast, con magari l’idea di presentare un nuovo modello, magari con tutti gli SM attivi e consumi ridotti.
    Staremo a vedere.

    Il Sales Manager di NVIDIA non è che fosse tanto propenso ad entrare nei dettagli, forse anche perche non ne sapeva tantissimo a riguardo, infondo, non è di questo che si occupa.
    Ciò che ha confermato è l’arrivo a breve di una GPU con la metà dei GPC.

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.