View Full Version : considerazioni su G70 e R520
yossarian
29-10-2005, 17:31
tranquilli, non ho intenzione di ammorbare nessuno con post chilometrici e non sarò neppure io a parlarvi dell'argomento del thread. Ho intenzione di invitare vaio-man a illustrare analogie e differenze tra i due chip e a chiarirci le idee sullo sm3.0.
[Kendall]
29-10-2005, 17:37
tranquilli, non ho intenzione di ammorbare nessuno con post chilometrici e non sarò neppure io a parlarvi dell'argomento del thread. Ho intenzione di invitare vaio-man a illustrare analogie e differenze tra i due chip e a chiarirci le idee sullo sm3.0.
fermi tutti... Vado a prendere i popcorn e poi torno... Ma siamo sicuri che venga Vaio? :D
prima fila per me !!! quando inizia lo spattacolo che dopo cena devo uscire ?! :sofico:
yossarian
29-10-2005, 17:43
']fermi tutti... Vado a prendere i popcorn e poi torno... Ma siamo sicuri che venga Vaio? :D
spero; l'invito l'ha ricevuto. Sta nel thread su xbox2 e ps3 a "dare lezioni" sui chip grafici e lo sm3.0. Gli ho proposto di aprire un thread apposito, per evitare che continui a inquinare l'altro.
[Kendall]
29-10-2005, 17:56
spero; l'invito l'ha ricevuto. Sta nel thread su xbox2 e ps3 a "dare lezioni" sui chip grafici e lo sm3.0. Gli ho proposto di aprire un thread apposito, per evitare che continui a inquinare l'altro.
Vabbè, io aspetto con trepidazione :D
Murakami
29-10-2005, 18:13
Non conoscevo questo vaio-man, ma dall'introduzione di Yoss credevo che fosse un grande sviluppatore che ci onorava della sua presenza...poi sono andato a leggere gli ultimi post del thread sulle nuove console...ma...che diavolo... :doh:
Ma per scaldare l'ambiente una domandina da ignorantone quale sono.Ma alla fine con sti sm 3.0 c'è venuto in tasca qualcosa ?
Sono previste le edram per le rop's anche per le future architetture pc ?
e sopratutto la domandona un po ot ma alla quale nessuno ha saputo rispondere.Che ne è stato dell'unità per la gestione della codifica/decodifica video integrata da nv40 in poi ? (funziona ? c'è ? non c'è ? usa un utility apposta ? quale ?)
Che ne è stato dell'unità per la gestione della codifica/decodifica video integrata da nv40 in poi ? (funziona ? c'è ? non c'è ? usa un utility apposta ? quale ?)
vaio-man x piacere diccelo tu :fagiano: :D
Murakami
29-10-2005, 18:21
...e sopratutto la domandona un po ot ma alla quale nessuno ha saputo rispondere.Che ne è stato dell'unità per la gestione della codifica/decodifica video integrata da nv40 in poi ? (funziona ? c'è ? non c'è ? usa un utility apposta ? quale ?)
Per quanto riguarda la codifica, temo che nessuno sappia ancora rispondere... :sbonk:
Le decodifica, invece, funziona bene, anche se non su tutti i chip: fossi il possessore di una 6800 Ultra AGP io vorrei indietro i soldi... :rolleyes:
Per quanto riguarda la codifica, temo che nessuno sappia ancora rispondere... :sbonk:
Le decodifica, invece, funziona bene, anche se non su tutti i chip: fossi il possessore di una 6800 Ultra AGP io vorrei indietro i soldi... :rolleyes:
No lo chiedo perchè ho sentito dire che l'unità è fallata perchè complicava troppo il processo produttivo.Insomma era un'ottima feature poi da un momento all'altro PUFF silenzio assoluto.
Ma per scaldare l'ambiente una domandina da ignorantone quale sono.Ma alla fine con sti sm 3.0 c'è venuto in tasca qualcosa ?
Sono previste le edram per le rop's anche per le future architetture pc ?
Rispondo io a queste due:
1) Qualcosa si', per ora soprattutto ottimizzazioni, ci sono alcune situazioni dove, personalmente, guadagno circa il 5% di tempo di rendering dall'uso del dynamic branching; Splinter Cell usa l'SM3.0 per implementare effetti quali l'offset mapping che in SM2.0 richiederebbero piu' passate. Non e' tanto, ma e' qualcosa.
2) Non direi mai, ma non credo a breve. Le EDRAM sono costose ed e' importante dosarne la quantita' in maniera precisa. Su X360, che e' prodotto in decine di milioni di unita', dove i costi sono ammortizzati col software e dove la risoluzione finale si conosce ed e' pressoche' fissa (1280x720), l'EDRAM e' una scelta possibile. Su PC dove i costi della GPU devono essere coperti interamente dal prezzo di vendita, e le risoluzioni di uscita non sono prevedibili, dimensionare un'eventuale EDRAM sarebbe molto complesso e difficilmente economico. Diciamo che prima di essere un motivo tecnico, secondo me e' un motivo prettamente economico (almeno questa e' la spiegazione che mi e' stata data quando ho fatto questa domanda sia ad ATI sia ad NVIDIA).
Mi prendo quel posto li' in seconda fila con i pop corn in attesa della lezione di vaio-man.
tranquilli, non ho intenzione di ammorbare nessuno con post chilometrici e non sarò neppure io a parlarvi dell'argomento del thread. Ho intenzione di invitare vaio-man a illustrare analogie e differenze tra i due chip e a chiarirci le idee sullo sm3.0.
A me avrebbe fatto piacere da profano quale sono (sono economista non informatico).
Abbiamo direi l'onore di avere te e fek nel forum e penso ci avresti arricchito culturalmente un pò a tutti :)
Personalmente ho sempre qualche dubbio amletico da risolvere
Murakami
29-10-2005, 18:30
No lo chiedo perchè ho sentito dire che l'unità è fallata perchè complicava troppo il processo produttivo.Insomma era un'ottima feature poi da un momento all'altro PUFF silenzio assoluto.
Questo (http://www.nvidia.com/page/purevideo_support.html) è quanto ci è dato di sapere.
Mi sa che vaio-man me lo perdo, devo uscire a cena... :muro:
Rispondo io a queste due:
1) Qualcosa si', per ora soprattutto ottimizzazioni, ci sono alcune situazioni dove, personalmente, guadagno circa il 5% di tempo di rendering dall'uso del dynamic branching; Splinter Cell usa l'SM3.0 per implementare effetti quali l'offset mapping che in SM2.0 richiederebbero piu' passate. Non e' tanto, ma e' qualcosa.
2) Non direi mai, ma non credo a breve. Le EDRAM sono costose ed e' importante dosarne la quantita' in maniera precisa. Su X360, che e' prodotto in decine di milioni di unita', dove i costi sono ammortizzati col software e dove la risoluzione finale si conosce ed e' pressoche' fissa (1280x720), l'EDRAM e' una scelta possibile. Su PC dove i costi della GPU devono essere coperti interamente dal prezzo di vendita, e le risoluzioni di uscita non sono prevedibili, dimensionare un'eventuale EDRAM sarebbe molto complesso e difficilmente economico. Diciamo che prima di essere un motivo tecnico, secondo me e' un motivo prettamente economico (almeno questa e' la spiegazione che mi e' stata data quando ho fatto questa domanda sia ad ATI sia ad NVIDIA).
Mi prendo quel posto li' in seconda fila con i pop corn in attesa della lezione di vaio-man.
Visto che si sta chiacchierando di belle cosine ho letto che Havock ha intenzione di passare (finalmente ?) i calcoli fisici sulla gpu con shader 3.0.
La domanda è...ma appurato che le gpu sono molto potenti è realistica come ipotesi? a me è sembrata un pò una sparata.Avviene forse qualcosa di simile nelle console next-gen ? E come mai si torna a parlare di shader 3.0 only ? forse perchè saranno operzioni lunghissime che sforano i registri 2.0 ?
P.s tanto aspettiamo vaio.....
Visto che si sta chiacchierando di belle cosine ho letto che Havock ha intenzione di passare (finalmente ?) i calcoli fisici sulla gpu con shader 3.0.
La domanda è...ma appurato che le gpu sono molto potenti è realistica come ipotesi? a me è sembrata un pò una sparata.Avviene forse qualcosa di simile nelle console next-gen ? E come mai si torna a parlare di shader 3.0 only ? forse perchè saranno operzioni lunghissime che sforano i registri 2.0 ?
P.s tanto aspettiamo vaio.....
Mentre aspettiamo... dove hai letto questa notizia? Non ne avevo mai sentito parlare prima, e' interessante.
Sicuramente una parte della pipeline fisica puo' essere spostata sulla GPU. Mi puo' venire in mente la fase di integrazione, oppure tutti i calcoli di fluidodinamica o di dinamica dei vestiti. Certo non tutto puo' essere spostato, come ad esempio la gestione delle collisioni.
Mi piacerebbe sapere con piu' precisione che cosa vogliono portare sulla GPU, ma dubito che me lo diranno :)
Certamente l'SM3.0 fornisce un modello di sviluppo decisamente piu' rilassato e flessibile dell'SM2.0 per il quale vedrei altamente improbabile cose tipo fluido dinamica ad un certo livello.
Poi c'e' il problema del "read-back": con l'SM3.0 il risultato del pixel shader puo' essere letto da un vertex shader attraverso un vertex texture fetch e senza passare dalla CPU. Su SM2.0 questo non e' previsto esplicitamente e si deve passare attraverso una backdoor chiamata "render to vertex buffer". E' un po' un macello, la situazione non e' ideale. Mentre su X360............... :)
Mentre aspettiamo... dove hai letto questa notizia? Non ne avevo mai sentito parlare prima, e' interessante.
Sicuramente una parte della pipeline fisica puo' essere spostata sulla GPU. Mi puo' venire in mente la fase di integrazione, oppure tutti i calcoli di fluidodinamica o di dinamica dei vestiti. Certo non tutto puo' essere spostato, come ad esempio la gestione delle collisioni.
Mi piacerebbe sapere con piu' precisione che cosa vogliono portare sulla GPU, ma dubito che me lo diranno :)
Certamente l'SM3.0 fornisce un modello di sviluppo decisamente piu' rilassato e flessibile dell'SM2.0 per il quale vedrei altamente improbabile cose tipo fluido dinamica ad un certo livello.
Poi c'e' il problema del "read-back": con l'SM3.0 il risultato del pixel shader puo' essere letto da un vertex shader attraverso un vertex texture fetch e senza passare dalla CPU. Su SM2.0 questo non e' previsto esplicitamente e si deve passare attraverso una backdoor chiamata "render to vertex buffer". E' un po' un macello, la situazione non e' ideale. Mentre su X360............... :)
Eccoti il link (http://www.tomshw.it/news.php?newsid=5091)
In effetti sarebbe una gran cosa anche perchè ageia e simili mi sembrano "nate morte" ma magari sbaglio.
Ma il render to vertex buffer sbaglio o è il trick usato per far girare l'hdr con ps 2.0 ? A proposito di hdr secondo te si parla di Hdr con fp16 o con integer ?La demo di lost coast ha aperto la discussione.Per me High Dinamc Range è high perchè fp16 (almeno).Integer aprossima decisamente troppo.
Ma come mai nessuno ha parlato del fatto che l'hdr non potrà essere pienamente apprezzato dal fatto che molti pannelli lcd sono 8bit e non ricoprono tale range ? Questa è una mia considerazione magari sono pazzo :fagiano: :sofico:
yossarian
29-10-2005, 19:01
Rispondo io a queste due:
1) Qualcosa si', per ora soprattutto ottimizzazioni, ci sono alcune situazioni dove, personalmente, guadagno circa il 5% di tempo di rendering dall'uso del dynamic branching; Splinter Cell usa l'SM3.0 per implementare effetti quali l'offset mapping che in SM2.0 richiederebbero piu' passate. Non e' tanto, ma e' qualcosa.
2) Non direi mai, ma non credo a breve. Le EDRAM sono costose ed e' importante dosarne la quantita' in maniera precisa. Su X360, che e' prodotto in decine di milioni di unita', dove i costi sono ammortizzati col software e dove la risoluzione finale si conosce ed e' pressoche' fissa (1280x720), l'EDRAM e' una scelta possibile. Su PC dove i costi della GPU devono essere coperti interamente dal prezzo di vendita, e le risoluzioni di uscita non sono prevedibili, dimensionare un'eventuale EDRAM sarebbe molto complesso e difficilmente economico. Diciamo che prima di essere un motivo tecnico, secondo me e' un motivo prettamente economico (almeno questa e' la spiegazione che mi e' stata data quando ho fatto questa domanda sia ad ATI sia ad NVIDIA).
Mi prendo quel posto li' in seconda fila con i pop corn in attesa della lezione di vaio-man.
quelli di NV e ATi ti hanno detto bene; non ci sono particolari problemi tecnici da risolvere, quanto, più che altro problemi di costi. O meglio, esiste anche un problema tecnico, se problema lo vogliamo chiamare: il quantitativo di eDRAM da integrare nelle rop's. Su una consolle sai di utilizzare una determinata risoluzione (o comunque non c'è una grande escursione), per cui puoi regolarti di conseguenza. Su pc correresti il rischio, ad esempio, nel caso del MSAA, di avere abbastanza spazio da poter applicare il filtro, ad esempio, a 4x e 1024x768, caricando tutto on chip e con perdite prestazionali quasi nulle, passare alla risoluzione successiva e notare un calo di prestazioni, diciamo, non lineare.
Una cosa che però si è già fatta con R520, è quella di adottare buffer di dimensioni abbastanza generose da utilizzare in sostituzione delle eDRAM: ad esempio, il color buffer nelle rop's, anche se non ha le dimensioni e neppure la banda passante del buffer di R500, permette di eseguire le operazioni caricando parte dei dati sul chip. E' lui, ad esempio, uno dei responsabili della possibilità di applicare MSAA+HDR su R520. Anche l'utilizzo dell'array di registri nel pixel processor, le cui dimensioni superano, addirittura, la somma dei registri interni di G70, che pure ha 8 pixel pipeline in più, è un'indicazione di quella che sarà una delle strade da seguire nello sviluppo dei prossimi chip: buffer capienti e il maggior numero possibile di operazioni direttamemte on chip
quelli di NV e ATi ti hanno detto bene; non ci sono particolari problemi tecnici da risolvere, quanto, più che altro problemi di costi. O meglio, esiste anche un problema tecnico, se problema lo vogliamo chiamare: il quantitativo di eDRAM da integrare nelle rop's. Su una consolle sai di utilizzare una determinata risoluzione (o comunque non c'è una grande escursione), per cui puoi regolarti di conseguenza. Su pc correresti il rischio, ad esempio, nel caso del MSAA, di avere abbastanza spazio da poter applicare il filtro, ad esempio, a 4x e 1024x768, caricando tutto on chip e con perdite prestazionali quasi nulle, passare alla risoluzione successiva e notare un calo di prestazioni, diciamo, non lineare.
Una cosa che però si è già fatta con R520, è quella di adottare buffer di dimensioni abbastanza generose da utilizzare in sostituzione delle eDRAM: ad esempio, il color buffer nelle rop's, anche se non ha le dimensioni e neppure la banda passante del buffer di R500, permette di eseguire le operazioni caricando parte dei dati sul chip. E' lui, ad esempio, uno dei responsabili della possibilità di applicare MSAA+HDR su R520. Anche l'utilizzo dell'array di registri nel pixel processor, le cui dimensioni superano, addirittura, la somma dei registri interni di G70, che pure ha 8 pixel pipeline in più, è un'indicazione di quella che sarà una delle strade da seguire nello sviluppo dei prossimi chip: buffer capienti e il maggior numero possibile di operazioni direttamemte on chip
Quindi se ho capito bene il problema delle eDram è dovuto alla progettazione.Per tener conto delle esigenze di costo si dovrebbe ridurre al minimo utile la loro dimensione con il rischio che,data la variabilità delle risoluzioni pc il dato non fosse presente e introdurebbe dei wait state importanti per ricaricare il dato.
Di contro si può sostituire la eDram (per i profani più di me ha dei costi esorbitanti) con dei buffer specifici.Quello che non mi è chiaro e che il fatto che la edram sia montata esterna al r500 non riduca parte dei potenziali vantaggi per via del bus che la collega al core.Altra cosa interessante xbox usera la fp10 per l'hdr in quanto avrà lo stesso peso di int. 32.Potevano pensarci pure per pc senza appesantire con fp16 o usare int. 32...
http://www.beyond3d.com/articles/xenos/images/edrambandwidth.gif
Eccoti il link (http://www.tomshw.it/news.php?newsid=5091)
In effetti sarebbe una gran cosa anche perchè ageia e simili mi sembrano "nate morte" ma magari sbaglio.
Ma il render to vertex buffer sbaglio o è il trick usato per far girare l'hdr con ps 2.0 ? A proposito di hdr secondo te si parla di Hdr con fp16 o con integer ?La demo di lost coast ha aperto la discussione.Per me High Dinamc Range è high perchè fp16 (almeno).Integer aprossima decisamente troppo.
Grazie per il link :)
Il "render to vertex buffer" non e' altro che la possibilita' di riutilzzare una texture come input per un vertex shader. Una texture puo' essere l'output di un pixel shader. Cosi' si chiude il ciclo. Ad esempio, posso calcolare la posizione di un oggetto (piu' oggetti) a partire dalla sua posizione e dalle forze applicate, all'interno del pixel shader, scrivere il risultato e poi leggere il risultato sotto forma della nuova posizione dell'oggetto all'interno del vertex shader per spostarlo effettivamente. Questa possibilita' e' negata dalle DX9 (se non sotto forma del vertex texturing dell'SM3.0) ma e' supportata in hardware fin dall'R300.
Quando parlo di HDR io, parlo sempre di output su un render target fp16, ma preciso che non e' il solo modo possibile di fare HDR, e' il modo piu' diretto e flessibile. Ma ci sono altre vie per raggiungere il risultato, come la via adottata in HL2 che applica il tonemapping in ogni pixel shader, invece di essere uno stadio di postprocessing.
Il tonemapping si ricollega al tuo dubbio sui monitor. E' vero quello che dici, ma in una certa misura sara' sempre e comunque necessario un certo livello di tone mapping per mappare i valori calcolati dal rendering nei valori a disposizione del dispositivo di uscita (sia esso un monitor LDR a 8/10 bit per canale o un monitor HDR). E' nient'altro di cio' che accade nel cinema da decenni, quando il regista cambia l'esposizione della telecamera: quello e' un tonemapping. Anche il nostro occhio fa tonemapping nel momento in cui l'apertura dell'iride si adatta alla quantita di luce presente nell'ambiente.
Il rendering in tempo reale si sta sempre piu' avvicinando al cinema come tecniche utilizzate (HDR + compositing).
Una cosa che però si è già fatta con R520, è quella di adottare buffer di dimensioni abbastanza generose da utilizzare in sostituzione delle eDRAM: ad esempio, il color buffer nelle rop's, anche se non ha le dimensioni e neppure la banda passante del buffer di R500, permette di eseguire le operazioni caricando parte dei dati sul chip. E' lui, ad esempio, uno dei responsabili della possibilità di applicare MSAA+HDR su R520. Anche l'utilizzo dell'array di registri nel pixel processor, le cui dimensioni superano, addirittura, la somma dei registri interni di G70, che pure ha 8 pixel pipeline in più, è un'indicazione di quella che sarà una delle strade da seguire nello sviluppo dei prossimi chip: buffer capienti e il maggior numero possibile di operazioni direttamemte on chip
Ho giocato tutta la settimana con l'R500, roba banale per ora, giusto renderizzare qualche oggetto per prendere dimestichezza. E poi mi sono letto i doc.......... si puo' perdere la testa per un pezzo di silicio? :D
yossarian
29-10-2005, 19:33
Quindi se ho capito bene il problema delle eDram è dovuto alla progettazione.Per tener conto delle esigenze di costo si dovrebbe ridurre al minimo utile la loro dimensione con il rischio che,data la variabilità delle risoluzioni pc il dato non fosse presente e introdurebbe dei wait state importanti per ricaricare il dato.
Di contro si può sostituire la eDram (per i profani più di me ha dei costi esorbitanti) con dei buffer specifici.Quello che non mi è chiaro e che il fatto che la edram sia montata esterna al r500 non riduca parte dei potenziali vantaggi per via del bus che la collega al core.
http://www.beyond3d.com/articles/xenos/images/edrambandwidth.gif
esatto.
Per quanto riguarda il limite imposto dal bus, il problema non si pone. Le operazioni che, solitamente, risultano bandwidth limited, sono proprio quelle che avvengono all'interno delle rop's (operazioni di blending, appplicazione del MSAA, ecc), mentre le operazioni all'interno dello shader processor possono essere limitate solo dalla velocità di calcolo delle fpu, in quanto i dati trasferiti dallo shader processor alle rop's sono tutt'altro che voluminosi.
yossarian
29-10-2005, 19:34
Ho giocato tutta la settimana con l'R500, roba banale per ora, giusto renderizzare qualche oggetto per prendere dimestichezza. E poi mi sono letto i doc.......... si puo' perdere la testa per un pezzo di silicio? :D
può succedere; non è normale ma può succedere :D
Quando parlo di HDR io, parlo sempre di output su un render target fp16, ma preciso che non e' il solo modo possibile di fare HDR, e' il modo piu' diretto e flessibile. Ma ci sono altre vie per raggiungere il risultato, come la via adottata in HL2 che applica il tonemapping in ogni pixel shader, invece di essere uno stadio di postprocessing.
La via usata da Hl2 è stata la via "compatibilità" in un certo senso.Solo nv40 e successive evoluzioni e r520 permetto di renderizzare hdr in fp se non erro.
Essendo conscio che hdr si fà un pò come si vuole :) il rischio di usare integer non è quello di non avere un Hdr piuttosto un range a media dinamica
In effetti valve ci ha un pò depistato circa l'hdr
What does HDR require?
“True” HDR requires FP everywhere
Floating-point arithmetic
Floating-point render targets
Floating-point blending
Floating-point textures
Floating-point filtering
Floating-point display?
Come si è comportata valve nei confronti del supporto al blending inesistente nel pre-nv40 ?
yossarian
29-10-2005, 20:47
Grazie per il link :)
Quando parlo di HDR io, parlo sempre di output su un render target fp16, ma preciso che non e' il solo modo possibile di fare HDR, e' il modo piu' diretto e flessibile. Ma ci sono altre vie per raggiungere il risultato, come la via adottata in HL2 che applica il tonemapping in ogni pixel shader, invece di essere uno stadio di postprocessing.
Il tonemapping si ricollega al tuo dubbio sui monitor. E' vero quello che dici, ma in una certa misura sara' sempre e comunque necessario un certo livello di tone mapping per mappare i valori calcolati dal rendering nei valori a disposizione del dispositivo di uscita (sia esso un monitor LDR a 8/10 bit per canale o un monitor HDR). E' nient'altro di cio' che accade nel cinema da decenni, quando il regista cambia l'esposizione della telecamera: quello e' un tonemapping. Anche il nostro occhio fa tonemapping nel momento in cui l'apertura dell'iride si adatta alla quantita di luce presente nell'ambiente.
Il rendering in tempo reale si sta sempre piu' avvicinando al cinema come tecniche utilizzate (HDR + compositing).
un altro metodo, equivalente qualitativamente al render target fp16, è quello di fare blending fp16 all'interno delle rop's, utilizzando un apposito buffer e evitando il post processing, quindi fare tone mapping, applicare il MSAA e inviare tutto al fb in formato i8. Basta avere un buffer e il circuito di tone mapping all'interno delle rop's (come R5x0 e R500)
yossarian
29-10-2005, 20:48
La via usata da Hl2 è stata la via "compatibilità" in un certo senso.Solo nv40 e successive evoluzioni e r520 permetto di renderizzare hdr in fp se non erro.
Essendo conscio che hdr si fà un pò come si vuole :) il rischio di usare integer non è quello di non avere un Hdr piuttosto un range a media dinamica
In effetti valve ci ha un pò depistato circa l'hdr
What does HDR require?
“True” HDR requires FP everywhere
Floating-point arithmetic
Floating-point render targets
Floating-point blending
Floating-point textures
Floating-point filtering
Floating-point display?
Come si è comportata valve nei confronti del supporto al blending inesistente nel pre-nv40 ?
ha fatto tone mapping prima del blending, in modo tale che quest'ultimo è stato eseguito a i8 anzichè a fp16.
Comunque, ad essere pignoli, gli addetti ai lavori definiscono hdr quello in cui si utilizza fp32; tutte le altre forme sono classificate come mid range e la notazione i8 è considerata low range.
domanda niubba: :stordita:
ma di che "range" si parla? il numero di colori? la differenza di luminosità tra l'oggetto più chiaro e quello più scuro? o cos'altro?
yossarian
29-10-2005, 22:20
domanda niubba: :stordita:
ma di che "range" si parla? il numero di colori? la differenza di luminosità tra l'oggetto più chiaro e quello più scuro? o cos'altro?
all'interno di un chip, ormai la maggior parte dei calcoli è eseguita in fp16 o fp32. Il problema è che quando, poi, le immagini digitalizzate sono trasferite al frame buffer, a causa della limitazione dei monitor che non vanno oltre gli 8 bit interi per canale (tranne rare e costose eccezioni), si opera una riduzione di precisione, da fp16 o fp32 a i8. Senza hdr, questa riduzione qualitativa avveniva all'uscita delle pixel pipleine (e pensavano gli stessi pixel shader a effettuare la compressione), quindi i dati erano inviati alle rop's, che si occupano di applicare MSAA, di fare color e alpha blending, già in formato i8. Con l'hdr, i dati arrivano alle rop's in formato fp16, li sono eseguite le operazioni di alpha e color blending, sempre in fp16, e quindi, inviate al frame buffer. Qui possono arrivare sia in formato fp16 e essere trasformate (mediante tone mappung) in i8, in post processing (cioè una volta terminata l'elaborazione del frame), oppure possono, se l'HW lo permette, essere sottoposte a tone mapping direttamente nelle rop's e arrivare al fb già in i8. All'atto pratico, l'applicazione dell'hdr permette di eseguire in fp16 (e quindi con maggior precisione e utilizzando un range più ampio, di sfumatire di colore, di trasparenze, di luminosità e quant'altro e, per di più, dinamico, in quanto l'utilizzo della virgola mobile permette l'adattamento dinamico del range utilizzato per quella particolare rappresentazione, tutta una serie di operazioni (quelle interne alle rop's) che prima avvenivano con notazione intera a 8 bit per canale. Alla fine, in ogni caso, si deve passare agli 8 bit interi, però l'aver potuto utilizzare fp16 per il maggior numero possibile di operazioni, permette una rappresentazione più realistica delle immagini. Tra le cose che beneficiano di questo allargamento della gamma di valori, ci sono anche luminosità e numero di sfumature per colore.
ok grazie ora la cosa è più chiara.. :)
ha fatto tone mapping prima del blending, in modo tale che quest'ultimo è stato eseguito a i8 anzichè a fp16.
Comunque, ad essere pignoli, gli addetti ai lavori definiscono hdr quello in cui si utilizza fp32; tutte le altre forme sono classificate come mid range e la notazione i8 è considerata low range.
ok ma non penso che ci sia hw a breve che faccia hdr a 32fp quando ho fatto notare nel 3d di hl2 lost coast che la tecnica integer non era "vero" hdr mi sono saltati alla gola.
Ma quì entra in gioco la mia ignoranza ma tone mapping non è l'ultima operazione prima della resa a schermo?
Come hanno aggirato al problema hdr + aa presumo visto l'andazzo di fare l'aa come post processing...quanto incide fp16 rispetto a int.32 ?Mi viene da fare un rapido conto e dovrebbe "pesare" un 30% in più :eek:
La differenza tra integer32 e fp16 è evidente...
http://www.hardwaresecrets.com/imageview.php?image=844
all'interno di un chip, ormai la maggior parte dei calcoli è eseguita in fp16 o fp32. Il problema è che quando, poi, le immagini digitalizzate sono trasferite al frame buffer, a causa della limitazione dei monitor che non vanno oltre gli 8 bit interi per canale (tranne rare e costose eccezioni), si opera una riduzione di precisione, da fp16 o fp32 a i8. Senza hdr, questa riduzione qualitativa avveniva all'uscita delle pixel pipleine (e pensavano gli stessi pixel shader a effettuare la compressione), quindi i dati erano inviati alle rop's, che si occupano di applicare MSAA, di fare color e alpha blending, già in formato i8. Con l'hdr, i dati arrivano alle rop's in formato fp16, li sono eseguite le operazioni di alpha e color blending, sempre in fp16, e quindi, inviate al frame buffer. Qui possono arrivare sia in formato fp16 e essere trasformate (mediante tone mappung) in i8, in post processing (cioè una volta terminata l'elaborazione del frame), oppure possono, se l'HW lo permette, essere sottoposte a tone mapping direttamente nelle rop's e arrivare al fb già in i8. All'atto pratico, l'applicazione dell'hdr permette di eseguire in fp16 (e quindi con maggior precisione e utilizzando un range più ampio, di sfumatire di colore, di trasparenze, di luminosità e quant'altro e, per di più, dinamico, in quanto l'utilizzo della virgola mobile permette l'adattamento dinamico del range utilizzato per quella particolare rappresentazione, tutta una serie di operazioni (quelle interne alle rop's) che prima avvenivano con notazione intera a 8 bit per canale. Alla fine, in ogni caso, si deve passare agli 8 bit interi, però l'aver potuto utilizzare fp16 per il maggior numero possibile di operazioni, permette una rappresentazione più realistica delle immagini. Tra le cose che beneficiano di questo allargamento della gamma di valori, ci sono anche luminosità e numero di sfumature per colore.
Traduzione: :D
Se al posto di lavorare con numeri interi lavori con anche i decimali ottieni molte più possibili combinazioni che si ripercuotono in un maggior numero di sfumature cromatiche dovute appunto a una miglior approssimazione della realtà.
Esame di calcolo numerico docet :D
Per quanto riguarda l'uso di Havok dell'accelerazione via GPU dei calcoli riguardanti la fisica
Havok FX (http://www.havok.com/content/view/187/77/)
Free Gordon
30-10-2005, 00:05
Xenos grazie al MEMEXPORT dovrebbe andare aldilà di questo.
O raga, ma quant'è gagliarda sta GPU??? :sofico: :sofico: :sofico:
Quali sono le novità degli SM4 ? (a parte l'unificazione degli shader)
yossarian
30-10-2005, 01:49
ok ma non penso che ci sia hw a breve che faccia hdr a 32fp quando ho fatto notare nel 3d di hl2 lost coast che la tecnica integer non era "vero" hdr mi sono saltati alla gola.
Ma quì entra in gioco la mia ignoranza ma tone mapping non è l'ultima operazione prima della resa a schermo?
Come hanno aggirato al problema hdr + aa presumo visto l'andazzo di fare l'aa come post processing...quanto incide fp16 rispetto a int.32 ?Mi viene da fare un rapido conto e dovrebbe "pesare" un 30% in più :eek:
La differenza tra integer32 e fp16 è evidente...
http://www.hardwaresecrets.com/imageview.php?image=844
non è corretto dire che l'utilizzo di interi non possa definirsi hdr; esistono vari modo e diversi algoritmi per fare hdr e non tutti fanno uso di fp16; ce ne sono a 48 bit (come quello di OpenEXR, con 16 bit per canale + 16 di alpha channel), ce ne sono a 32, a 36, a 24, a 33 bit(pixel; ce ne sono alcuni che utilizzano, a desempio, 32 o 36 bit/pixel, che permettono di raggiungere un range più ampio di quello di OPenEXR (che ne usa 48). Uno degli aspetti fondamentali, quando si fa hdr, è l'algortimo di tone mapping e, in questo caso, quello di OPenEXR è uno dei migliori in quanto a resa qualitativa dopo la compressione da fp16 a i8.
Allo stesso modo, si può classificare come hdr una qualsiasi tecnica che fa uso di tutte , o quasi, le caratteristiche che hai elencato sopra; dico quasi, perchè anche l'utilizzo interi o di notazione in virgola fissa (fx), può rientrare, a pieno titolo, tra le forme di hdr. Ad esempio, un modo per fare hdr con un chip non predisposto all'fp blending, come R4x0, può essere quello di fare render to texture e usare i ps per fare fp blending prima del tone mapping (entrambi in post processing). Vista l'enorme varietà di modi di fare hdr, anche l'ipotesi di fare blending dopo aver fatto tone mapping, al limite, può essere ammissibile, purchè l'algoritmo di compressione sia di buona qualità (i migliori sono, in genere, quelli logaritmici).
Se ti riferisci a Lost Coast, il modo per applicare MSAA insiene all'hdr è solo uno: si deve fare tone mapping prima di applicare il MSAA; questo eprchè il circuito che si occupa del MSAA lavora solo a i8. Quindi, in ogni caso, l'AA si può applicare solo su un framebuffer in modalità 8 bit INT per canale.
yossarian
30-10-2005, 01:58
Quali sono le novità degli SM4 ? (a parte l'unificazione degli shader)
http://www.beyond3d.com/articles/directxnext/
buona lettura :)
Hai dimenticato l'hdr 10fp di xbox 360 :D.
Insomma è sempre un discorso di precisione come fu per gli shader.Sia lo shader a fp16 che fp24 (radeon) che fp32 sempre shader era però qualitativamente e computazionalmente diversi.
Per le implementazioni odierne (hl2,splinte cell) penso che pecchino di un attaccamento al passato (comprensibile) lavorando su int. e in effetti la resa non è il massimo.
Con questo chiarito che tutti è hdr :-)
Immaginavo qualcosa di simile riguardo l'msaa+hdr.Ma allora r520 che permette hdr+msaa porta a qualche vantaggio qualitativo/computazionale ? (visto che a sto punto presumo che non lavori in i8)
Ma è possibile usare le Stencil shadow volumes senza supporto hw al blending ? :confused:
P.s rompo più di bruno vespa :D
yossarian
30-10-2005, 02:31
Hai dimenticato l'hdr 10fp di xbox 360 :D.
Insomma è sempre un discorso di precisione come fu per gli shader.Sia lo shader a fp16 che fp24 (radeon) che fp32 sempre shader era però qualitativamente e computativamente diversi.
Per le implementazioni odierne (hl2,splinte cell) penso che pecchino di un attaccamento al passato (comprensibile) lavorando su int. e in effetti la resa non è il massimo.
Immaginavo qualcosa di simile per farci stare l'msaa.Ma allora r520 che permette hdr+msaa porta a qualche vantaggio qualitativo/computazionale ? (visto che a sto punto presumo che non lavori in i8)
Ma è possibile usare le Stencil shadow volumes senza supporto hw al blending ? :confused:
P.s rompo più di bruno vespa :D
Beh, non attenendosi strettamente alla definizione precisa di hdr (fp32), ance per mancanza di HW di supporto, tutto ciò che permette di raggiungere un range superiore agli 8 bit interi per canale, automaticamente diventa hdr (anche se la qualità non è la stessa, per forza di cose). Per quanto riguarda l'utilizzo nei chip grafici, si è scelta la modalità fp16 di OpenEXR, perchè, oltre a garantire un buon incremento del range dinamico, implementa anche uno dei migliori algoritmi di compressione in assoluto (e questo garantisce risultati di buona qualità anche dopo il passaggio a i8). Però, come hai ricordato anche tu, ce ne sono anche altre (i10 e i16, ad esempio, entrambe supportate da R5x0 e R500).
Le implementazioni in HL2 e SC, nel complesso, sono qualitativamente molto buone, compatibilmente con i limiti dell'HW su cui devono girare.
R5x0 funziona come R500; hanno infilato un color buffer nelle rop's, a cui hanno accesso sia le color rop's e le z-rop's che il circuito di MSAA. In questo modo, si arriva in fp16 fino alle color rop's che fanno blending dentro al color buffer (quindi on chip); quindi si fa tone mapping e si applica il MSAA, sempre a i8 e sempre on chip. In questo modo, l'immagine arriva già pronta al fb, le operazioni sono più veloci e si risparmia anche banda passante (e sono soddisfatte tutte le richieste affinchè lo si possa catalogare come hdr a tutti gli effetti). Il MSAA lavora a i8 su tutti i chip: anche su R500.
Non capisco cosa intendi per supporto HW al blending; nella peggiore delle ipotesi, comunque, un supporto HW al blending c'è comunque, visto che i ps possono svolgere qualsivoglia operazione di blending (e un buffer, on chip o ricavato nella vram, per immagazzinare i risultati intermedi dell'elaborazione comunque serve).
ok ma non penso che ci sia hw a breve che faccia hdr a 32fp quando ho fatto notare nel 3d di hl2 lost coast che la tecnica integer non era "vero" hdr mi sono saltati alla gola.
Ma quì entra in gioco la mia ignoranza ma tone mapping non è l'ultima operazione prima della resa a schermo?
Come hanno aggirato al problema hdr + aa presumo visto l'andazzo di fare l'aa come post processing...quanto incide fp16 rispetto a int.32 ?Mi viene da fare un rapido conto e dovrebbe "pesare" un 30% in più :eek:
La differenza tra integer32 e fp16 è evidente...
http://www.hardwaresecrets.com/imageview.php?image=844
Hanno fatto il tone mapping in ogni pixel shader ancora prima di arrivare alle ROP. In pratica mandano alle ROP e poi a schermo un colore gia' i8, in range [0..1]. E' comunque "vero" HDR rendering, nel senso che i calcoli di illuminazione sono fatti in HDR e poi mappati immediatamente.
Quello che di solito si indica come HDR, la tecnica piu' flessibile, prevede che i calcoli di illuminazione siano fatti in fp32, il risultato sia passato alle ROP in fp16, le quali possono fare il blending del colore con il resto del framebuffer in questo formato. Una successiva operazione di postprocessing mappa il range dinamico in fp16 ad una comune precisione i8 che poi viene mandata a schermo.
I vantaggi di questa tecnica consistono nella possibilita' di gestire piu' luci in multipass (questo e' impossibile in HL2), di avere anche il blending di superfici trasparenti corretto in HDR, e di essere leggermente meno costoso in situazioni di alto overdraw. Consuma pero' piu' banda passante e richiede hardware dedicato e non supporta MSAA sull'NV40.
Free Gordon
30-10-2005, 16:26
quelli di NV e ATi ti hanno detto bene; non ci sono particolari problemi tecnici da risolvere, quanto, più che altro problemi di costi. O meglio, esiste anche un problema tecnico, se problema lo vogliamo chiamare: il quantitativo di eDRAM da integrare nelle rop's. Su una consolle sai di utilizzare una determinata risoluzione (o comunque non c'è una grande escursione), per cui puoi regolarti di conseguenza. Su pc correresti il rischio, ad esempio, nel caso del MSAA, di avere abbastanza spazio da poter applicare il filtro, ad esempio, a 4x e 1024x768, caricando tutto on chip e con perdite prestazionali quasi nulle, passare alla risoluzione successiva e notare un calo di prestazioni, diciamo, non lineare.
Una cosa che però si è già fatta con R520, è quella di adottare buffer di dimensioni abbastanza generose da utilizzare in sostituzione delle eDRAM: ad esempio, il color buffer nelle rop's, anche se non ha le dimensioni e neppure la banda passante del buffer di R500, permette di eseguire le operazioni caricando parte dei dati sul chip. E' lui, ad esempio, uno dei responsabili della possibilità di applicare MSAA+HDR su R520. Anche l'utilizzo dell'array di registri nel pixel processor, le cui dimensioni superano, addirittura, la somma dei registri interni di G70, che pure ha 8 pixel pipeline in più, è un'indicazione di quella che sarà una delle strade da seguire nello sviluppo dei prossimi chip: buffer capienti e il maggior numero possibile di operazioni direttamemte on chip
Dalle prime indiscrezioni riguardo ai giochi in uscita, pare che la eDRAM possa applicare il 4x quasi free, solo nel caso in cui non vengano utilizzati altri filtri o effetti (si parla anche del motion blur), nel gioco.
Se questo fosse vero, non ti pare una limitazione un pò troppo grossa, per quanto riguarda i costi/benefici din una tecnologia del genere?
Sta cosa mi ha deluso un pò... :( sapresti dirmi se è vera o no?
yossarian
30-10-2005, 16:34
Dalle prime indiscrezioni riguardo ai giochi in uscita, pare che la eDRAM possa applicare il 4x quasi free, solo nel caso in cui non vengano utilizzati altri filtri o effetti (si parla anche del motion blur), nel gioco.
Se questo fosse vero, non ti pare una limitazione un pò troppo grossa, per quanto riguarda i costi/benefici din una tecnologia del genere?
Sta cosa mi ha deluso un pò... :( sapresti dirmi se è vera o no?
è vera e dipende dallo spazio richiesto per l'applicazione dei filtri. Per poter fare altrimenti, ci vorrebbe un buffer molto più ampio dei 10 MB dell'R500 (ad esempio, un'immagine a 1024x768, senza filtri, occupa, non considerando gli algoritmi di compressione, circa 6,3 MB se si utilizza fb a i8).
Non è una limitazione, in quanto, senza la presenza di buffer all'interno delle rop's, è impossibile avere free anche il solo MSAA. Le eDRAM, rispetto ad un normale buffer, tipo quello utilizzato si R5x0, ha il vantaggio di avere una bandwidth molto più ampia (256 contro 40 GB circa della XT) e tempi d'accesso ridotti, grazie alla presenza di una sorta di cache di secondo livello, all'interno della cache principale, di tipo SRAM
Xenos grazie al MEMEXPORT dovrebbe andare aldilà di questo.
O raga, ma quant'è gagliarda sta GPU??? :sofico: :sofico: :sofico:
Scusa è di mamma ATI, di che ti meravigli ? :confused:
:sofico:
Dalle prime indiscrezioni riguardo ai giochi in uscita, pare che la eDRAM possa applicare il 4x quasi free, solo nel caso in cui non vengano utilizzati altri filtri o effetti (si parla anche del motion blur), nel gioco.
PGR3(motion blur,AA,HDR) :read:
buona lettura
Speravo in un breve riassuntino con le cose + importanti... :D
Free Gordon
30-10-2005, 23:11
:sofico:
:sofico: :sofico: :sofico:
Free Gordon
30-10-2005, 23:14
PGR3(motion blur,AA,HDR) :read:
E 30fps.................... :cry: :cry: :cry: :cry:
Preferivo meno menate e più fluidità... :rolleyes:
Boh, io ci spero ancora cmq... :fagiano:
Ps: sull'AA di PGR3 avrei cmq dei dubbi...
Dai filmati pare che AL MAX nella finale ci sarà un 2x e la demo che girava allo Smau era una scaletta unica.... :mad:
renax200
07-11-2005, 13:49
salve raga...mi hanno detto su forumeye che per questa domanda dovevo rivolgermi ad yossiaran....allora la domanda è questa...la gpu della x360 è + potente della ati x1800xt?
Foglia Morta
07-11-2005, 13:53
yoss sta diventando un vip in rete :D
Free Gordon
07-11-2005, 14:17
salve raga...mi hanno detto su forumeye che per questa domanda dovevo rivolgermi ad yossiaran....allora la domanda è questa...la gpu della x360 è + potente della ati x1800xt?
Bella domanda! :D
yossarian
07-11-2005, 14:46
salve raga...mi hanno detto su forumeye che per questa domanda dovevo rivolgermi ad yossiaran....allora la domanda è questa...la gpu della x360 è + potente della ati x1800xt?
è più potente a livello di capacità di calcolo (operazioni per ciclo di clcok), è meglio ottimizzata grazie all'unificazione degli shader (che permette un'ottimale ripartizione dei carichi di lavoro), gestisce meglio le operazioni all'interno delle rop's, grazie all'eDRAM e ai 256 Gb di bandwidth tra buffer e unità di calcolo e ha la funzione memexport; questi i pro, adesso passiamo ai contro: solo 8 rop's contro le 16 di R520 (anche se quelle di R500 raddoppiano l'output in caso di only z pixel) e lavora a frequenza inferiore (il fillrate teorico di R500 è di "soli" 4000 MPixel/sec contro i 10k di R520, però all'aumentare della complessità di calcolo, lo scostamento dal valore teorico, per R500, è molto meno sensibile rispetto a quello di R520).
Diciamo che, nel complesso, R500 è più potente di R520, ma che la differenza sarebbe molto più elevata se R500 lavorasse a frequenza più alte e avesse almeno 16 rop's
Free Gordon
07-11-2005, 14:59
Solo 8 ROPs! :eek:
Ma non è un pò fillrate limited allora? :D
Peggio della 7800 mi pare... :p (da profano eh.. :stordita: )
yossarian
07-11-2005, 15:41
Solo 8 ROPs! :eek:
Ma non è un pò fillrate limited allora? :D
Peggio della 7800 mi pare... :p (da profano eh.. :stordita: )
tutto è relativo all'uso che se ne deve fare; è inutile avere un fillrate teorico di 10k e poi, con AA e AF attivi, oppure con 4 texture, si scende a 2500 MPixel/sec. Se hai 4k Mpixel/sec teorici e ti avvicini a quel valore sia con calcoli smeplici che con calcoli complessi (grazie anche a motori grafici ottimizzati (si parla di consolle), il risultato finale sarà superiore a quello ottenibile con valori teorici molto più levati e valori reali inferiori.
Free Gordon
07-11-2005, 16:00
Ho capito, un mostro di ottimizzazione. :D
Volevo farti un'altra domanda: per C1 si parla di 48 ALU, non 48 pipe... giusto?
Ma in C1 ogni ALU possiede anche una mini-ALU? Come nelle altre architetture?
E quante TMU ha C1, per ogni ALU?
yossarian
07-11-2005, 17:24
Ho capito, un mostro di ottimizzazione. :D
Volevo farti un'altra domanda: per C1 si parla di 48 ALU, non 48 pipe... giusto?
Ma in C1 ogni ALU possiede anche una mini-ALU? Come nelle altre architetture?
E quante TMU ha C1, per ogni ALU?
C1 ha 48 alu full vect fp128 + 48 alu fp32 scalari (configurazione analoga a quella delle vertex unit dei chip NV da NV40 in poi e di quelli ATi da R300 in poi; ha 16 tmu complete + 16 tmu in grado di fare solo texture fetch e point sampling (da adoperare alla stregua delle tmu delle vertex unit di NV40/G70). Inoltre le tmu sono raggruppate in array, al pari di quanto avviene con la fpu, quindi non ci sono tmu dedicate ad una specifica alu ma tmu dedicate ad uno specifico thread (con il numero di unità dedicate che può variare in base al carico di lavoro). Già in R520 si ha una cosa simile, però con 4 tmu dedicate ad ogni quad
Free Gordon
07-11-2005, 21:38
C1 ha 48 alu full vect fp128 + 48 alu fp32 scalari (configurazione analoga a quella delle vertex unit dei chip NV da NV40 in poi e di quelli ATi da R300 in poi; ha 16 tmu complete + 16 tmu in grado di fare solo texture fetch e point sampling (da adoperare alla stregua delle tmu delle vertex unit di NV40/G70). Inoltre le tmu sono raggruppate in array, al pari di quanto avviene con la fpu, quindi non ci sono tmu dedicate ad una specifica alu ma tmu dedicate ad uno specifico thread (con il numero di unità dedicate che può variare in base al carico di lavoro). Già in R520 si ha una cosa simile, però con 4 tmu dedicate ad ogni quad
Grazie. ;)
Detto così sembra veramente una figata di chip! :eek:
Attendo con ansia Halo3 e Ninja gaiden2!!!! :sofico:
Free Gordon
09-11-2005, 03:45
tutto è relativo all'uso che se ne deve fare; è inutile avere un fillrate teorico di 10k e poi, con AA e AF attivi, oppure con 4 texture, si scende a 2500 MPixel/sec. Se hai 4k Mpixel/sec teorici e ti avvicini a quel valore sia con calcoli smeplici che con calcoli complessi (grazie anche a motori grafici ottimizzati (si parla di consolle), il risultato finale sarà superiore a quello ottenibile con valori teorici molto più levati e valori reali inferiori.
Ancora una domanda niubbissima... :sofico:
Se i giochi per 360, vengono fatti tutti in 720p, visualizzano per ogni frame, al massimo 1 mln di pixel circa...giusto? (920mila ecc..)
Cosa serve allora avere una macchina in grado di sparare 4000 :eek: mln di pixel in un secondo, se poi i gli fps saranno al max 60 (60x1=60mln al sec)?? :stordita:
yossarian
09-11-2005, 14:28
Ancora una domanda niubbissima... :sofico:
Se i giochi per 360, vengono fatti tutti in 720p, visualizzano per ogni frame, al massimo 1 mln di pixel circa...giusto? (920mila ecc..)
Cosa serve allora avere una macchina in grado di sparare 4000 :eek: mln di pixel in un secondo, se poi i gli fps saranno al max 60 (60x1=60mln al sec)?? :stordita:
hai ragione, si tratta di una domanda niubbissima :D .
Apparentemente non ha senso, se consideriamo i valori teorici. Peccato che, quando hai a che fare con calcoli complessi succede che ad esmepio, la 9700 pro, che ha un fillrate teorico di 2600 Mp/sec, basta fare multitexturing con più di 4 o 5 texel per pixel per vedela precipitare a qualche centinaio di MP/sec.
Per quanto un chip possa essere efficiente e per quanto un SW ottimizzato, ci sono delle operazioni che richiedono un elevato numero di ciclo di clock e operazioni che vanno svolte in multipass e in post processing. Questo rende di gran lunga più pesante l'elaborazione.
Ad esempio, nVIDIA, per il G70, dichiara, per ogni pixel pipeline, 5 istruzione per ciclo; all'atto pratico, con fp16 le istruzioni medie svolte sono 2,2 per ciclo, con fp32 si scende a 1,6 (puoi immaginare l'impatto sul fillrate e, di conseguenza, sul frame rate)
è vera e dipende dallo spazio richiesto per l'applicazione dei filtri. Per poter fare altrimenti, ci vorrebbe un buffer molto più ampio dei 10 MB dell'R500 (ad esempio, un'immagine a 1024x768, senza filtri, occupa, non considerando gli algoritmi di compressione, circa 6,3 MB se si utilizza fb a i8).
Non è una limitazione, in quanto, senza la presenza di buffer all'interno delle rop's, è impossibile avere free anche il solo MSAA. Le eDRAM, rispetto ad un normale buffer, tipo quello utilizzato si R5x0, ha il vantaggio di avere una bandwidth molto più ampia (256 contro 40 GB circa della XT) e tempi d'accesso ridotti, grazie alla presenza di una sorta di cache di secondo livello, all'interno della cache principale, di tipo SRAM
C'è una cosa però che non mi quadra: se l'AA MS stressa principamente il chip video, mentre "rilassa" un po' la memoria video, come mai usando una eDRAM ci sono benefici così evidenti? Cioè, se è legato principalmente al fill-rate del chip, come mai una tecnica per la velocizzazione dell'accesso alla memoria ha dei risultati così positivi?
Ciao. :)
yossarian
09-11-2005, 18:16
C'è una cosa però che non mi quadra: se l'AA MS stressa principamente il chip video, mentre "rilassa" un po' la memoria video, come mai usando una eDRAM ci sono benefici così evidenti? Cioè, se è legato principalmente al fill-rate del chip, come mai una tecnica per la velocizzazione dell'accesso alla memoria ha dei risultati così positivi?
Ciao. :)
il MSAA ha un circuito dedicato all'interno delle rop's, che opera a i8 (in tutti i chip più recenti). Questo significa che non sono coinvolte le psu e che un buffer di 10 MB permette di eseguire un elevatissimo numero di operazioni on chip (a 640x480, con AA4x, puoi lavorare su un intero frame senza accessi alla ram esterna, che sono almeno due ordini di grandezza, forse tre, più lenti dell'accesso a buffer interni).
il MSAA ha un circuito dedicato all'interno delle rop's, che opera a i8 (in tutti i chip più recenti). Questo significa che non sono coinvolte le psu e che un buffer di 10 MB permette di eseguire un elevatissimo numero di operazioni on chip (a 640x480, con AA4x, puoi lavorare su un intero frame senza accessi alla ram esterna, che sono almeno due ordini di grandezza, forse tre, più lenti dell'accesso a buffer interni).
Con l'espressione "chip recenti" cosa intedi all'incirca?
OK per la maggior velocità di accesso ai dati garantiti dall'eDRAM, però mi sorgono 2 dubbi:
-) se la eDRAM sarà, come mi è capitato di leggere, su un die separato rispetto alla GPU, bhe... che embedded è? :confused: :p
-) possibile che sia addirittura 100/1000 volte più veloce rispetto alle memorie esterne (VRAM)?
Ciao. :)
yossarian
09-11-2005, 21:24
Con l'espressione "chip recenti" cosa intedi all'incirca?
OK per la maggior velocità di accesso ai dati garantiti dall'eDRAM, però mi sorgono 2 dubbi:
-) se la eDRAM sarà, come mi è capitato di leggere, su un die separato rispetto alla GPU, bhe... che embedded è? :confused: :p
-) possibile che sia addirittura 100/1000 volte più veloce rispetto alle memorie esterne (VRAM)?
Ciao. :)
dalla dx9 generation :D
la eDRAM è su un die separato, ma i dati sono compressi nello shader processor, passano attraverso il canale di connessione, e arrivano nell'eDRAM che si chiama e(mbedded)RAM, proprio perchè all'interno ci sono 192 unità di calcolo (le rop's) che svolgono operazioni di blending, z-test, MSAA, ecc, ecc. Quindi, l'embedded è riferito alle rop's, non allo shader processor
Si, perchè è l'equivalente di un registro interno (e quindi ad accesso rapido), e ha una composizione mista DRAM-SRAM che la rende più veloce (le VRAM sono di tipo SDRAM e l'unità di calcolo specifica non ha accesso diretto)
dalla dx9 generation :D
Quindi da R300 / NV30, giusto?
la eDRAM è su un die separato, ma i dati sono compressi nello shader processor, passano attraverso il canale di connessione, e arrivano nell'eDRAM che si chiama e(mbedded)RAM, proprio perchè all'interno ci sono 192 unità di calcolo (le rop's) che svolgono operazioni di blending, z-test, MSAA, ecc, ecc. Quindi, l'embedded è riferito alle rop's, non allo shader processor
Perfetto... questo dato importante mi era sfuggito! :stordita:
Si, perchè è l'equivalente di un registro interno (e quindi ad accesso rapido), e ha una composizione mista DRAM-SRAM che la rende più veloce (le VRAM sono di tipo SDRAM e l'unità di calcolo specifica non ha accesso diretto)
Sulla maggiore velocità non ci sono dubbi, è il valore di 100 o 1000 volte maggiore che mi lascia un po' perplesso...
Una scheda come la X1800XT può vantare una banda di 40GB/sec, immaginare un qualcosa di così enormemente superiore mi stupisce! Anche per il discorso latenze, è vero che con la eDRAM si hanno latenze molto basse (tipo quelle delle cache L2 dei processori), però migliorare di 100 o 1000 volte rispetto a una veloce memoria VRAM mi pareva impossibile... :mbe:
Ciao. :)
Ancora una domanda niubbissima... :sofico:
Se i giochi per 360, vengono fatti tutti in 720p, visualizzano per ogni frame, al massimo 1 mln di pixel circa...giusto? (920mila ecc..)
Cosa serve allora avere una macchina in grado di sparare 4000 :eek: mln di pixel in un secondo, se poi i gli fps saranno al max 60 (60x1=60mln al sec)?? :stordita:
Serve perche' i pixel che vedi a schermo non sono gli unici frammenti calcolati dalla GPU. Da una parte ogni pixel su schermo viene toccato mediamente almeno due volte per via dell'overdraw della scena, pezzi di scena che si disegnano l'uno sull'altro.
Da un altro lato molto rendering non va direttamente a schermo, ma va su render target d'appoggio che servono per calcolare dati intermedi da usare durante il rendering finale. Immagina uno shadow buffer dove la scena viene renderizzata dal punto di vista di una luce permemorizzare la distanza di ogni pixel dalla luce stessa, per poi usarlo durante il rendering per calcolare le zone in ombra. Immagina poi questo shadow buffer ricalcolato per ogni luce della scena (magari tre, quattro, cinque volte).
Ed infine, una volta renderizzata la scena, immagina di voler applicare qualche effetto in post processing (depth of field, blur, tone mapping, bloom e quant'altro ti possa venire in mente). Ecco che ogni pixel viene toccato altre due o tre volte.
Alla fine del rendering vedrai che il fillrate non basta mai e, se ce ne fosse di piu', si potrebbe sempre implementare un altro effetto...
tutto è relativo all'uso che se ne deve fare; è inutile avere un fillrate teorico di 10k e poi, con AA e AF attivi, oppure con 4 texture, si scende a 2500 MPixel/sec. Se hai 4k Mpixel/sec teorici e ti avvicini a quel valore sia con calcoli smeplici che con calcoli complessi (grazie anche a motori grafici ottimizzati (si parla di consolle), il risultato finale sarà superiore a quello ottenibile con valori teorici molto più levati e valori reali inferiori.
E su questi piccoli mostri gli shader tendono a diventare presto piuttosto lunghi e complessi. Giusto giocando un po' qui e un po' la' con l'X360, in una settimana lo shader che sto scrivendo per l'illuminazione ha sfondato le 100 istruzioni (il piu' lungo che ho scritto per bw2 era di 60 per l'acqua). E inizia a mettere un numero illimitato di luci per pixel, usa un kernel corposo per filtrare le shadow map e le istruzioni salgono.
Il bello di questa GPU e' che ancora non si sta sedendo, tanto che stiamo pensando di provare filtri con kernel di dimensioni grandicelle. Per darti un idea, la settimana prossima per ogni frammento potrei fare fino a 50/100 texture fetch...
DarKilleR
09-11-2005, 21:48
"Scot usciamo dalla curvatura" :sofico:
Non c'è che dire è mostruoso...considerando che poi questa sarà la base di partenza per il futuro R600...SBAW
yossarian
09-11-2005, 22:22
E su questi piccoli mostri gli shader tendono a diventare presto piuttosto lunghi e complessi. Giusto giocando un po' qui e un po' la' con l'X360, in una settimana lo shader che sto scrivendo per l'illuminazione ha sfondato le 100 istruzioni (il piu' lungo che ho scritto per bw2 era di 60 per l'acqua). E inizia a mettere un numero illimitato di luci per pixel, usa un kernel corposo per filtrare le shadow map e le istruzioni salgono.
Il bello di questa GPU e' che ancora non si sta sedendo, tanto che stiamo pensando di provare filtri con kernel di dimensioni grandicelle. Per darti un idea, la settimana prossima per ogni frammento potrei fare fino a 50/100 texture fetch...
ho l'impressione che ATi, quando parla di efficienza prossima al 95%, non è molto lontana dalla verità. Inoltre, un chip con le caratteristiche di R500, rispetto ai chip "tradizionali", riesce a mantenere un'elevata efficienza anche all'aumentare della complessità dei calcoli (come succede in parte con R520, che però non ha shader unificati, né eDRAM, né altre feature dell'R500), ma solo il pixel processor e il memory controller che hanno elementi in comune con il chip della xbox. Quindi, all'aumentare della complessità dei calcoli, risente molto poco del diminuire dell'efficienza, che porta al crollo delle prestazioni con rendering molto pesanti, alte risoluzioni e filtri attivi, tipico della vga a cui siamo solitamente abituati
OT: secondo te è possibile che il mio gatto sia high tech? Passa un mucchio di tempo davanti alla TV, è attratto dal pc e si mette a studiare la stampante quando è in funzione :D
yossarian
09-11-2005, 22:28
Quindi da R300 / NV30, giusto?
oui
Sulla maggiore velocità non ci sono dubbi, è il valore di 100 o 1000 volte maggiore che mi lascia un po' perplesso...
Una scheda come la X1800XT può vantare una banda di 40GB/sec, immaginare un qualcosa di così enormemente superiore mi stupisce! Anche per il discorso latenze, è vero che con la eDRAM si hanno latenze molto basse (tipo quelle delle cache L2 dei processori), però migliorare di 100 o 1000 volte rispetto a una veloce memoria VRAM mi pareva impossibile... :mbe:
Ciao. :)
non è un problema di bandwidth, (o meglio, non solo di quella). Funziona tipo le cache L1 e L2 delle cpu; sono registri a cui l'unità ha accesso diretto, senza dover inoltrare richieste e senza dover attendere la disponibilità del dato e del canale.
Free Gordon
10-11-2005, 00:03
hai ragione, si tratta di una domanda niubbissima :D
Grazie della spiegazione, maestro. :D
Solo ora comprendo l'ardua via che porta alla creazione di un'immagine 3d! :D
Ma non pensare di essere ormai al sicuro, ho un sacco di altre domande niubbissime da farti! :sofico:
yossarian
10-11-2005, 00:08
Grazie della spiegazione, maestro. :D
Solo ora comprendo l'ardua via che porta alla creazione di un'immagine 3d! :D
Ma non pensare di essere ormai al sicuro, ho un sacco di altre domande niubbissime da farti! :sofico:
sei il discepolo più niubbissimo che abbia mai avuto :D
Free Gordon
10-11-2005, 00:13
Alla fine del rendering vedrai che il fillrate non basta mai e, se ce ne fosse di piu', si potrebbe sempre implementare un altro effetto...
Ho capito perfettamente, grazie anche a te. ;)
Riguardo alla questione del fillrate che hai menzionato, Ati ha affermato più volte che R500 è un chip quasi del tutto privo di colli di bottiglia.
E' fisicamente possibile una cosa del genere secondo te? :D Osservando logicamente la cosa, dal punto di vista della risoluzione fissa (720p).
Free Gordon
10-11-2005, 00:14
sei il discepolo più niubbissimo che abbia mai avuto :D
Anche Luke Skywalker lo era. :sofico:
Ho capito perfettamente, grazie anche a te. ;)
Riguardo alla questione del fillrate che hai menzionato, Ati ha affermato più volte che R500 è un chip quasi del tutto privo di colli di bottiglia.
E' fisicamente possibile una cosa del genere secondo te? :D Osservando logicamente la cosa, dal punto di vista della risoluzione fissa (720p).
Beh non sono yoss :sofico: però a quanto ho capito/visto/letto il loop a 512bit ha dato un bel taglio al passato.
Questa è stata l'innovazione che ha tolto la maggior parte dei colli di bottiglia a questa si aggiunge ottimizzazioni varie edram,shader unificati...
[discorso ot dalla risposta....]
Normalmente la gente paragona direttamente le pipeline come fossero mhz delle cpu.
Ma come ati fa uscire solo 16 pipe ?
Nvidia ne ha già ora 24pipe sono troppo avanti !
(soliti commenti da flame di chi poco sà e guarda troppa pubblicità)
Come per le cpu un conto è la potenza della cpu un conto sono i mhz.
Quindi un conto è il numero delle pipeline un conto è la loro potenza.
Spiegazione per singola pipe:
R300 1 texture sample + 2 istruzioni matematiche
Nv32 2 texture + 3 mat
Nv40 1 texture + 4 mat
Vien da sè che difficilmente un nv40 a 8 pipe ha la stessa capacità di un r300 a 8 pipe così come hanno dimostrato che le 16pipe dell'r520 eguagliano le 24 del nuovo chip nvidia (ovviamente conta tanto anche l'architettura interna)
Ho capito perfettamente, grazie anche a te. ;)
Riguardo alla questione del fillrate che hai menzionato, Ati ha affermato più volte che R500 è un chip quasi del tutto privo di colli di bottiglia.
E' fisicamente possibile una cosa del genere secondo te? :D Osservando logicamente la cosa, dal punto di vista della risoluzione fissa (720p).
Mi sembra un'affermazione talmente generica che e' difficile da giudicare.
Il bello di questa GPU e' che ancora non si sta sedendo, tanto che stiamo pensando di provare filtri con kernel di dimensioni grandicelle. Per darti un idea, la settimana prossima per ogni frammento potrei fare fino a 50/100 texture fetch...
Poveretta sta GPU. Non è manco uscita e già la vuoi mettere in crisi.:D
eh, bisogna conoscerne i limiti prima di poterla sfruttare a fondo :D
Anche Luke Skywalker lo era. :sofico:
... anche Anakin lo era. .. ma guarda poi che fine ha fatto :D :D :D
Free Gordon
10-11-2005, 20:07
... anche Anakin lo era. .. ma guarda poi che fine ha fatto :D :D :D
Ma no, Anakin non era niubbo, è nato culato! Era già un mostro da piccolo! :D
Solo che poi si è seduto un pò... :sofico:
parla un super niubbo, che si sta studiando tutte le scehde video per passare ad una seria.
Io ho capito che l'architettura contamolto anche per i giochi,
soprattutto perché le due case ATI Nvidia, usano due architetture diverse non solo per le gpu, ma anche per i giochi che sponsorizzano, esempio perché DOOM3 va meglio con Nvidia che con ATI perché Doom 3 sfrutta i calcoli che fa la gpu nvidia, mentre ati fa calcoli diversi per (non so come dire) far vedere l'immagine.
So di non essermi spiegato benissimo, ma credo di essermi fatto capire
Dico questo dopo aver letto diecimila articoli.
da quel che ho capito se uno gioca a HL2 si prende ATI perché hl2 sfrutta i calcoli delle gpu ATI mentre la Nvidia si trova male a causa di calcoli diversi da parte delle sua gpu nei giochi di ati
Giusto :D
MiKeLezZ
10-11-2005, 22:00
Oppure compra una VGA che vada bene in entrambe.
Francamente da quando ho LCD guardo più alla risoluzione che userò e scelgo la scheda che mi garantisca un 40 fps con i filtri.
Riguardo alla questione del fillrate che hai menzionato, Ati ha affermato più volte che R500 è un chip quasi del tutto privo di colli di bottiglia.
E' un'affermazione che presenta nell'essere insensata il suo collo di bottiglia :D
Oppure compra una VGA che vada bene in entrambe.
Francamente da quando ho LCD guardo più alla risoluzione che userò e scelgo la scheda che mi garantisca un 40 fps con i filtri.
io ho un crt 17pollici e gioco sempre a 1024x768
ATI Has Been Testing R580 Since July – Sources. (http://www.xbitlabs.com/news/video/display/20051111144411.html)
:fiufiu:
Foglia Morta
13-11-2005, 18:39
ATI Has Been Testing R580 Since July – Sources. (http://www.xbitlabs.com/news/video/display/20051111144411.html)
:fiufiu:
mi sa che la tengono in laboratorio per farla salire per bene in frequenza e quando uscirà il G70 a 0.09 si farà il confronto
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.