Intervista a David Kirk: richiesta di domande

[fek]

Originariamente inviato da Pat77

Io intendo soluzioni sli o dual chip, Ppu-Gpu. Sulla carta Ageia dovrebbe essere in grado di calcolare la fisica, le variazioni morfologiche dell'ambiente, simulazioni di fluidi e particelle da 10 a 100 volte più efficacemente di qualsiasi cpu-gpu.

Il discorso e' interessante. Dipende dall'algoritmo, ma io non sono d'accordo nel dire che il chip di Ageia sia tanto piu' veloce di una GPU high-end.
Ma poniamo il caso che lo sia.

Ora, poniamo il caso che sia in grado di calcolare in qualche modo la fisica su 30.000 oggetti; il tutto si riduce a calcolare la posizione di questi oggetti in funzione del tempo (e di un certo numero di altri ingressi, per ora ignoriamoli) per 30 volte al secondo.

Il problema che spesso si ignora e': una volta che questi dati sono calcolati, devono transitare attraverso qualche bus per poi finire alla GPU per il rendering.

Ora, senza alcuna tecnica di batching (Geometry Instancing) particolare, la CPU e' in grado di spedire alla GPU non piu' di 3/4 mila oggetti separati per frame saturandosi totalmente e senza fare altro. Si tratta di un fattore 10 in meno rispetto a quanto necessario per far transitare i dati calcolati di un eventuale chip fisico. Ti sei domandato perche' non ti fanno mai vedere una demo con 30 mila oggetti?

Sto parlando di Direct3D qui, OpenGL e' un po' piu' veloce, ma il discorso sostanzialmente non cambia ed e' il motivo per il quale sono scettico riguardo a queste soluzioni.

E' piu' sensato a mio avviso fare i calcoli il piu' possibile in-place dove vengono usato, in questo caso nella GPU senza saturare i bus di connessione, che asintoticamente migliorano in prestazioni molto piu' lentamente di quanto cresca la potenza di calcolo.

[yossarian]

Originariamente inviato da fek

Puoi elaborare un po' il discorso sul caricamento e la selezione dei thread? Mi fai anche un esempio pratico per favore?

Tipo, che accade quando mando due gruppi di tre vertici alla GPU con stati diversi? Come vengono divisi i frammenti in thread? A grandi linee.

scusate il ritardo, ma ho avuto una giornata un po'...........impegnativa

hai ragione, sono stato molto pooooocoooooo prooofeeeeesssiooonaaaleeee, però andavo di fretta e spero vorrai scusarmi

Quello che intendevo è che, nei chip NV (parlo a livello di pixel shader), si fa ricorso a uno schema del tipo che segue; durante la prima fase, in base alle indicazioni del microcodice dell'istruzione da eseguire, sono configurate tmu e alu; quindi si rintracciano e si collegano tra loro tutti i quad presenti nella coda, ordinandoli in base a quanto indicato; quindi, il singolo quad entra nella pipeline, passando attraverso i vari stadi, fino ad elaborazione terminata. Mentre viene elaborato, genera un nuovo microcodice da inviare al controller che lo legge e organizza le operazioni relative al secondo quad che entra nella pipeline e così via (naturalmente l'ingresso del quad successivo non è subordinato all'uscita di quello precedente; in tal modo si può avere un gran numero di quad, almeno in teoria, che circolano all'interno della pipeline)

Nei chip ATi, invece, si ha qualcosa del genere: si collegano e si ordinano tutti i quad nella coda in base all'elaborazione da fare; si caricano nei registri delle texture le 8 texture che si prevede di usare per prime; tra queste si seleziona quella relativa al primo dato da elaborare; infine, vengono caricati tutti i dati relativi alle operazioni matematiche da eseguire (massimo 128); infine si procede all'elaborazione, adoperando i dati caricati nei registri, fino a svuotamento degli stessi.

