considerazioni su G70 e R520

[yossarian]

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]]

Originariamente inviato da yossarian

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?

[Maury]

prima fila per me !!! quando inizia lo spattacolo che dopo cena devo uscire ?!

[yossarian]

Originariamente inviato da [Kendall]

fermi tutti... Vado a prendere i popcorn e poi torno... Ma siamo sicuri che venga Vaio?

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]]

Originariamente inviato da yossarian

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

[Murakami]

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...

[luckye]

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 ?)

[Maury]

Originariamente inviato da luckye

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

[Murakami]

Originariamente inviato da luckye

...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...
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...

[luckye]

Originariamente inviato da Murakami

Per quanto riguarda la codifica, temo che nessuno sappia ancora rispondere...
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...

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.

[fek]

Originariamente inviato da luckye

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.

[luckye]

Originariamente inviato da yossarian

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]

Originariamente inviato da luckye

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 è quanto ci è dato di sapere.
Mi sa che vaio-man me lo perdo, devo uscire a cena...

[luckye]

Originariamente inviato da fek

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.....

[fek]

Originariamente inviato da luckye

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...............

[luckye]

Originariamente inviato da fek

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

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

[yossarian]

Originariamente inviato da fek

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

[luckye]

Originariamente inviato da yossarian

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...

[fek]

Originariamente inviato da luckye

Eccoti il link

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).

[fek]

Originariamente inviato da yossarian

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?