View Full Version : [Riflessioni] Intervista a David Kirk di Vifani
Direi che possiamo scrivere qui i commenti e le domande da porre a Vifani sull'ottima intervista fatta ai PR di Nvidia. :)
Vuoi sapere quale tecnologia introdurremo? (sorride) Non lo so quale tecnologia introdurremo, ma il futuro è lontano e nel futuro tutto è possibile. Io penso che sicuramente vedremo bus più ampi e più veloci seguendo l'attuale trend. Riguardo il tile based rendering non penso che ci siano mai stati prodotti di grande successo basati su questa tecnologia. Noi abbiamo valutato questa tecnologia pervenutaci dall'acquisizione del core assets di 3dfx Interactive con il nome Gigapixel. Esistono essenzialmente due benefici derivanti dall'uso di una simile architettura. Il primo riguarda la banda passante ed il quantitativo di memoria che è possibile risparmiare. Questo beneficio, tuttavia, è reso del tutto superfluo dalle le dimensioni dei bus di oggi uniti alla memoria dai costi sempre più bassi e abbordabili. Il secondo beneficio consiste essenzialmente nel non disegnare le superfici non visibili scartando i poligoni nascosti, il che è sicuramente molto interessante, ma richiede la realizzazione di un hardware troppo complesso affinché questa operazione possa essere svolta in fluidità anche con le scene ricche di poligoni
Questa un po' mi puzza.. :D;)
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
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
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.. ;):D
Dici poco, inoltre era una scheda molto economica, peccato per qualche lacuna di troppo dei driver :(
Pk77
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.. ;):D
Io ho avuto una Kyro2, e andava benone, lasciava dietro la mia vecchia GTS e la mia mai dimenticata V5 agp di parecchie FPS.
In effetti i driver facevano un po' cagare, mi ricordo artefatti evidenti in Alice, Rune e Giants.
IMHO, il TBR era ed è una tecnologia importante, troppo presto accantonata.
Alberto Falchi
12-11-2004, 12:39
Originariamente inviato da dataman
IMHO, il TBR era ed è una tecnologia importante, troppo presto accantonata.
COme dice Kirk, ha poco senso considerando il bus e la banda passante delle schede attuali. 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
yossarian
12-11-2004, 13:28
Originariamente inviato da Simon82
Direi che possiamo scrivere qui i commenti e le domande da porre a Vifani sull'ottima intervista fatta ai PR di Nvidia. :)
Vuoi sapere quale tecnologia introdurremo? (sorride) Non lo so quale tecnologia introdurremo, ma il futuro è lontano e nel futuro tutto è possibile. Io penso che sicuramente vedremo bus più ampi e più veloci seguendo l'attuale trend. Riguardo il tile based rendering non penso che ci siano mai stati prodotti di grande successo basati su questa tecnologia. Noi abbiamo valutato questa tecnologia pervenutaci dall'acquisizione del core assets di 3dfx Interactive con il nome Gigapixel. Esistono essenzialmente due benefici derivanti dall'uso di una simile architettura. Il primo riguarda la banda passante ed il quantitativo di memoria che è possibile risparmiare. Questo beneficio, tuttavia, è reso del tutto superfluo dalle le dimensioni dei bus di oggi uniti alla memoria dai costi sempre più bassi e abbordabili. Il secondo beneficio consiste essenzialmente nel non disegnare le superfici non visibili scartando i poligoni nascosti, il che è sicuramente molto interessante, ma richiede la realizzazione di un hardware troppo complesso affinché questa operazione possa essere svolta in fluidità anche con le scene ricche di poligoni
Questa un po' mi puzza.. :D;)
su questo punto sono in totale disaccordo con Kirk per due motivi:
1) ci sono evidenti casi in cui le attuali architetture sono bandwidth limited, come lo erano, nella precedente generazione.
Un esempio è dato dalle prestazioni della configurazione in SLI delle vga nVIDIA, che qualcuno ha postato qualche tempo fa; in qualche caso, lo SLI raggiungeva e superava il 100% delle prestazioni di una singola vga: poichè 2 chip o 2 vga gestite da uno o più controller non arriveranno mai ad uguagliare il doppio delle prestazioni di una singola vga dello stesso tipo in fatto di numero di operazioni per ciclo e, quindi, di potenza di calcolo (i controller richiedono lo "spreco" di qualche ciclo di clock extra), questo è un tipico caso in cui, se ciò succede, è solo perchè la singola vga risulta limitata in banda.
2) abbiamo l'esempio dell'HSR dell'R3x0 che, pur non basandosi su un TBR puro, come quello del Kyro, utilizza uno hyerarchical a 3 livelli, dividendo l'immagine in tile 4x4 al primo livello, per passare a 2x2 nel secondo e, infine, facendo un'analisi per pixel, tipo quella del Kyro2, qualora fosse necessario, al 3° livello. E' ovvio che, in caso di scansione front to back, sono rari i casi in cui è necessario fare ricorso all'analisi per pixel.
leoneazzurro
12-11-2004, 13:43
Una curiosità OT:
ma la citazione dal Macbeth? :)
yossarian
12-11-2004, 13:51
Originariamente inviato da leoneazzurro
Una curiosità OT:
ma la citazione dal Macbeth? :)
adoro Shakespeare e MacBeth è la mia seconda opera preferita dopo Amleto.
Questa citazione, in particolare, la trovo particolarmente emblematica, perchè rivolta a tutti coloro che, occupando una posizione di potere, pensano di essere inattaccabili. La frase, detta da una delle tre streghe che profetizzano a MacBeth un futuro da re, rassicura MacBeth, convinto che un bosco non si sarebbe mai mosso dal suo posto e che, quindi, la sua posizione di futuro re sarebbe stata inattaccabile. Invece succede l'imponderabile, quando l'esercito nemico, per avvicinarsi al castello di Dunsinane senza farsi notare, taglia parte del bosco di Birnan, nei pressi del castello, e lo usa per mimetizzarsi.
ciao, sono contento di sentirti
leoneazzurro
12-11-2004, 13:54
Ciao! :) Macbeth piace molto anche a me, pover'uomo, in fondo era tutta colpa della moglie :D
Hmmm... dovevamo continuare quella famosa discussione sui test sintetici PS in 3Dmark '05 e incrementi nei driver ATI.. ma quello era un altro forum.
Che dici, riposto laggiù e termino l'OT? :)
Ciao!
yossarian
12-11-2004, 13:56
Originariamente inviato da leoneazzurro
Ciao! :) Macbeth piace molto anche a me, pover'uomo, in fondo era tutta colpa della moglie :D
Hmmm... dovevamo continuare quella famosa discussione sui test sintetici PS in 3Dmark '05 e incrementi nei driver ATI.. ma quello era un altro forum.
Che dici, riposto laggiù e termino l'OT? :)
Ciao!
Sempre stato dell'idea che le donne sono pericolose :D
ok, anzi, se trovi i link ai test a cui fai riferimento, posta anche quelli che facciamo un'analisi "al volo"
;)
aggiungo a quanto detto sopra a proposito del TBR che, ai tempi del Kyro2 le pipeline erano molto meno complesse e con un minor numero di stadi; perciò una tecnica come quella del TBR poteva, in alcuni casi rallentare l'elaborazione e causare stalli della pipeline; adesso la situazione è molto diversa: le pipeline sono molto più lunghe e complesse e il possibile "rischio" connesso all'utilizzo del TBR è molto più ridotto
Originariamente inviato da yossarian
su questo punto sono in totale disaccordo con Kirk per due motivi:
1) ci sono evidenti casi in cui le attuali architetture sono bandwidth limited, come lo erano, nella precedente generazione.
Un esempio è dato dalle prestazioni della configurazione in SLI delle vga nVIDIA, che qualcuno ha postato qualche tempo fa; in qualche caso, lo SLI raggiungeva e superava il 100% delle prestazioni di una singola vga: poichè 2 chip o 2 vga gestite da uno o più controller non arriveranno mai ad uguagliare il doppio delle prestazioni di una singola vga dello stesso tipo in fatto di numero di operazioni per ciclo e, quindi, di potenza di calcolo (i controller richiedono lo "spreco" di qualche ciclo di clock extra), questo è un tipico caso in cui, se ciò succede, è solo perchè la singola vga risulta limitata in banda.
2) abbiamo l'esempio dell'HSR dell'R3x0 che, pur non basandosi su un TBR puro, come quello del Kyro, utilizza uno hyerarchical a 3 livelli, dividendo l'immagine in tile 4x4 al primo livello, per passare a 2x2 nel secondo e, infine, facendo un'analisi per pixel, tipo quella del Kyro2, qualora fosse necessario, al 3° livello. E' ovvio che, in caso di scansione front to back, sono rari i casi in cui è necessario fare ricorso all'analisi per pixel.
Ottima osservazione. ;)
leoneazzurro
12-11-2004, 13:57
Originariamente inviato da yossarian
ok, anzi, se trovi i link ai test a cui fai riferimento, posta anche quelli che facciamo un'analisi "al volo"
;)
Hmm.. bella domanda. Vabbè, se ci riesco entro oggi mi ritrovi di lì :)
Originariamente inviato da yossarian
su questo punto sono in totale disaccordo con Kirk per due motivi:
1) ci sono evidenti casi in cui le attuali architetture sono bandwidth limited, come lo erano, nella precedente generazione.
Un esempio è dato dalle prestazioni della configurazione in SLI delle vga nVIDIA, che qualcuno ha postato qualche tempo fa; in qualche caso, lo SLI raggiungeva e superava il 100% delle prestazioni di una singola vga: poichè 2 chip o 2 vga gestite da uno o più controller non arriveranno mai ad uguagliare il doppio delle prestazioni di una singola vga dello stesso tipo in fatto di numero di operazioni per ciclo e, quindi, di potenza di calcolo (i controller richiedono lo "spreco" di qualche ciclo di clock extra), questo è un tipico caso in cui, se ciò succede, è solo perchè la singola vga risulta limitata in banda.
2) abbiamo l'esempio dell'HSR dell'R3x0 che, pur non basandosi su un TBR puro, come quello del Kyro, utilizza uno hyerarchical a 3 livelli, dividendo l'immagine in tile 4x4 al primo livello, per passare a 2x2 nel secondo e, infine, facendo un'analisi per pixel, tipo quella del Kyro2, qualora fosse necessario, al 3° livello. E' ovvio che, in caso di scansione front to back, sono rari i casi in cui è necessario fare ricorso all'analisi per pixel.
Concordo pienamente.
Pk77
Dark Schneider
12-11-2004, 14:48
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.. ;):D
In realtà se ti sente fek parlare bene del Kiro II... :asd:
yossarian
12-11-2004, 15:22
Originariamente inviato da Dark Schneider
In realtà se ti sente fek parlare bene del Kiro II... :asd:
fek ha ragione a parlare male del Kyro2, poichè dal suo punto di vista, di sviluppatore di SW, presentava molti problemi.
Però aveva delle caratteristiche HW decisamente interessanti e all'avanguardia, soprattutto in relazione al periodo in cui è uscito (ricordo che la GF2 non utilizzava affatto algoritmi di HSR e gli stess hyper-z e hyper-z 2 dell'R100 e dell'R200 e la lightspeed architecture dell'NV2x non erano efficaci come il TBR.
Certo, si trattava di una tecnica ancora "acerba" e che andava affinata; però da qui a dire che non serve, perchè le attuali vga non soffrono di limiti in banda, ce ne corre e parecchio (anche perchè non è assolutamente vero, tanto che sull'R420 hanno aumentato a 560 Mhz la frequenza del memory bus controller, rispetto ai 360 Mhz dell'R3x0, proprio per cercare di minimizzare i limiti derivanti da una insufficiente benda passante).
Alberto Falchi
12-11-2004, 15:25
Originariamente inviato da yossarian
fek ha ragione a parlare male del Kyro2, poichè dal suo punto di vista, di sviluppatore di SW, presentava molti problemi.
Però aveva delle caratteristiche HW decisamente interessanti e all'avanguardia, soprattutto in relazione al periodo in cui è uscito (ricordo che la GF2 non utilizzava affatto algoritmi di HSR e gli stess hyper-z e hyper-z 2 dell'R100 e dell'R200 e la lightspeed architecture dell'NV2x non erano efficaci come il TBR.
Certo, si trattava di una tecnica ancora "acerba" e che andava affinata; però da qui a dire che non serve, perchè le attuali vga non soffrono di limiti in banda, ce ne corre e parecchio (anche perchè non è assolutamente vero, tanto che sull'R420 hanno aumentato a 560 Mhz la frequenza del memory bus controller, rispetto ai 360 Mhz dell'R3x0, proprio per cercare di minimizzare i limiti derivanti da una insufficiente benda passante).
Bisogna anche vedere a cosa sono dovuti questi problemi di banda. Si tratta di limiti dovuti al passaggio delle texture e alla loro elaborazione, o sono dovuti all'evelato numero di poligoni? Siamo sicuri che sia proprio la coimplessità poligonale a causare queste saturazioni? Io non ne sarei così certo. Del resto, a sentire Carmack, anche se nVidia attiverà Ultrashadow nei driver, il suo engine non ne otterà grandi benefici. Eppure le ombre di D3 sono trattate come poligoni.
Pape
Originariamente inviato da Dark Schneider
In realtà se ti sente fek parlare bene del Kiro II... :asd:
Fattosta che all'utente finale, la GeForce2 GTS da 1.300.000 lire pareva in ridotta... :sofico:
yossarian
12-11-2004, 15:52
Originariamente inviato da GMCPape
Bisogna anche vedere a cosa sono dovuti questi problemi di banda. Si tratta di limiti dovuti al passaggio delle texture e alla loro elaborazione, o sono dovuti all'evelato numero di poligoni? Siamo sicuri che sia proprio la coimplessità poligonale a causare queste saturazioni? Io non ne sarei così certo. Del resto, a sentire Carmack, anche se nVidia attiverà Ultrashadow nei driver, il suo engine non ne otterà grandi benefici. Eppure le ombre di D3 sono trattate come poligoni.
Pape
il TBR prescinde dalla complessità poligonale, poichè basa l'analisi sul singolo pixel (e sulla valutazione di tutti i valori presenti nello z-buffer, le cui coordinate x e y coincidano); allo stato attuale, non esistono algoritmi di HSR basati sui poligono (sarebbero i migliori in assoluto, in termini di resa, ma sono anche i più difficili da implementare su un chip senza alterarne la logica di funzionamento). L'ultrashadow è una tecnica che gestisce le ombre come se fossero contenute in una sorta di volume di vista canonico, eseguendo operazioni di backface culling e facendo uso di uno shadow buffer come depth; si tratta di una tecnica che rimuove euristicamente le superfici esterne al volume di vista, però no nè una vera tecnica di HSR, paragonabile al TBR o all'hyper-z o alla lightspeed architecture.
Una limitazione in banda dovuta ad un ampio uso di texture può comunque essere limitata se si limita il fenomeno dell'overdraw (che era il responsabile della litazione in banda anche nelle passate generazioni), comunque sempre presente nei chip che non facciano uso di tecniche di hsr con scansione effettuata per pixel. Tieni presente, inoltre, che una tecnica tbr based permette di svolgere operazioni come lo z-test e il texture blending direttamente on chip, senza ulteriori accessi alla ram video e operando alla display resolution (mentre invece un hsr non basato su una tecnica tipo tbr effettua lo z-test ad una risoluzione inferiore, per poi fare un successivo upscaling con conseguente e inevitabile perdita di dati relativi ad alcuni poligoni nascosti, come avviene, ad esempio, con l'R200).
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.
I Bitboys :D
Che fine ha fatto il glaze 3d? :O ;)
Pk77
yossarian
13-11-2004, 01:12
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.
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).
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 :D
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... ;):p
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
13-11-2004, 11:12
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.. ;):D
Quto in pieno
:O
BTinside
13-11-2004, 11:15
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
13-11-2004, 11:21
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
13-11-2004, 11:42
Originariamente inviato da Simon82
Ottima osservazione. ;)
Osservazione da convertire in domanda per l'intervista a Kirk
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
13-11-2004, 11:58
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
:D )
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
:D )
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.
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... ;):p
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
13-11-2004, 12:18
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... ;):p
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
13-11-2004, 12:31
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
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
13-11-2004, 12:39
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;)
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
13-11-2004, 12:45
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
;)
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?
:D
Originariamente inviato da Vifani
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?
Esattamente quello che pensavo l'annoscorso mentre si parlava di un possibile PowerVR5 con Pixel Shader 3.0 :D
Comunque stavo pensando... il Kyro 2 andava in crisi se c'erano troppi triangoli per tile, in particolare se erano > 512, cioè più di uno per pixel. Guardando le specifiche del Unreal Engine 3 si legge che arriva a 1.2 milioni di triangoli per scena, e a 1024x768 significa in medi più di uno per pixel... Si deve complicare la circuiteria interna per gestire il culling di un maggior numero di triangoli (mantenendo buona la tecnologia degli Infinite Planes così come è descritta da Beyond 3d).
La soluzione ibrida di yossarian mi sembra molto più interessante, ma da quello che so non dovrebbe essere molto diversa da quella che Ati sfrutta con la sua HyperZ HD.
BTinside
13-11-2004, 15:19
Originariamente inviato da Spytek
Parli per caso della TT, o S3?
:D
dai raga basta OT,
Simon sposta nella sezione giusta:asd:
Scherzo eh...
il motore sempre volkswagen è quindi...
:D
BTinside
13-11-2004, 15:23
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
:D )
Mi quoto perchè nessuno mi ha ancora risposto a questa domanda,
il doppio fill rate dell'ultrashadow di NV40 , non viene compensato da R420 con l'HyperZ??? Altrimenti come fa una X800XT PE a competere e spesso superare la 6800Ultra? Non ditemi che questo vantaggio sia solo merito delle frequenze più alte di R420
Originariamente inviato da BTinside
Mi quoto perchè nessuno mi ha ancora risposto a questa domanda,
il doppio fill rate dell'ultrashadow di NV40 , non viene compensato da R420 con l'HyperZ??? Altrimenti come fa una X800XT PE a competere e spesso superare la 6800Ultra? Non ditemi che questo vantaggio sia solo merito delle frequenze più alte di R420
Ero convinto di averti risposto :confused: sto invecchiando...
Il fill rate doppio di NV40 rispetto a R420 è presente nel rendering sul solo z-buffer o sul solo stencil buffer. Queste operazioni non sono molto frequenti e vengono fatte essenzialmente per realizzare le stencil shadow in Doom III.
Quindi NV40 ha il doppio del fill rate di R420 limitatamente a quella situazione. Nella più diffusa e classica operazione di rendering contemporaneamente nello z-buffer e nello stencil buffer le due architettura si comportano allo stesso modo.
Hyper-Z HD racchiude tecniche di compressione del colore e dei dati relativi allo z-buffer oltre a tecniche per la rimozione di superfici nascoste. Il rendering fatto per le ombre di Doom III non beneficia + di tanto di queste tecniche. Solo nell'ultima passata in cui si scrive nel frame buffer si vedono i miglioramenti dovuti all'Hyper-Z HD.
BTinside
13-11-2004, 17:12
Originariamente inviato da Vifani
Ero convinto di averti risposto :confused: sto invecchiando...
Il fill rate doppio di NV40 rispetto a R420 è presente nel rendering sul solo z-buffer o sul solo stencil buffer. Queste operazioni non sono molto frequenti e vengono fatte essenzialmente per realizzare le stencil shadow in Doom III.
Quindi NV40 ha il doppio del fill rate di R420 limitatamente a quella situazione. Nella più diffusa e classica operazione di rendering contemporaneamente nello z-buffer e nello stencil buffer le due architettura si comportano allo stesso modo.
Hyper-Z HD racchiude tecniche di compressione del colore e dei dati relativi allo z-buffer oltre a tecniche per la rimozione di superfici nascoste. Il rendering fatto per le ombre di Doom III non beneficia + di tanto di queste tecniche. Solo nell'ultima passata in cui si scrive nel frame buffer si vedono i miglioramenti dovuti all'Hyper-Z HD.
Anche NV40 possiede una tecnica di compressione del colore o sbaglio?
Alberto Falchi
13-11-2004, 18:23
Originariamente inviato da BTinside
Secondo me non ne hanno proprio la voglia di produrre una soluzione basata su tbr
Il "non avere voglia" non esiste in ambito commerciale. Se non lo si fa, è perché non conviene economicamente, perché qualcuno ha già il brevetto (non è questo caso, visto che le tecnologia 3dfx sono di nVidia) o perché il gioco non vale la candela. Quando cì'è in atto una simile guerra di prodotto fra i due grossi concorrenti, "non ho voglia" è una risposta inacettabile, olter che stupida ^_^.
Pape
Originariamente inviato da BTinside
Anche NV40 possiede una tecnica di compressione del colore o sbaglio?
Si certo.
yossarian
13-11-2004, 22:38
Originariamente inviato da Banus
La soluzione ibrida di yossarian mi sembra molto più interessante, ma da quello che so non dovrebbe essere molto diversa da quella che Ati sfrutta con la sua HyperZ HD.
in effetti non è molto differente; in questo caso, una soluzione "ibrida" è l'unico mezzo per non stravolgere la logica del chip e per ovviare ai problemi di spazio interno.
Il Kyro, infatti, è un chip molto semplice, con un'architettura 2x1 e con una sola alu per pipeline (come, d'altra parte, anche NV15, NV2x, R100 e R200), operante a 32 bit (8 per canale) in virgola fissa. Realizzato a 0,18 u ha, perciò, un notevole spazio interno per allocare buffer di varia natura e, proprio grazie a questa caratteristica, presenta soluzioni molto moderne per l'epoca in cui è stato progettato (la possibilità di applicare 8 texel per pixel per single pass, ad esempio pur disponendo di 1 sola tmu).
Nel caso dell'R300, invece, la situazione è molto diversa: elevato parallelismo, elevato numero di transistor, architettura molto complessa e poco spazio interno al chip. Perciò i registri adoperati come tile buffer (l'R300 ne utilizza 3 poichè adotta un algoritmo a 3 livelli) sono di dimensioni estremamente ridotte (4x4, 2x2 e 1) rispetto a quello del Kyro2 (16x32), però la necessità di ricorrere alla display resolution è ridotta al minimo: E' ovvio che il tbr si basa su un principio diverso nella gestione del rendering dell'immagine, però anche l'algortimo di ATi prevede la completa eliminazione di tutte le superfici nascoste e risulta persino più veloce del tbr nel caso di scansione front to back.
Originariamente inviato da GMCPape
Il "non avere voglia" non esiste in ambito commerciale. Se non lo si fa, è perché non conviene economicamente, perché qualcuno ha già il brevetto (non è questo caso, visto che le tecnologia 3dfx sono di nVidia) o perché il gioco non vale la candela. Quando cì'è in atto una simile guerra di prodotto fra i due grossi concorrenti, "non ho voglia" è una risposta inacettabile, olter che stupida ^_^.
Pape
Ciao,
non sono d'accordo.
A questi livelli le aziende rivali si studiano a vicenda sono in grado di capire abbastanza precisamente cosa farà l'avversario e/o anche come lo farà.
La tecnologia TBR è davvero fantastica (sebbene affetta da diversi problemi, non ultimo quello di doversi scontrare con delle API pensate per operatori di rendering immediato) e dire che non conviene usala perchè tanto si può aumentare il bus e/o la frequenza mi sembra un tantino fuori luogo. Immagina un chip della complessita (e con la potenza bruta) di NV40 accoppiato alla tecnologia TBR: se un KyroII da 350Mp/Mt per secondo teneva testa a una GF2GTS da 800Mp/1600Mt per secondo, chissa cosa potrebbe fare questo ipotetico chip...
Un'ultima cosa: la tecnologia UltraShadowII non ha nulla a che fare con il TBR. E' vero che in ultima analisi lo scopo di queste tecnologie è quello di risparmiare calcoli non processando ciò che non serve, ma il modo in cui lo fanno e i principi a cui si appoggiano (nonchè la loro efficenza) sono molto differenti...
X Yossarian: così com'è strutturato l'R300 non ha bisogno di tenere nessuna triangle list o in qualche caso è necessario anche per lui ricorrere a queste famose liste?
CIAO! :)
Originariamente inviato da yossarian
Realizzato a 0,18 u ha, perciò, un notevole spazio interno per allocare buffer di varia natura e, proprio grazie a questa caratteristica, presenta soluzioni molto moderne per l'epoca in cui è stato progettato (la possibilità di applicare 8 texel per pixel per single pass, ad esempio pur disponendo di 1 sola tmu).
Non riesco a capire la relazione fra teconlogia 0.18 e spazio per i buffer... perchè adesso i chip sono molto più complessi e rimane poco spazio per buffer di vario tipo?
E' ovvio che il tbr si basa su un principio diverso nella gestione del rendering dell'immagine, però anche l'algortimo di ATi prevede la completa eliminazione di tutte le superfici nascoste e risulta persino più veloce del tbr nel caso di scansione front to back.
Che se non vado errato è l'ordine di rendering che solitamente si sceglie per avere una corretta gestione delle trasparenze mediante alpha blending.
Un dubbio.. il Kyro doveva parte della sua efficenza alla possibilità di operare localmente su una tile tranne nella fase di texture fetch (se non ricordo male), e questo significava anche risparmio di banda.
Le attuali schede hanno per quello che si sa una specie di cache interna oppure accedono sempre direttamente al framebuffer?
Originariamente inviato da shodan
La tecnologia TBR è davvero fantastica (sebbene affetta da diversi problemi, non ultimo quello di doversi scontrare con delle API pensate per operatori di rendering immediato) e dire che non conviene usala perchè tanto si può aumentare il bus e/o la frequenza mi sembra un tantino fuori luogo.
C'è anche da stabilire in quali occasioni porti a un grosso miglioramento. Se le Ati riescono con un numero relativamente ridotto di calcoli a scartare la quasi totalità dei pixel nascosti non è difficile capire che avrebbero prestazioni quasi allineate con un ipotetico Kyro5. Inoltre con l'aumentare del numero dei poligoni potrebbero diventare più efficienti altre strade. Se si impone l'uso su larga scala delle displacement map con le WGF potrebbe rivelarsi più efficiente, mettiamo, un'architettura tipo Reyes.
X Yossarian: così com'è strutturato l'R300 non ha bisogno di tenere nessuna triangle list o in qualche caso è necessario anche per lui ricorrere a queste famose liste?
Mi permetto di rispondere :p
http://www.xbitlabs.com/articles/video/display/r420_9.html
Oltre allo Z-buffer c'è un "Tile Z buffer" che tiene traccia del valore Z più alto della tile.
Prende un singolo poligono e lo divide in blocchi 8x8, testando i valori Z agli angoli. Se sono tutti superiori al valore memorizzato nel "Tile Z buffer" il blocco viene scartato, altrimenti raffina a blocchi di 4x4, e se necessario, a 2x2, ovvero a livello di pixel.
Originariamente inviato da Banus
C'è anche da stabilire in quali occasioni porti a un grosso miglioramento. Se le Ati riescono con un numero relativamente ridotto di calcoli a scartare la quasi totalità dei pixel nascosti non è difficile capire che avrebbero prestazioni quasi allineate con un ipotetico Kyro5. Inoltre con l'aumentare del numero dei poligoni potrebbero diventare più efficienti altre strade. Se si impone l'uso su larga scala delle displacement map con le WGF potrebbe rivelarsi più efficiente, mettiamo, un'architettura tipo Reyes.
Mi permetto di rispondere :p
http://www.xbitlabs.com/articles/video/display/r420_9.html
Oltre allo Z-buffer c'è un "Tile Z buffer" che tiene traccia del valore Z più alto della tile.
Prende un singolo poligono e lo divide in blocchi 8x8, testando i valori Z agli angoli. Se sono tutti superiori al valore memorizzato nel "Tile Z buffer" il blocco viene scartato, altrimenti raffina a blocchi di 4x4, e se necessario, a 2x2, ovvero a livello di pixel.
Ciao, grazie per la risposta! ;)
Avevo letto anche io qualcosa su come funziona l'HSR sull'R300 ed ero a conoscenza di questa "tile z buffer", però non ho capito se, per operare su una tile, deve prima generare la tringle list relativa (come nei chip Kyro).
CIAO! :)
BTinside
14-11-2004, 01:50
Originariamente inviato da GMCPape
Il "non avere voglia" non esiste in ambito commerciale. Se non lo si fa, è perché non conviene economicamente, perché qualcuno ha già il brevetto (non è questo caso, visto che le tecnologia 3dfx sono di nVidia) o perché il gioco non vale la candela. Quando cì'è in atto una simile guerra di prodotto fra i due grossi concorrenti, "non ho voglia" è una risposta inacettabile, olter che stupida ^_^.
Pape
Infatti era un "non ne hanno la voglia" generico:
è implicito e può significare tante cose
-non ne hanno la voglia...........perchè risulterebbe compromettente economicamente
yossarian
14-11-2004, 03:32
Originariamente inviato da shodan
X Yossarian: così com'è strutturato l'R300 non ha bisogno di tenere nessuna triangle list o in qualche caso è necessario anche per lui ricorrere a queste famose liste?
CIAO! :)
l'R300 utilizza una suddivisione dell'immagine in tile 4x4; ogni tile è composta di blocchi 2x2 e di ogni blocco si prende il valore maggiore (pivot) e si inserisce in un'altra lista; questa seconda è composta da blocchi 2x2 che contengono tutti i valori pivot suddetti; infine, tra i 4 valori di questa seconda tessera, si sceglie il valore maggiore in assoluto (che è anche il valore più grande della tessera di partenza 4x4); questo valore rappresenta il valore z, relativo a quella tessera, più lontano dall'osservatore. Quindi, nel caso dell'R300, abbiamo più liste che vengono caricate on chip. Quando si effettua il primo test con una texturre relativa a pixel aventi le stesse coordinate x e y di una data tessera 4x4, si confrontano i valori z della texture da applicare con quello che potremmo definire "pivot dei pivot". Se il valore z della nuova tessera è maggiore di quello di riferimento, la texture viene scartata, ina caso contrario si passa a confrontarla con i valori della tile 2x2; in caso di ulteriore dubbio si passa all'ultimo confronto, quello con la tessera campione 4x4, presa alla display resolution. Quest'ultimo confronto permette di fugare ogni ulteriore dubbio e "rigettare" o accettare la texture o parte di essa. Eseguendo una scansione front to back, poichè i primi valori ad essere caricati on chip sono quelli relativi ai layer più vicini all'osservatore, è facile prevedere che la maggior parte delle tile esaminate in seguito saranno "rigettate" già nella prima fase dell'analisi (questo permette di velocizzare molto il processo).
Da puntualizzare una cosa; a partire dalla generazione DX7 (l'R100 ad esempio) i chip non eseguono più immediate rendering (tranne, la GF2) ma hanno un algoritmo per la rimozione delle superfici nascoste. Il problema è che non tutti eseguono, newi casi dubbi, il test alla display resolution (come invece fa l'R300). Questo non permette di eliminare completamente tutti i poligono nascosti, dando luogo in alcuni casi, al fenomeno dell'overdraw che diventa tanto più grave quanto più alta è la risoluzione, maggiore il numero di poligoni e a filtri attivi.
Il TBR, invece, utilizza solo la display resolution (cioè la risoluzione reale a cui si lavora) per effettuare il test; questo permette un'analisi accurata pixel per pixel.
yossarian
14-11-2004, 03:35
Originariamente inviato da Banus
Le attuali schede hanno per quello che si sa una specie di cache interna oppure accedono sempre direttamente al framebuffer?
no, hanno delle cache interne, però, a parte il caso dell'R300 e, suppongo, dell'R420, non sono sicuro che gli altri effettuino test pre rendering alla display resolution; se così fosse, il fenomeno dell'overdraw non sarebbe del tutto eliminato, perchè l'analisi sullo z-buffer della ram video viene fatta in fase di post processing, ovvero a rendering effettuato.
yossarian
14-11-2004, 03:47
Originariamente inviato da Banus
Non riesco a capire la relazione fra teconlogia 0.18 e spazio per i buffer... perchè adesso i chip sono molto più complessi e rimane poco spazio per buffer di vario tipo?
il Kyro, ha un'architettura molto semplice: è una 2x1, con una sola alu fx8 per pipeline; questo, su un chip a 0,18 u, permette di ricavare molto spazio per utilizzare cache interne per svolgere varie funzioni (da qui la possibilità di fare multitexturing a 8 layer in single pass e di utilizzare tile di grandi dimensioni (16x32) da caricare on chip).
Al paragone, lo stesso NV15, con la sua 4x2 (e 1 alu fx4/fx8 per pipeline) o l'R100 con la 2x3 e 1 alu fx8 per pipeline, sono molto più complessi; per non parlare dell'R300, realizzato a 0,15, ma con architettura 8x1, con 2 fpu per pipe, 4 unità VS, ecc. ecc.: in un chip così complicato, che già deve implementare il numero minimo di registri per essere compatibile con il tipo di API per cui è progettato (DX9 in questo caso), non c'è molto spazio per allocare una ulteriore cache di grandi dimensioni (tipo quella del Kyro) per fare TBR (ATi, sull'R300, ha dovuto "risparmiare", cercando di ridurre al minimo la complessità dei circuiti che si occupano del LoD e dell'AF), facendo ricorso al numero minimo di bit consentiti per avere una corretta visualizzazione. Questo è il motivo per cui le dimensioni della tile alla display resolution sono state scelte di soli 4x4 pixel (R200, ad esempio, l'aveva 8x8, però on chip era caricata solo una tile a "risoluzione" ridotta, delle dimensioni di 2x2 pixel scelti col criterio dei pivot sui 4 gruppi 4x4 costituenti la tessera di partenza: infatti R200 non effettua early z-test alla display resolution ed è affetto dal fenomeno dell'overdraw).
Originariamente inviato da yossarian
il Kyro, ha un'architettura molto semplice: è una 2x1, con una sola alu fx8 per pipeline; questo, su un chip a 0,18 u, permette di ricavare molto spazio per utilizzare cache interne per svolgere varie funzioni
Capito, è un semplice problema di transistor budget :)
A proposito, mi chiedo se l'attuale tendenza a inserire molte funzioni complesse on chip sia conveniente, piuttosto che replicare molte volte le operazioni più frequenti, essenzialmente MAC e divisioni (per il calcolo delle coordinate texture), più o meno come nell'Emotion Engine, che infatti ha un numero di transistor molto ridotto (10 milioni). Ovvio che un'architettura simile significa la necessità di un buon lavoro a livello di driver ;)
Questo è il motivo per cui le dimensioni della tile alla display resolution sono state scelte di soli 4x4 pixel (R200, ad esempio, l'aveva 8x8, però on chip era caricata solo una tile a "risoluzione" ridotta, delle dimensioni di 2x2 pixel scelti col criterio dei pivot sui 4 gruppi 4x4 costituenti la tessera di partenza: infatti R200 non effettua early z-test alla display resolution ed è affetto dal fenomeno dell'overdraw).
Su X-bit labs leggo che R420 esegue il test su blocchi di 8x8 pixel e nei casi dubbi scende fino a due livelli. Infatti si parla di Hierarchical Z buffer a 3 livelli. I blocchi 2x2 richiedono il calcolo dei valori di Z di tutti i pixel e quindi si ricade nell'Early Z:
When the polygon to be processed arrives, HyperZ HD splits it into 8x8 pixel blocks and finds minimal Z value for 64 pixels of each block: it will evidently be found on one of the corner pixels, that is why it is more than enough to check only the 4 Z values in the corners of the block.
yossarian
14-11-2004, 11:42
Originariamente inviato da Banus
Capito, è un semplice problema di transistor budget :)
A proposito, mi chiedo se l'attuale tendenza a inserire molte funzioni complesse on chip sia conveniente, piuttosto che replicare molte volte le operazioni più frequenti, essenzialmente MAC e divisioni (per il calcolo delle coordinate texture), più o meno come nell'Emotion Engine, che infatti ha un numero di transistor molto ridotto (10 milioni). Ovvio che un'architettura simile significa la necessità di un buon lavoro a livello di driver ;)
l'attuale tendenza sta iniziando a mostrare la corda; riprova ne è il fatto della ricerca di soluzioni multi-vga, come lo SLI di nVIDIA.
E' molto probabile che la generazione prossima (R520 e NV50?) sia l'ultima con questo tipo di architettura; in seguito si dovrebbe migrare verso architetture con VS e PS unificati, il che sta a significare utilizzo di circuiti in grado di eseguire le operazioni di base comuni e renderle disponibili per entrambi i tipi di unità di calcolo complesse. Risultato: maggior parallelismo, drastica riduzione dei tempi morti nelle elaborazioni (periodi in cui uno dei due blocchi è inattivo, in attesa che l'altro termini i suoi calcoli) e, soprattutto, notevole risparmio di transistor (molte unità di calcolo elementari, attualmente contenute sia nei ps che nei vs, non saranno replicate ma saranno uniche e i risultati da esse forniti saranno a disposizione di chi ne avrà bisogno in quel momento).
Originariamente inviato da Banus
Su X-bit labs leggo che R420 esegue il test su blocchi di 8x8 pixel e nei casi dubbi scende fino a due livelli. Infatti si parla di Hierarchical Z buffer a 3 livelli. I blocchi 2x2 richiedono il calcolo dei valori di Z di tutti i pixel e quindi si ricade nell'Early Z:
si, ho letto l'articolo di x-bit; c'è da vedere se la matrice 8x8 è stato possibile caricarla "on chip), oppure se è stato possibile "imbarcare" solo la 4x4; in questo secondo caso, il chip è in grado di effettuare uno z-test a quella che è definita, in gergo "una risoluzione inferiore rispetto alla display resolution" e rappresenterebbe un passo indietro rispetto all'algoritmo implementato sull'R300 in fatto di risparmio di banda passante (anche se è pprobabile che, in termini di velocità, recupari grazie al fatto che riesce ad eliminare, in molti casi, in prima analisi, blocchi interi di 64 pixel contro i 16 dell'R300). Nel caso, invece, si sia trovato spazio per caricare la tile 8x8, allora l'early z-test dell'R420 è più veloce di quello dell'R300 a parità di efficacia.
Originariamente inviato da yossarian
in seguito si dovrebbe migrare verso architetture con VS e PS unificati, il che sta a significare utilizzo di circuiti in grado di eseguire le operazioni di base comuni e renderle disponibili per entrambi i tipi di unità di calcolo complesse. Risultato: maggior parallelismo, drastica riduzione dei tempi morti nelle elaborazioni (periodi in cui uno dei due blocchi è inattivo, in attesa che l'altro termini i suoi calcoli) e, soprattutto, notevole risparmio di transistor (molte unità di calcolo elementari, attualmente contenute sia nei ps che nei vs, non saranno replicate ma saranno uniche e i risultati da esse forniti saranno a disposizione di chi ne avrà bisogno in quel momento).
Di un'architettura analoga si parla del futuro Cell, di cui per ora esistono solo rumors e supposizioni basate su alcuni brevetti depositati da Sony. In particolare si parla di 8 unità di elaborazione
che a loro volta coordinano ciascuna 4 o 8 unità SIMD.
Anche le voci riguardo R500 parlano di 48 ALU dotate di un'unità vettoriale. A quanto pare è la soluzione più efficiente ;)
si, ho letto l'articolo di x-bit; c'è da vedere se la matrice 8x8 è stato possibile caricarla "on chip), oppure se è stato possibile "imbarcare" solo la 4x4; in questo secondo caso, il chip è in grado di effettuare uno z-test a quella che è definita, in gergo "una risoluzione inferiore rispetto alla display resolution" e rappresenterebbe un passo indietro rispetto all'algoritmo implementato sull'R300 in fatto di risparmio di banda passante (anche se è pprobabile che, in termini di velocità, recupari grazie al fatto che riesce ad eliminare, in molti casi, in prima analisi, blocchi interi di 64 pixel contro i 16 dell'R300). Nel caso, invece, si sia trovato spazio per caricare la tile 8x8, allora l'early z-test dell'R420 è più veloce di quello dell'R300 a parità di efficacia.
Sono dell'idea che l'algoritmo usato nei due chip sia fondamentalmente lo stesso, infatti sul sito della Ati riguardo a R300 usa la stessa definizione:
http://www.ati.com/products/radeon9700/radeon9700pro/specs.html
In che senso si avrebbe risparmio di banda? andando a leggere/ scrivere solo blocchi di 4 pixel sul framebuffer non si ha un guadagno di banda? Anche copiando tutto il blocco 8x8 arrivati a livello pixel si deve eseguire uno Z-test classico perchè comunque non ci sono più blocchi da rigettare/raffinare. E sarebbe necessario copiare poi il blocco elaborato nel framebuffer. Questo andando a logica, dimmi se sto sbagliando qualcosa :p
yossarian
14-11-2004, 13:20
Originariamente inviato da Banus
Di un'architettura analoga si parla del futuro Cell, di cui per ora esistono solo rumors e supposizioni basate su alcuni brevetti depositati da Sony. In particolare si parla di 8 unità di elaborazione
che a loro volta coordinano ciascuna 4 o 8 unità SIMD.
Anche le voci riguardo R500 parlano di 48 ALU dotate di un'unità vettoriale. A quanto pare è la soluzione più efficiente ;)
Si, R500 dovrebbe avere un'architettura con 48 alu polifunzionali più 16 texture unit; una società consociata di ATi (intrinsity) sta da tempo conducendo esperimenti su processori con unità SIMD, enormi cache interne e frequenze molto elevate (raggiungibili grazie alla semplicità del chip).
Originariamente inviato da Banus
Sono dell'idea che l'algoritmo usato nei due chip sia fondamentalmente lo stesso, infatti sul sito della Ati riguardo a R300 usa la stessa definizione:
http://www.ati.com/products/radeon9700/radeon9700pro/specs.html
In che senso si avrebbe risparmio di banda? andando a leggere/ scrivere solo blocchi di 4 pixel sul framebuffer non si ha un guadagno di banda? Anche copiando tutto il blocco 8x8 arrivati a livello pixel si deve eseguire uno Z-test classico perchè comunque non ci sono più blocchi da rigettare/raffinare. E sarebbe necessario copiare poi il blocco elaborato nel framebuffer. Questo andando a logica, dimmi se sto sbagliando qualcosa :p
anch'io sono della stessa idea, anzi credo proprio che sia esattamente lo stesso identico; questo perchè i risultati dei test di efficienza dei due algoritmi danno valori praticamente allineati.
Ho parlato di risparmio di banda perchè, nel caso la tile 8x8, quella alla display resolution, tanto per intenderci, non è caricata on chip, la sua analisi avviene in post processing, quando è già stata effettuata l'operazione di texturing; questo significa che è sempre presente il rischio di overdraw. In caso contrario, lo z-test preventivo rimuove tutti i poligoni, non si ha overdraw e lo z-test effettuato in post processing (perchè in ogni caso si effettua un doppio controllo, prima e dopo le operazioni di texturing), ha solo il compito di mero controllo
Originariamente inviato da yossarian
Si, R500 dovrebbe avere un'architettura con 48 alu polifunzionali più 16 texture unit; una società consociata di ATi (intrinsity) sta da tempo conducendo esperimenti su processori con unità SIMD, enormi cache interne e frequenze molto elevate (raggiungibili grazie alla semplicità del chip).
Questa cosa non la sapevo... :D
Comunque con unità semplici non ci sono problemi per la propagazione dei segnali nel chip e sulla lunghezza delle interconnessioni, che pongono un limite superiore al clock raggiungibile...
C'è da considerare che la potenza delle GPU attuali è limitata dalla frequenza relativamente bassa. Un ipotetico NV40 a 2GHz avrebbe l'impressionante potenza teorica di 128 Gflops a 32 bit.
Ho parlato di risparmio di banda perchè, nel caso la tile 8x8, quella alla display resolution, tanto per intenderci, non è caricata on chip, la sua analisi avviene in post processing, quando è già stata effettuata l'operazione di texturing; questo significa che è sempre presente il rischio di overdraw. In caso contrario, lo z-test preventivo rimuove tutti i poligoni, non si ha overdraw e lo z-test effettuato in post processing (perchè in ogni caso si effettua un doppio controllo, prima e dopo le operazioni di texturing), ha solo il compito di mero controllo
Lo Z-test preventivo non può essere eseguito anche prelevando i pixel direttamente dallo Z-buffer senza caricare in memoria tutto il blocco? in ogni modo il test sui blocchi avviene sul "Tile Z Buffer", e richiede nel caso di decisione a livello 2x2 pixel, 4x4 valori. Eventuali pixel non scartati saranno rimossi dallo Z-test preventivo, senza sprecare cicli di shading/texturing.
Comunque questo significa fare 2 accessi successivi alla memoria, prima sullo Z buffer e poi sul texture buffer.
Una cosa che non stavo assolutamente considerando:qui (http://www.firingsquad.com/guides/occlusionculling/page2.asp) viene sottolineato il fatto che l'efficacia di Hierarchical Z e Early Z test dipende strettamente dall'ordine dei poligoni. Se l'ordine è back to front si ottiene overdraw massimo con in più l'overhead dei test aggiuntivi. Al contrario il Kyro eseguendo un'ordinamento di tutti i poligoni della tile ha in ogni caso overdraw nullo.
yossarian
14-11-2004, 14:35
Originariamente inviato da Banus
Questa cosa non la sapevo... :D
Comunque con unità semplici non ci sono problemi per la propagazione dei segnali nel chip e sulla lunghezza delle interconnessioni, che pongono un limite superiore al clock raggiungibile...
C'è da considerare che la potenza delle GPU attuali è limitata dalla frequenza relativamente bassa. Un ipotetico NV40 a 2GHz avrebbe l'impressionante potenza teorica di 128 Gflops a 32 bit.
problemi sulla propagazione dei segnali no; sulla lunghezza e sulla quantità (e di conseguenza sulla tipologia) delle interconnessioni, invece, si (esistono diverse soluzioni al riguardo.
E oltre a questo, ci sono anche altri problemi da risolvere (che sarebbe un po' lungo da elencare). Però si tratta, in ogni caso, di architetture più efficienti e, soprattutto, che possono garantire un parallelismo notevolmente maggiore (necessario nelle applicazioni video, coma ha giustamente sottolineato Kirk).
Originariamente inviato da Banus
.
Lo Z-test preventivo non può essere eseguito anche prelevando i pixel direttamente dallo Z-buffer senza caricare in memoria tutto il blocco? in ogni modo il test sui blocchi avviene sul "Tile Z Buffer", e richiede nel caso di decisione a livello 2x2 pixel, 4x4 valori. Eventuali pixel non scartati saranno rimossi dallo Z-test preventivo, senza sprecare cicli di shading/texturing.
Comunque questo significa fare 2 accessi successivi alla memoria, prima sullo Z buffer e poi sul texture buffer.
un'analisi pixel per pixel nello z-buffer canonico imporrebbe continui accessi alla ram video (cosa assolutamente da evitare per non vedere decadere le prestazioni, poichè si tratta di una delle operazioni più "lente" di un chip grafico 8l'elevato parallelismo serve proprio a processare il maggior numero di pixel per pass, evitando, il più possibile, accessi alla ram video).
Originariamente inviato da Banus
Una cosa che non stavo assolutamente considerando:qui (http://www.firingsquad.com/guides/occlusionculling/page2.asp) viene sottolineato il fatto che l'efficacia di Hierarchical Z e Early Z test dipende strettamente dall'ordine dei poligoni. Se l'ordine è back to front si ottiene overdraw massimo con in più l'overhead dei test aggiuntivi. Al contrario il Kyro eseguendo un'ordinamento di tutti i poligoni della tile ha in ogni caso overdraw nullo.
il link che hai postato, fa riferimento allo z-test dell'R200 che ancora presentava il problema dell'overdraw.
Una scansione back to front, in quel caso, non solo era affetta da overdraw (che era presente anche nella front to back) ma costringeva anche il chip ad effettuare quasi sempre entrambi gli step dello hyerarchical-z test, con notevole spreco di cicli di clock (praticamente si ottiene l'effetto opposto a quello che un ordinamento di tipo hyerarchical si propone, ossia di risparmiare cicli).
Il TBR del Kyro, invece, per la sua stessa natura, risulta quasi "trasparente" all'ordine in cui sono effettuate le operaziooni.
Nel caso dell'R300/R420, invece, in caso di back to front, non si ha overdraw, ma si ha il problema dello spreco di cicli di clock (per giunta peggio che nel caso dell'R200, poichè l'R300 ha un livello in più).
Una scansione back to front, in quel caso, non solo era affetta da overdraw (che era presente anche nella front to back) ma costringeva anche il chip ad effettuare quasi sempre entrambi gli step dello hyerarchical-z test, con notevole spreco di cicli di clock (praticamente si ottiene l'effetto opposto a quello che un ordinamento di tipo hyerarchical si propone, ossia di risparmiare cicli).
Sì hai ragione, mi sono confuso. Stavo ragionando pensando al caso della rasterizzazione immediata del triangolo.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.