[Riflessioni] Intervista a David Kirk di Vifani

[Pat77]

I Bitboys

Che fine ha fatto il glaze 3d?

Pk77

[yossarian]

Originariamente inviato da Vifani
Non è un caso che io abbia fatto quella domanda a Kirk citando due tecnologie alternative: il TBR e l'embedded-RAM rispettivamente di PowerVR e di Bitboys.

Io penso che il discorso che ha fatto Kirk sul costo delle memorie sia un discorso giusto nell'ottica commerciale di un'azienda. Di fatto se le memorie costano sempre di meno la necessità reale di sviluppare una tecnologia di rendering radicalmente differente (con tutti i costi che ciò comporta per renderla affidabile, veloce, ecc...) non sono minimamente giustificati. Concordo con chi dice "ma non possiamo mica aumentare le frequenze e le dimensioni dei bus all'infinito", ma di fatto fino a quando sarà possibile proseguire per questa strada, lo si farà perché è semplicemente la più economica. Non penso sia un caso che Kirk abbia detto che in futuro potrebbe essere la giusta strada da percorrere.

Riguardo il discorso della complessità poligonale, ovviamente sappiamo bene quanto un'architettura come quella TBR sia dipendente dal numero di poligoni utilizzati. La creazione delle triangle-list per tile è un po' il suo punto debole anche se PowerVR afferma di aver risolto questo problema al punto che esistono soluzioni PowerVR MBX con Vertex Processor Programmabile (compatibile VS 1.1). Ovviamente Kirk avrà risposto avendo in mente bene la tecnologia Gigapixel e non quella PowerVR e non sappiamo bene in cosa si differenziano.

Io sono sicuro che un'architettura come quella TBR darebbe enormi vantaggi soprattutto oggi che il calcolo per fragment si sta appesantendo con i pixel shader 2.0 e 3.0. Immaginate il risparmio di risorse di calcolo derivante dall'eliminazione di tutte le superfici nascoste?

PowerVR e Bitboys si sono buttati nel settore mobile, guarda caso un settore in cui il discorso "le memorie costano poco e possiamo incrementare le dimensioni dei bus" va a cozzare contro il problema del risparmio energetico, assolutamente primario in questo mercato.

E hai fatto benissimo a citarle entrambe.
Io, ad esempio, sono tra quelli che sostengono che non si possono aumentare le dimensioni del bus e salire in frequenza all'infinito. Innanzitutto perchè aumentare le dimensioni del bus comporta anche l'aumento della capacità di trasferimento dati all'interno del chip, al fine di avere un flusso di dati bilanciato. Non è un caso che chip con bus a 128 bit e ram ddr (quindi 256 bit trasferiti per ciclo) avevano architettura interna a 256 bit, mentre chip con bus a 256 bit e ram ddr hanno architetture a 512 bit (unica eccezione NV35 che però era nato da un progetto che in origine prevedeva il bus a 128 bit). Riguardo alle frequenze, si è trovato l'escamotage del clock interno, che permette di moltiplicare i dati trasferiti per ciclo, a parità di frequenza di core. Però anche questo non è un processo esente da problemi. Le GDDR3, ad esempio, che rispetto alle SDR trasferiscono 8 bit per ciclo di clock (4 il lettura e 4 in scrittura), hanno avuto seri problemi di stabilità operativa (non ancora del tutto risolti) con il core a 200 Mhz (bitrate pari a SDR da 1600 Mhz), tanto che si stanno adottando soluzioni molto conservative (le ram da 1200 Mhz hanno core frequency di 150 Mhz e quelle da 1000 di 125).

In merito al problema del TBR in presenza di elevato numero di poligoni, è vero che esiste il problema della triangle list per tile, però è anche vero che è un problema che si può affrontare in vari modi, uno dei quali è quello di affiancare al TBR un algoritmo di HSR "tradizionale, che operi su una tessera nxn utilizzando un valore pivot, per poi passare al tbr solo in caso di "dubbio" e ridurre le dimensione della tessera su cui si opera (in modo da ridurre il numero di triangoli coinvolti nell'operazione). Questo potrebbe servire a contenere le dimensioni della triangle list e a minimizzare il numero di volte in cui si fa ricorso al tbr.