Quello scelto da NV è un approccio di tipo dinamico (reso possibile anche dal controllo dinamico del flusso di dati), in cui ogni elaborazione fornisce indicazioni per l'elaborazione successiva; quello di ATi è un approccio "statico", in cui, una volta stabilito il dato da processare, si predispone tutto, caricando i registri costanti e assegnando gli indirizzi alle texture; in tal modo, quando parte l'elaborazione, è già tutto pronto, non solo per quanto riguarda il primo quad, ma anche i successivi, fino ad esaurimento della coda o allo svuotamento dei registri. In poche parole, secondo l'appoccio di ATi, nel momento in cui parte l'elaborazione, ogni stadio della pipeline "sa già cosa fare", mentre nel caso di nVIDIA, le operazioni vengono programmate di volta in volta.
L'approccio di ATi è migliore per quanto riguarda la gestione dei registri temporanei, richiede un minor numero di transistor (pipeline più corte) e permette di svincolare il texture processor dalle alu. Però è limitato dalla capacità dei registri costanti e quindi nel numero di elaborazioni dipendenti le une dalle altre (nel caso di nvidia si potrebbero avere, teoricamente, infinite elaborazioni l'una dipendente dall'altra, e mi riferisco in particolare alle texture, mentre per ATi il numero è limitato alla quantità di dati contenuti nelle cache: infatti, ad esempio, i chip R4x0 e R3x0, hanno 8 texture register da 16 bit per un totale di massimo 4 dependent texture read a 32 bit, anche se, stando a quanto detto da ATi, l'ideale, per avere le migliori prestazioni, si ha non superando le due; nel caso di NV40 non c'è un limite teorico alle operazioni di dependent texture read). OT (il texture processor di ATi lavora a 16 e 32 bit) FINE OT
ATi ha superato questo limite con il ricorso al'f-buffer, che però richiede l'impiego di ulteriori cicli di clock nella migliore delle ipotesi (quando si tratta di una cache on chip).

Per Dark Schneider

In assoluto l'approccio migliore non esiste; per shader molto lunghi e con molte istruzioni di tipo dependent read, è preferibile nVIDIA, per shader più corti, invece, meglio ATi.

[fek]

Originariamente inviato da yossarian

hai ragione, sono stato molto pooooocoooooo prooofeeeeesssiooonaaaleeee, però andavo di fretta e spero vorrai scusarmi

Ma che poco professionale, sono io che non lo so e volevo egoisticamente che me lo spiegassi

[fek]

Originariamente inviato da yossarian

In assoluto l'approccio migliore non esiste; per shader molto lunghi e con molte istruzioni di tipo dependent read, è preferibile nVIDIA, per shader più corti, invece, meglio ATi.

Speculazione: dici che nell'R520 hanno cambiato approccio?

[yossarian]

Originariamente inviato da fek

Ma che poco professionale, sono io che non lo so e volevo egoisticamente che me lo spiegassi

beh, anch'io ho egoisticamente approfittato di molti chiarimenti da parte tua e conto di continuare a farlo

[fek]

Originariamente inviato da yossarian

beh, anch'io ho egoisticamente approfittato di molti chiarimenti da parte tua e conto di continuare a farlo

Smettila che arrossico

Oggi sono duro, scusami, la spiegazione sull'approccio NVIDIA non mi e' chiara.

Mi fai un esempio con un triangolo di 16 pixel?
Dunque, siamo all'albo dei tempi, la GPU e' vuota, configuro le texture, i render state, gli shader, parte il primo triangolo, viene rasterizzato in 4 quad. Entra il primo quad nella prima pipeline.

A questo punto? Dimmelo passetto per passetto immaginando che io non sappia nulla (che in questo caso non e' tanto lontano dalla realta' )

[yossarian]

Originariamente inviato da fek

Speculazione: dici che nell'R520 hanno cambiato approccio?