[Vifani]

Originariamente inviato da yossarian
In merito al problema del TBR in presenza di elevato numero di poligoni, è vero che esiste il problema della triangle list per tile, però è anche vero che è un problema che si può affrontare in vari modi, uno dei quali è quello di affiancare al TBR un algoritmo di HSR "tradizionale, che operi su una tessera nxn utilizzando un valore pivot, per poi passare al tbr solo in caso di "dubbio" e ridurre le dimensione della tessera su cui si opera (in modo da ridurre il numero di triangoli coinvolti nell'operazione). Questo potrebbe servire a contenere le dimensioni della triangle list e a minimizzare il numero di volte in cui si fa ricorso al tbr.

Non penso che una soluzione simile sia fattibile o cmq decadrebbero la maggioranza dei vantaggi del rendering per Tile.

Con il TBR una volta eseguita la fase di setup dei triangoli, le triangle list sono già tutte belle e pronte. Una volta passati al rendering per implementare quello che dici tu dovrebbero ritornare in fase di setup dei triangoli, pescare il triangolo in cui ricadono i fragment sospetti, individuare il viewport (la tessera) che ci interessa e applicare il rendering TBR su quella tessera. Troppi via vai... troppo complesso. Il TBR di fatto è semplicissimo.

E poi l'architettura TBR non è legata solo alla triangle list, ma è un modo di approcciarsi completamente differente a quello tradizionale. Il FSAA, lo z-buffer, il frame buffer, lo stencil buffer, ecc... sono tutti eseguiti ON CHIP. Il frame buffer ad esempio è calcolato tutto on chip e solo una volta definito il colore di tutti i pixel di quella tile lo si trasporta sulla memoria video. A parte questo accesso, l'unico altro accesso alla memoria video è rappresentato dal caricamento delle texture (solo quelle visibili).

[checo]

imho un film già visto per quanto riguarda le cpu.
considerando che lo sviluppo di chip 3d per home pc è molto recente rispetto a quello delle cpu si nota un ripetersi della storia, ovvero, finchè possibile aumentiamo le frequenze per dare più prestazioni, e di volta in volta ci mettiamo le nuove features
come se la geforce1 fosse il corrispettivo del 386
la geforce 3 del pentium
la geforce fx del pentium pro
e via dicendo, si arriverà certamente ad un punto dove è più conveniente ottimizzare chip e memorie piuttosto che aumentarne frequenze e bus, chiedere alla intel per delucidazioni

[Simon82]

Il discorso di aumentare a dismisura le frequenze perche' e' la via piu' semplice imho ricalca l'inutilita' nelle macchine americane che hanno motori 5000cc 6000cc V8-V10 per poter fare magari 300 cavalli su un telaio di millemila chili...
Il risparmio che ci sarebbe nell'investire in tecnologie che porterebbero a una eliminazione di tanto sovraccarico di lavoro inutile nelle varie fasi di rendering, potrebbe imho essere bilanciato con l'uso gratuito di altre features. Risparmiare in un punto per poter eccedere nell'altro. (vedi FSAA.. AF.. ).

[BTinside]

Originariamente inviato da Simon82
Dire comunque che non ci sono mai state buone soluzioni Tile based... se con il Kyro2 Nvidia non si e' mangiata le mani vedendo che una soluzione con un quarto della potenza della loro Ge2 GTS potesse spingerla e sorpassarla in alcuni casi..

Quto in pieno

[BTinside]

Originariamente inviato da Pat77
Eh bhe, mi sembra un discorso molto poco professionale, anche perchè bus e ram vengono pagati da noi.
Tra le righe imho costerebbe troppo produrre e ottimizzare una soluzione tile di fascia alta, ma questo superare i problemi con la quantità piuttosto che con la qualità non mi piace nemmeno un po'.

Pk77

Secondo me non ne hanno proprio la voglia di produrre una soluzione basata su tbr

[BTinside]

Originariamente inviato da GMCPape

COnsidera inoltre che Ultrashadow alla fine non è che una tecnologia simile: invece di essere applicata ai poligoni, è applicata alle ombre (trattate per l'appunto come poligoni, in D3). Il fatto è che, pur presente, non è attivata nei driver (a sentire David Kirk, solo alcune delle sue funzioni sono state attivate), ma a sentire Carmack, non farebbe grosse differenze. Ergo... il tile rendering poteva essere eccezionale con le misere schede di allora, ma le architetture di oggi non ne traggono un enorme vantaggio, a meno di ottimizzare in maniera particolare il progetto del chip (sempre a detta di Kirk), aumentando il costo e la complessità

Pape

Diciamo pure che l'Ultrashadow è stato reso funzionante ,indipendentemente dall'implementazione da parte dei programmatori , soltanto a partire da NV4X, ribattezzato in UltrashadowII.
Tuttavia l'UltrashadowII, pur funzionando senza implementazioni necessarie nel motore grafico del gioco( a detta di Nvidia), non verrà sfruttato sicuramente al 100%.
Per farne un uso utile e tangibile deve essere pur sempre implementato dai prog, quindi mi sà ke non serva a molto,
sarebbe stato meglio il tile rendering

A questo punto viene da chiedersi : ma in che percentuale l'ultrashadow in Doom3 pone le soluzioni nvidia in vantaggio su quelle Ati che non ce l'hanno?
Secondo me non molto, tutto quel vantaggio sarà dovuto ai driver ogl di Nvidia.
Se qualcuno sa spararmi un numero sui vantaggi di tale tecnologia in questo gioco lo faccia pure please....

[BTinside]

Originariamente inviato da Simon82
Ottima osservazione.

Osservazione da convertire in domanda per l'intervista a Kirk

[Vifani]

Originariamente inviato da BTinside
Diciamo pure che l'Ultrashadow è stato reso funzionante ,indipendentemente dall'implementazione da parte dei programmatori , soltanto a partire da NV4X, ribattezzato in UltrashadowII.
Tuttavia l'UltrashadowII, pur funzionando senza implementazioni necessarie nel motore grafico del gioco( a detta di Nvidia), non verrà sfruttato sicuramente al 100%.
Per farne un uso utile e tangibile deve essere pur sempre implementato dai prog, quindi mi sà ke non serva a molto,
sarebbe stato meglio il tile rendering

A questo punto viene da chiedersi : ma in che percentuale l'ultrashadow in Doom3 pone le soluzioni nvidia in vantaggio su quelle Ati che non ce l'hanno?
Secondo me non molto, tutto quel vantaggio sarà dovuto ai driver ogl di Nvidia.
Se qualcuno sa spararmi un numero sui vantaggi di tale tecnologia in questo gioco lo faccia pure please....

Veramente la tecnologia UltraShadow racchiude in se tutta una serie di ottimizzazioni:

- fill rate doppio nel trattamento dello z-buffer e dello stencil buffer;
- two sided stencil buffer: eliminazione di una passata di rendering;
- depth bounds test: riduzione dell'overdraw nel calcolo delle volume shadow

Di queste la prima è legata all'architettura di NV3x e NV4x e pertanto è indipendente dall'implementazione dal programmatore. La seconda deve essere implementata necessariamente (anche se ormai lo fanno tutti perché è uno standard) ed è supportata anche dalle schede Radeon e Volari. L'ultima deve essere implementata necessariamente ed è esclusiva di NVIDIA.

Considera che la prima permette a NV40 di eseguire la passata di rendering in cui di scrive nello z-buffer e quella in cui si scrive nello stencil buffer a quasi il doppio della velocità di R420. L'ultima offre qualche vantaggio anche se sembra che tale vantaggio sia meno marcato di quello che ci si aspettava.

[BTinside]

Originariamente inviato da Vifani
Veramente la tecnologia UltraShadow racchiude in se tutta una serie di ottimizzazioni:

- fill rate doppio nel trattamento dello z-buffer e dello stencil buffer;
- two sided stencil buffer: eliminazione di una passata di rendering;
- depth bounds test: riduzione dell'overdraw nel calcolo delle volume shadow

Di queste la prima è legata all'architettura di NV3x e NV4x e pertanto è indipendente dall'implementazione dal programmatore. La seconda deve essere implementata necessariamente (anche se ormai lo fanno tutti perché è uno standard) ed è supportata anche dalle schede Radeon e Volari. L'ultima deve essere implementata necessariamente ed è esclusiva di NVIDIA.

Considera che la prima permette a NV40 di eseguire la passata di rendering in cui di scrive nello z-buffer e quella in cui si scrive nello stencil buffer a quasi il doppio della velocità di R420. L'ultima offre qualche vantaggio anche se sembra che tale vantaggio sia meno marcato di quello che ci si aspettava.

Tu dici che il fill rate doppio nel trattamento dello Z e dello Stencil buffer permertte a NV40 di eseguire la passata di rendering in cui si scrive in Z e Stencil a quasi il doppio di R420,
ma scusa l'R420 non recupera con l'HyperZ HD?
Se non è così ecco spiegata la maggior efficienza di NV40 che compete con R420 con valori di frequenze core, ram e capacità poligonale abbastanza inferiori (almeno..credo
)

[Vifani]

Originariamente inviato da BTinside
Tu dici che il fill rate doppio nel trattamento dello Z e dello Stencil buffer permertte a NV40 di eseguire la passata di rendering in cui si scrive in Z e Stencil a quasi il doppio di R420,
ma scusa l'R420 non recupera con l'HyperZ HD?
Se non è così ecco spiegata la maggior efficienza di NV40 che compete con R420 con valori di frequenze core, ram e capacità poligonale abbastanza inferiori (almeno..credo
)

Si ma fai attenzione. L'uso delle passate di rendering in cui si scrive solo sullo z-buffer o solo sullo stencil buffer è molto raro. Viene utilizzato massicciamente solo quando si usano le stencil shadows, cioè le ombre di Doom III. La maggioranza delle volte il rendering si effettua scrivendo contemporaneamente nel frame buffer e nello z-buffer e in questo caso NV40 e R420 si comportano allo stesso modo.

L'Hyper-Z HD racchiude tecniche di compressione del colore e dei dati dello z-buffer e altre tecniche per la rimozione di superfici nascoste. Per questo non rientra particolarmente utile nella generazione delle stencil shadow: solo nell'ultima passata in cui si scrive nel frame buffer è utile.

[Pat77]

Originariamente inviato da Simon82
Il discorso di aumentare a dismisura le frequenze perche' e' la via piu' semplice imho ricalca l'inutilita' nelle macchine americane che hanno motori 5000cc 6000cc V8-V10 per poter fare magari 300 cavalli su un telaio di millemila chili...
Il risparmio che ci sarebbe nell'investire in tecnologie che porterebbero a una eliminazione di tanto sovraccarico di lavoro inutile nelle varie fasi di rendering, potrebbe imho essere bilanciato con l'uso gratuito di altre features. Risparmiare in un punto per poter eccedere nell'altro. (vedi FSAA.. AF.. ).

Lode a Amd e Nvidia comunque, che con Nv40 e Athlon64 hanno creato architetture indubbiamente più efficenti oltre che "grosse".

Pk77

[BTinside]

Originariamente inviato da Simon82
Il discorso di aumentare a dismisura le frequenze perche' e' la via piu' semplice imho ricalca l'inutilita' nelle macchine americane che hanno motori 5000cc 6000cc V8-V10 per poter fare magari 300 cavalli su un telaio di millemila chili...
Il risparmio che ci sarebbe nell'investire in tecnologie che porterebbero a una eliminazione di tanto sovraccarico di lavoro inutile nelle varie fasi di rendering, potrebbe imho essere bilanciato con l'uso gratuito di altre features. Risparmiare in un punto per poter eccedere nell'altro. (vedi FSAA.. AF.. ).

Piccolo OT
Insomma diciamo che le cilindrate da te elencate appartengono ad automobili di fascia sportiva,
quà in europa abbiamo i 3600 V6 e i 4300V12 non è che siamo poi così distanti.
loro hanno la fissazione del "big is better" e delle cose robuste, mentre quà in Italia si dice "il buon vino sta nella botte piccola",
da loro il carburante costa meno che da noi, non si preoccupano dei consumi, e preferiscono fare motori robusti che durino molto senza eccedere con i cavalli, ecco spiegate le cilindrate quasi da camion.

[yossarian]

Originariamente inviato da Vifani
Non penso che una soluzione simile sia fattibile o cmq decadrebbero la maggioranza dei vantaggi del rendering per Tile.

Con il TBR una volta eseguita la fase di setup dei triangoli, le triangle list sono già tutte belle e pronte. Una volta passati al rendering per implementare quello che dici tu dovrebbero ritornare in fase di setup dei triangoli, pescare il triangolo in cui ricadono i fragment sospetti, individuare il viewport (la tessera) che ci interessa e applicare il rendering TBR su quella tessera. Troppi via vai... troppo complesso. Il TBR di fatto è semplicissimo.

E poi l'architettura TBR non è legata solo alla triangle list, ma è un modo di approcciarsi completamente differente a quello tradizionale. Il FSAA, lo z-buffer, il frame buffer, lo stencil buffer, ecc... sono tutti eseguiti ON CHIP. Il frame buffer ad esempio è calcolato tutto on chip e solo una volta definito il colore di tutti i pixel di quella tile lo si trasporta sulla memoria video. A parte questo accesso, l'unico altro accesso alla memoria video è rappresentato dal caricamento delle texture (solo quelle visibili).

non sarebbe necessario tornare alla fase di setup; basterebbe utilizzare un registro di modeste dimensioni dove, per ogni tile analizzato, sia immagazzinato un valore pivot, accoppiato ad un circuito comparatore. All'atto della scansione dello stesso settore del'immagine, sarebbe sufficiente fare il confronto tra i valori della nuova tessera con quelli del pivot. Se il valore più grande della nuova tessera è inferiore a quello utilizzato come termine di paragone, si eliminano tutti i pixel che la formano. Sarebbe solo da introdurre un passaggio in più nell'elaborazione che, se da un lato richiederebbe qualche ciclo di clock di più, dall'altro potrebbe far risparmiare il tempo necessario ad un'analisi per pixel, mentre tutto il resto rimarrebe invariato

[Simon82]

Originariamente inviato da BTinside
Piccolo OT
Insomma diciamo che le cilindrate da te elencate appartengono ad automobili di fascia sportiva,
quà in europa abbiamo i 3600 V6 e i 4300V12 non è che siamo poi così distanti.
loro hanno la fissazione del "big is better" e delle cose robuste, mentre quà in Italia si dice "il buon vino sta nella botte piccola",
da loro il carburante costa meno che da noi, non si preoccupano dei consumi, e preferiscono fare motori robusti che durino molto senza eccedere con i cavalli, ecco spiegate le cilindrate quasi da camion.

E' uno spreco.. semplicemente.. una macchina che fa i 2 al litro sebbene la benzina costi un terzo inquina e non ha motivo di esistere..

[BTinside]

Originariamente inviato da Simon82
E' uno spreco.. semplicemente.. una macchina che fa i 2 al litro sebbene la benzina costi un terzo..

tanto loro i soldi li hanno

[Simon82]

Originariamente inviato da BTinside
tanto loro i soldi li hanno

Se li usassero in altre spese sarebbe meglio.

Da qui il concetto.. risparmia qua per spendere la dove ce n'e' bisogno.

[BTinside]

Originariamente inviato da Simon82
Se li usassero in altre spese sarebbe meglio.

Da qui il concetto.. risparmia qua per spendere la dove ce n'e' bisogno.

e lo so però nelle automobili la questione è un po' complessa.
Si si risparmia però poi ci vendono motori 1.8 Turbo spinti a 225 cv (non faccio nomi) con turbocompressori che vanno a temperatura troppo facilmente (con degrado delle prestazioni) e motori in alluminio(al posto della tradizionale e affidabile ghisa) troppo fragili per sopportare quel numero di cv fin quando poi non ti spaccano la testata.
Magari per le vga questi problemi non sorgono

[Spytek]

Originariamente inviato da BTinside
e lo so però nelle automobili la questione è un po' complessa.
Si si risparmia però poi ci vendono motori 1.8 Turbo spinti a 225 cv (non faccio nomi) con turbocompressori che vanno a temperatura troppo facilmente (con degrado delle prestazioni) e motori in alluminio(al posto della tradizionale e affidabile ghisa) troppo fragili per sopportare quel numero di cv fin quando poi non ti spaccano la testata.

Parli per caso della TT, o S3?