direi di si; i casi sono due: o hanno implementatio grandi quantitativi di cache da utilizzare come f-buffer on chip o per ampliare a dismisura i registri (e comunque, in quest'ultimo caso, il problema sarebbe solo "spostato un po' più in la", ossia fino al limite della capacità dei nuovi registri), oppure hanno modificato la logica di funzionamento; l'approccio attuale è mutuato da quello delle cpu e non è ideale per l'elaborazione di shader lunghi e complessi da dover elaborare necessariamente in multipass.
Secondo me (anche se non ho la sfera di cristallo e ciò che dico va preso moooolto col beneficio del dubbio) R520 sarà una sostanziosa evoluzione di R420 e non una semplice revisione

[yossarian]

Originariamente inviato da fek

Smettila che arrossico

Oggi sono duro, scusami, la spiegazione sull'approccio NVIDIA non mi e' chiara.

Mi fai un esempio con un triangolo di 16 pixel?
Dunque, siamo all'albo dei tempi, la GPU e' vuota, configuro le texture, i render state, gli shader, parte il primo triangolo, viene rasterizzato in 4 quad. Entra il primo quad nella prima pipeline.

A questo punto? Dimmelo passetto per passetto immaginando che io non sappia nulla (che in questo caso non e' tanto lontano dalla realta' )

Oddio, la cosa va immaginata con molto più di 4 quad, facenti parte di diversi frammenti e tutti presenti nella coda dei dati da elaborare; comunque, il primo quad arriva all'ingresso della pixel pipeline; passa attraverso un'unità che legge una sorta di microcodice recante informazioni sul tipo di elaborazione da fare; la pixel pipeline viene organizzata di conseguenza, predisponendo le alu e la tmu per quello specifico tipo di elaborazione. Ovvio che mi sto riferendo a elaborazioni che richiedono più cicli di clock (le altre sono molto poco interessanti); il microcodice contiene informazioni sul numero e sul tipo di operazioni che devono essere eseguite su quello specifico quad; quindi, ad esempio, se devono essere eseguiti calcoli che richiedono l'utilizzo della tmu per n volte con in più m calcoli matematici, si può partire, ipoteticamente, con un rapporto 1:1 tra math ops e texture fetch (ho sparato a caso, quindi potrebbe non essere così e, comunque, sicuramente, il rapporto iniziale è fortemente dipendente da quanto è grande m rispetto a n); una volta fatto ciò, il quad entra nella pipeline e inizia a essere elaborato; una volta che il quad 1 ha passato i primi stadi di elaborazione, entra il quad 2 e si ripete il procedimento; di conseguenza, il primo blocco di unità di calcolo viene riorganizzato per accogliere il secondo quad; questo procedimento si ripete fino al momento dell'uscita del quad 1 dalla pixel pipeline; a questo punto, il quad 1 è dirottata all'interno di un quad buffer (che si trova dentro la pixel pipeline) e viene messo in attesa; nel compiere le varie operazioni all'interno della pixel pipeline, il microcodice (che non è altro che un registro delle operazioni da eseguire e di quelle eseguite) viene aggiornato e le informazioni sono inviate all'ingresso della pixel pipeline, dove vengono confrontate con il microcodice del quad che si trova in quel momento, per la prima volta, all'ingresso della stessa. Dal confronto delle operazioni da eseguire immediatamente sui due quad e dai dati risultanti sullo stato di occupazione delle unità di calcolo all'interno della pipeline, nonchè del numero di quad che sono, in quel momento in elaborazione, un controller decide quale quad far entrare (se il n°1 per il secondo ciclo o quello che si è presentato in quel momento, per la prima volta, all'ingresso). In questo tipo di elaborazione, le unità di calcolo vengono ogni volta riconfigurate e lo stesso vale per i dati caricati all'interno dei registri.
Col metodo seguito da ATi, invece, l'analisi dei microcodici è fatta all'inizio, per tutti i quad che possono essere ospitati al'interno della pipeline; di conseguenza, anche il lavoro delle unità di calcolo e lo stato di occupazione dei registri di sola lettura e di lettura/scrittura sono organizzati, completamente, prima che il primo quad faccia il suo ingresso nella pixel pipeline. Ovviamente, una volta esaurita l'elaborazione degli n quad che le pipeline può ospitare, si azzera e si riconfigura tutto per il successivo gruppo di quad.

Stavolta spero di essere stato più chiaro

[fek]

Originariamente inviato da yossarian

Stavolta spero di essere stato più chiaro

Chiaro! Grazie

Vediamo se ho capito.
Io ho uno shader con un certo elenco di istruzioni.

Esempio per semplificare:

fetch 1
alu 1
fetch 2
norm 2

fetch 1 e alu 1 sono raggruppati nel pass 1
fetch 2 e norm 2 sono raggruppati nel pass 2

Se non sbaglio, per l'NV40.

Entra il primo quad. La pipeline analizza il primo pass, si configura per eseguire un fetch e un alu e butta dentro il quad 1. Presumibilmente ad un certo stadio aspettera' che il fetch 1 prelevi e filtri il texel. Entra il secondo quad che deve eseguire sempre il pass 1 e la storia si ripete. Ad un certo punto immagino che quad 1 e quad 2 siano fermi e aspettino i loro relativi fetch. Il tempo passa e prima o poi arrivano i dati e i due quad escono dal primo pass nella pipeline.

Secondo pass, entra il quad 1, la pipeline si configura per un fetch e per una normalizzazione (sempre NV40) e si riparte per il secondo pass.

A parte gli errori e le imprecisioni, e' questa l'idea?

(Oggi ti sfrutto )

[fek]

Aggiungo, immagino che ogni quad si porti dietro le informazioni su quale pass all'interno dello shader deve eseguire.

[youthgonewild]

Potresti fare una domanda del genere:
"Si parla spesso di imminente rivoluzione nel modo di concepire i futuri videogiochi sia nel campo delle console che in quello del personal computer.Quali sono i vosti progetti in merito?Siete convinti che sia necessario implementare sempre nuove istruzioni nelle gpu per dare maggior realismo alle scene 3d o sono i programmatori di software che secondo voi devono dare inizio a questa "svolta"?"

[yossarian]

[quote=fek]Chiaro! Grazie

Vediamo se ho capito.
Io ho uno shader con un certo elenco di istruzioni.

Esempio per semplificare:

fetch 1
alu 1
fetch 2
norm 2

fetch 1 e alu 1 sono raggruppati nel pass 1
fetch 2 e norm 2 sono raggruppati nel pass 2

Se non sbaglio, per l'NV40.

Entra il primo quad. La pipeline analizza il primo pass, si configura per eseguire un fetch e un alu e butta dentro il quad 1. Presumibilmente ad un certo stadio aspettera' che il fetch 1 prelevi e filtri il texel. Entra il secondo quad che deve eseguire sempre il pass 1 e la storia si ripete. Ad un certo punto immagino che quad 1 e quad 2 siano fermi e aspettino i loro relativi fetch. Il tempo passa e prima o poi arrivano i dati e i due quad escono dal primo pass nella pipeline.

Secondo pass, entra il quad 1, la pipeline si configura per un fetch e per una normalizzazione (sempre NV40) e si riparte per il secondo pass.

A parte gli errori e le imprecisioni, e' questa l'idea?

[quote]

diciamo che, in teoria, la situazione di "attesa" non dovrebbe verificarsi, però può accadere (anzi, considerando che non ci si limita a soli due quad, succede sicuramente e il quad buffer è li anche per questo) che ci siano più pixel che stiano in attesa della stessa istruzione; questo rende inefficiente l'elaborazione, perchè non tutte le unità sono impiegate; inoltre, considerata la ridotta capacità del quad buffer, se in un qualunque punto x della pipeline si crea un ritardo nell'elaborazione, gli altri quad in ingresso vengono bloccati, finchè non riprende l'elaborazione di quelli già presenti all'interno.
Questi inconvenienti dovrebbero subire un drastico ridimensionamento con ladozione di unità di calcolo generiche, con un'organizzazione diversa dall'attuale (anche se, pure queste ultime, non raggiungeranno il 100% dell'efficienza di cui parla Richard Huddy)

[yossarian]

Originariamente inviato da fek

Aggiungo, immagino che ogni quad si porti dietro le informazioni su quale pass all'interno dello shader deve eseguire.

esatto: è il microcodice di cui parlavo prima; reca informazioni relative a tutto l'iter di quello specifico quad, passo per passo

[yossarian]

Originariamente inviato da fek

(Oggi ti sfrutto )

se mi licenziano per scarso rendimento ti mando il conto delle spese mediche...........di tutta la famiglia, gatto compreso

[Maury]

Originariamente inviato da yossarian

se mi licenziano per scarso rendimento ti mando il conto delle spese mediche...........di tutta la famiglia, gatto compreso

Ma chi ti licenzia ? ATI o nVidia ?

te non la racconti giusta, chi sei davvero ? leva la maschera!!

[DjLode]

Te lo svelo io, in realtà yoss è Gabe Newell.

[Crashman]

Originariamente inviato da DjLode

Te lo svelo io, in realtà yoss è Gabe Newell.

Lo sapevoooooo

[fek]

Originariamente inviato da yossarian

diciamo che, in teoria, la situazione di "attesa" non dovrebbe verificarsi, però può accadere (anzi, considerando che non ci si limita a soli due quad, succede sicuramente e il quad buffer è li anche per questo) che ci siano più pixel che stiano in attesa della stessa istruzione; questo rende inefficiente l'elaborazione, perchè non tutte le unità sono impiegate; inoltre, considerata la ridotta capacità del quad buffer, se in un qualunque punto x della pipeline si crea un ritardo nell'elaborazione, gli altri quad in ingresso vengono bloccati, finchè non riprende l'elaborazione di quelli già presenti all'interno.

Ma le latenze dei texture fetch non sono inevitabili?
Quando un quad si blocca su un fetch non viene messo in una specie di coda d'attesa che il fetch si completi per far posto ad altri quad di passaggio?

Almeno so che l'R500 fa qualcosa di simile, scambiando thread in attesa di fetch con thread che hanno tutti i dati a disposizione per l'esecuzione.

[yossarian]

Originariamente inviato da fek

Ma le latenze dei texture fetch non sono inevitabili?
Quando un quad si blocca su un fetch non viene messo in una specie di coda d'attesa che il fetch si completi per far posto ad altri quad di passaggio?

Almeno so che l'R500 fa qualcosa di simile, scambiando thread in attesa di fetch con thread che hanno tutti i dati a disposizione per l'esecuzione.

si, ma la coda d'attesa è limitata; il problema sorge quando più pixel sono in attesa dello stesso tipo di operazioni; in R500 le cache interne sono di dimensioni decisamente più generose e l'architettura stessa del chip prevede la possibilità di ridurre al minimo il rischio che ci siano più quad in attesa dello stesso fetch. R500 è dotata di una crossbar connection tra le texture unit e i 48 gruppi di alu generiche (raggruppate a 16 a 16); la logica è molto simile (e c'è un arbiter o controller che dir si voglia, che si occupa di "dirigere il traffico"; sono i mezzi tecnici che sono diversi (parcheggi più ampi e più vie di rifornimento per R500) e rendono l'architettura di R500 molto più efficiente.
Tra l'altro, e qui dovrei rig... , informarmi meglio , il quad buffer interno alla pixel pipeline dovrebbe essere di tipo FIFO


PER I TRE SPIRITOSONI (Maury, DjLode e Crashman): si Gabe Newell con 70 Kg di meno

[Pat77]

http://games.tiscali.cz//images/black&white2/bfgf.jpg

Con Ageia cose del genere saranno all'ordine del giorno?