Pixel & Vertex Shaders 3.0 su Kyro? [Archivio]

pandyno

29-05-2003, 22:35

PowerVR KYRO Coming Here With Pixel Shaders 3.0 and Vertex Shaders 3.0

To Blast ATI and NVIDIA?
by Anton Shilov
05/29/2003 | 06:34 AM

Developers from PowerVR were noted as authors of articles about Pixel Shaders 3.0 and Vertex Shaders 3.0 in an upcoming book dedicated to 3D graphics. This may mean that PowerVR is still in the graphics business and will launch something massive and powerful possibly this year, as noted by Beyond3D.

The book &#8220;ShaderX2&#8221; covers many topics related to 3D graphics from rendering certain specific effects to DirectX 9.0 HLSL programming. What is definitely interesting to note that there are four contributions from the PowerVR employees: &#8220;Deferred Shading with Multiple Render Targets&#8221;, &#8220;Introduction to the vs_3_0 and ps_3_0 Shader Models&#8221;, &#8220;Cloth Animation with Pixel and Vertex Shader 3.0&#8221; and &#8220;Rendering Voxel Objects with ps_3_0&#8221;.

There is no point for employees of a hardware company to write articles about things that have nothing to do with reality. I believe that PowerVR personnel have already started to promote techniques that will be implemented in the next-generation hardware from the company.

Last year I heard that PowerVR cancelled the development of its Kyro III and derivatives, but decided to go on with the so-called Series 5 of its graphics processors. Considering the topics covered by the mentioned articles we can assume that the PowerVR Series 5 chips will support Pixel Shader 3.0 and Vertex Shader 3.0 in hardware. In case the chip is physically launched in 2003, PowerVR may be in a position to offer the first graphics processor with Pixel Shader 3.0 and Vertex Shader 3.0 support. At least, last year an official from the company said that they would launch its Series 5 GPU this year.

We still do not know anything about manufacturing technology, manufacturing partner and performance of the chip. It may be very capable, but a bit slow, in this case it will hardly become successful and we will have to wait for its second revision with boosted speed, just like it happened in 2000 and 2001 with the Kyro and Kyro II. Furthermore, ATI Technologies and NVIDIA Corporation certainly do not want their partners to manufacture graphics cards based on graphics chips from third parties, so, there is a bunch of work for marketing people from PowerVR.

Read the whole topic on the matter with loads of assumptions over here at Beyond3D.

Cosimo

29-05-2003, 22:35

Originally posted by "V|RuS[X

"]

404: not found
The page you requested could not be found on this server. Try to find the article you need using a search form or site map.

Cmq aprendo il sito di xbitlabs.com nella sezione news non ho visto niente di ciò.

come no? http://www.xbitlabs.com/news/video/display/20030529063322.html

A me il link funziona perfettamente, parla della nuova GPU di kyro.. Ma se non puoi vedere faremo una cosa...

PowerVR KYRO Coming Here With Pixel Shaders 3.0 and Vertex Shaders 3.0

To Blast ATI and NVIDIA?
by Anton Shilov
05/29/2003 | 06:34 AM

Developers from PowerVR were noted as authors of articles about Pixel Shaders 3.0 and Vertex Shaders 3.0 in an upcoming book dedicated to 3D graphics. This may mean that PowerVR is still in the graphics business and will launch something massive and powerful possibly this year, as noted by Beyond3D.

The book “ShaderX2” covers many topics related to 3D graphics from rendering certain specific effects to DirectX 9.0 HLSL programming. What is definitely interesting to note that there are four contributions from the PowerVR employees: “Deferred Shading with Multiple Render Targets”, “Introduction to the vs_3_0 and ps_3_0 Shader Models”, “Cloth Animation with Pixel and Vertex Shader 3.0” and “Rendering Voxel Objects with ps_3_0”.

There is no point for employees of a hardware company to write articles about things that have nothing to do with reality. I believe that PowerVR personnel have already started to promote techniques that will be implemented in the next-generation hardware from the company.

Last year I heard that PowerVR cancelled the development of its Kyro III and derivatives, but decided to go on with the so-called Series 5 of its graphics processors. Considering the topics covered by the mentioned articles we can assume that the PowerVR Series 5 chips will support Pixel Shader 3.0 and Vertex Shader 3.0 in hardware. In case the chip is physically launched in 2003, PowerVR may be in a position to offer the first graphics processor with Pixel Shader 3.0 and Vertex Shader 3.0 support. At least, last year an official from the company said that they would launch its Series 5 GPU this year.

We still do not know anything about manufacturing technology, manufacturing partner and performance of the chip. It may be very capable, but a bit slow, in this case it will hardly become successful and we will have to wait for its second revision with boosted speed, just like it happened in 2000 and 2001 with the Kyro and Kyro II. Furthermore, ATI Technologies and NVIDIA Corporation certainly do not want their partners to manufacture graphics cards based on graphics chips from third parties, so, there is a bunch of work for marketing people from PowerVR.

Adesso si :D

MaBru

29-05-2003, 22:42

Originally posted by "Cosimo"

Letti, allora possiamo vedere che DX 9.0 Supporta anche le versioni 3.0 non lo sapevo propio, ma questa features dipende dei DX? O della programmabilità della GPU?

La versione 3.0 permette istruzioni più lunghe ed un miglior controllo di esse. Se anche l'hardware la supporta sei a cavallo, in caso contrario credo che si possano emulare in multipassata con un evidente e anche logico brusco calo di prestazioni.

Ciao

Vifani

29-05-2003, 22:55

Secondo alcune informazioni rilasciate l'anno scorso sembra che PowerVR abbia deciso di saltare la Serie 4 e di passare direttamente alla Serie 5 il cui lancio è previsto entro la fine dell'anno.

Negli ultimi giorni sono stati pubblicati diversi documenti sul "ShaderX 2 3D techniques and programming book", una specie di punto di riferimento per i programmatori Direct 3D nel quale molti dipendenti di PowerVR Technologies hanno dato il loro contributo. Parliamo pricipalmente di Kristof Beets che è uno degli ingegneri alla base degli algoritmi matematici della tecnologia di PowerVR Technologies. I documenti sono i seguenti: "Deferred Shading with Multiple Render Targets", "Introduction to the vs_3_0 and ps_3_0 Shader Models", "Cloth Animation with Pixel and Vertex Shader 3.0" e "Rendering Voxel Objects with ps_3_0".

Inoltre nel discorso di fine anno fiscale Imagination Technologies (di cui PowerVR è una divisione) ha dichiarato di lavorare assiduamente per il lancio di un prodotto "high-end", cioè di fascia alta, all'interno del mercato PC.

Il tutto ha fatto presumere alla stampa che PowerVR sia sul punto di lanciare la quindi generazione della sua tecnologia (Serie 5) e che la cosa avverrà sicuramente entro la fine dell'anno.

Purtroppo non si conosce ancora chi sarà il produttore di chip grafici basati sulla tecnologia PowerVR Serie 5 (ricordo che PowerVR non produce chip, ma solo licenze tecnologiche) tanto meno si hanno dati sulle prestazioni di questo futuro prodotto.

checo

29-05-2003, 23:30

bene bene

yossarian

30-05-2003, 00:06

Originally posted by "MaBru"

La versione 3.0 permette istruzioni più lunghe ed un miglior controllo di esse. Se anche l'hardware la supporta sei a cavallo, in caso contrario credo che si possano emulare in multipassata con un evidente e anche logico brusco calo di prestazioni.

Ciao

Utilizza un algoritmo con un'istruzione di looping, analogo a quello utilizzato per effettuare multitexturing e a quello studiato alla Stanford e che è stato denominato F-Buffer.
Come ha detto MaBru, nel caso l'HW non supporti questa funzione, esattamente come avviene per il multitexturing, lo stesso risultato viene ottenuto, anzichè in singola passata, in multipassata, con ovvio calo delle prestazioni.
Non c'è da meravigliarsi se veramente PowerVR dovesse implementare il supporto per i PS3 e i VS3, visto che già nel Kyro2 si era fatto largo uso di buffer interni (TBR e multitexturing con 8 textures per single pass).
Rispetto alla versione 2 dei PS e dei VS non è una rivoluzione ma una semplice evoluzione di tipo quantitativo che non comporterà neppure grandi rivoluzioni nell'adeguamento degli attuali chip di fascia alta.

DragonWizard

30-05-2003, 17:48

Ma la notizia è sicura già? Speriamo...vedremo nuovi concorrenti!!

A proposito, di DeltaForce niente? Ma ke dorme S3???!!!

Xilema

30-05-2003, 19:03

Con questa storia dei pixel & vertex shaders 3.0 siamo davvero giunti al ridicolo...
Deve ancora uscire un gioco che sia uno che sfrutti i 2.0 (per fortuna prossimamente ci saranno Half life 2, Doom 3, Far cry e Stalker a farlo...) e già si parla di 3.0 ?!?!
Bella buffonata, è ora che si comincino ad usare tutte le tecnologie presenti ORA sul mercato, come il dot3 bump davvero poco usato... e presente e disponibile già da diversi anni... e i pixel e vertex shaders 1.0 e 2.0 invece di farneticare sui 3.0 !
Altrimenti tutti questi effetti diventano un puro e semplice esercizio di stile dialettico per decantare le lodi di questa o quella scheda video...

MaBru

30-05-2003, 19:14

Originally posted by "Xilema"

Con questa storia dei pixel & vertex shaders 3.0 siamo davvero giunti al ridicolo...
Deve ancora uscire un gioco che sia uno che sfrutti i 2.0 (per fortuna prossimamente ci saranno Half life 2, Doom 3, Far cry e Stalker a farlo...) e già si parla di 3.0 ?!?!
Bella buffonata, è ora che si comincino ad usare tutte le tecnologie presenti ORA sul mercato, come il dot3 bump davvero poco usato... e presente e disponibile già da diversi anni... e i pixel e vertex shaders 1.0 e 2.0 invece di farneticare sui 3.0 !
Altrimenti tutti questi effetti diventano un puro e semplice esercizio di stile dialettico per decantare le lodi di questa o quella scheda video...

E' quello che sostengo io da tempo. Se si pensa che i giochi che sfruttano a fondo le DirectX 7 si possono contare su una mano (o al massimo due) viene veramente da rabbrividire...

Speriamo veramente che le DirectX 9 durino fino al 2005 come promesso da microsoft :mc:

Ciao

conan_75

30-05-2003, 20:59

Originally posted by "MaBru"

E' quello che sostengo io da tempo. Se si pensa che i giochi che sfruttano a fondo le DirectX 7 si possono contare su una mano (o al massimo due) viene veramente da rabbrividire...

Speriamo veramente che le DirectX 9 durino fino al 2005 come promesso da microsoft :mc:

Ciao

Ci puoi contare!
Ma ora come ora quali sono i giochi che usano Dx8.1?
Mi pare ci sia Rallisport (e si vede), poi Splinter Cell parzialmente (almeno credo), poi?
UT2003 e U2 che hanno il nuovo motore 3D che verrà usato in tantissimi giochi futuri non è nemmeno full DX7.
Doom3 che uscirà l'anno prossimo userà i PS 1.x già visti nella alpha e anche gli altri giochi elencati da Xilema dovrebbero usare PS 1.x.
Per utilizzare i PS 2.x l'unica cosa è il test 4 del 3Dmark 2003 :muro: :muro:

Hanamichi

30-05-2003, 22:33

Originally posted by "conan_75"

Ci puoi contare!
Ma ora come ora quali sono i giochi che usano Dx8.1?
Mi pare ci sia Rallisport (e si vede), poi Splinter Cell parzialmente (almeno credo), poi?
UT2003 e U2 che hanno il nuovo motore 3D che verrà usato in tantissimi giochi futuri non è nemmeno full DX7.
Doom3 che uscirà l'anno prossimo userà i PS 1.x già visti nella alpha e anche gli altri giochi elencati da Xilema dovrebbero usare PS 1.x.
Per utilizzare i PS 2.x l'unica cosa è il test 4 del 3Dmark 2003 :muro: :muro:

i giochi che supportono le direct x 8 sono abbastanza: MOTO GP, RALLY SPORT, SPLINTER CELL UT 2003 e U2 usano le direct x 8! :p ;)

DoomIII

30-05-2003, 23:23

Originally posted by "Hanamichi"

i giochi che supportono le direct x 8 sono abbastanza: MOTO GP, RALLY SPORT, SPLINTER CELL UT 2003 e U2 usano le direct x 8! :p ;)

usare le DX8 nn significa implementare le funzioni 'avanzate' nello specifico vertex&pixel shader.
difatti nelle Dx8 sono disponibili chiamate T&L per cui DX8 non è automaticamente sinonimo di vertex&pixel shader.

L'engine di unreal ad esempio è pesantemente T&L... altro che DX8... :o

Xilema

30-05-2003, 23:35

Originally posted by "conan_75"

Ci puoi contare!
Ma ora come ora quali sono i giochi che usano Dx8.1?
Mi pare ci sia Rallisport (e si vede), poi Splinter Cell parzialmente (almeno credo), poi?
UT2003 e U2 che hanno il nuovo motore 3D che verrà usato in tantissimi giochi futuri non è nemmeno full DX7.
Doom3 che uscirà l'anno prossimo userà i PS 1.x già visti nella alpha e anche gli altri giochi elencati da Xilema dovrebbero usare PS 1.x.
Per utilizzare i PS 2.x l'unica cosa è il test 4 del 3Dmark 2003 :muro: :muro:

Stalker userà sicuramente i 2.0, gli altri forse gli 1.0 e comunque... vedere oggi un gioco che usa contemporaneamente dot 3 e pixel/vertex shaders... fa davvero gridare al miracolo !

Jaguar64bit

30-05-2003, 23:39

Se esce un chip Kyro conpatibile con la Dx9.........addio Ati e Nvidia , il problema e' SE esce........ :D

Vifani

30-05-2003, 23:55

Originally posted by "Jaguar64bit"

Se esce un chip Kyro conpatibile con la Dx9.........addio Ati e Nvidia , il problema e' SE esce........ :D

Sono d'accordo. Il problema non è di certo la validità del prodotti PowerVR, ma quando uscirà.

Comunque mi sembra che ormai sia chiaro a tutti che il discorso di supportare nuove tecnologie sia una cosa del tutto distinta dall'averne effettivamente bisogno. E' solo una battaglia tecnologia. Il resto è nulla.

Le uniche funzioni interessanti oggi di schede come le 9700/9800 e 5800/5900 è il poter utilizzare sempre l'antialiasing.... cioè l'unica funzione che non richiede ottimizzazione specifica. Il resto è solo una battaglia tra concorrenti.

Jaguar64bit

31-05-2003, 00:35

Originally posted by "Vifani"

Sono d'accordo. Il problema non è di certo la validità del prodotti PowerVR, ma quando uscirà.

Comunque mi sembra che ormai sia chiaro a tutti che il discorso di supportare nuove tecnologie sia una cosa del tutto distinta dall'averne effettivamente bisogno. E' solo una battaglia tecnologia. Il resto è nulla.

Le uniche funzioni interessanti oggi di schede come le 9700/9800 e 5800/5900 è il poter utilizzare sempre l'antialiasing.... cioè l'unica funzione che non richiede ottimizzazione specifica. Il resto è solo una battaglia tra concorrenti.

Io ho sempre apprezzato i chip con tecnologia PowerVr , sono molto affezzionato alla Kyro 2 , la qualita' grafica di questa scheda e' eccezzionale , anche io come tu hai detto sostengo che se x assurdo questo chip non fosse vincolato dalle Dx , ma fosse sfruttato come disse un programmatore giapponese , "a cuore aperto" , regalerebbe miracoli grafici.....e gia' col Dreamcast si era intravvisto "qualcosa"........se dovesse uscire un Kyro3 avrebbe di sicuro successo x me' , la tecnologia del Hsr e del Tile based Rendering e' all'avanquardia....x me'...

danige

31-05-2003, 00:46

Ragazzi ma di cosa state parlando ? in quella pagina si dice solamente che verrà presto presentato un libro dal nome ShaderX2 che parlerà di programmazione in 3D e ci sarà anche il capitolo su Pixel Shaders e Vertex Shader 3.0 scritti da 2 dipendenti di Power Vr tutto qui! nessun nuovo chip o Kyro III in quel libro ci sono anche numerose parti scritte da tecnici Trident e di altre case, non vuol dire nulla :)

Vifani

31-05-2003, 01:17

Ma infatti non si parla di certezze, ma di rumours.

PowerVR l'anno scorso ha dichiarato ufficialmente che quest'anno avrebbe presentato la Serie 5. PowerVR qualche giorno fa ha rilasciato il commento all'anno fiscale appena concluso dicendo che vuole entrare nel mercato PC high-end. PowerVR ha rilasciato da breve nuovi driver Kyro (cosa che non faceva guarda caso dalla presentazione del Kyro II SE) e Kristof Beets, una delle menti di PowerVR, in tutti i suoi discorsi ci ha sempre messo i VS e PS 3.0.

La stampa ha semplicemente messo insieme tutte queste cose... la verità solo il tempo ce la dirà.

Jaguar64bit

31-05-2003, 01:39

so solo questo....[/siz]

Dark Schneider

31-05-2003, 02:17

Beh veramente Ati e nVidia non resterebberò di certo a guardare, anzi...
Ovviamente ben venga perchè più concorrenza c'è meglio è per noi.

yossarian

31-05-2003, 02:28

http://forum.hwupgrade.it/faccine/42.gif

Fai il serio. Al ritmo attuale, non è facendo uscire un chip, per quanto buono possa essere, ogni due o tre anni, che mandi a zappare i dipendenti ATI e nVIDIA.

:sofico:

Spike

31-05-2003, 03:31

Non vorrei dire una cazzata (sono poco aggiornato) ma che io sappia la tecnologia tile based di powervr è ancora l'unica che sfrutta la rimozione dei poligoni non visibili e che quindi non vengono nè texturizzati nè interessati da tutte le successive operazioni di rendering (quindi ipoteticamente anche i pixel shader). Ati e Nvidia hanno solo dei sistemi di rimozione dei pixel non visibili solo per diminuire la banda passante richiesta.
E' vero ciò che dico?

Vifani

31-05-2003, 08:35

Originally posted by "Spike"

Non vorrei dire una cazzata (sono poco aggiornato) ma che io sappia la tecnologia tile based di powervr è ancora l'unica che sfrutta la rimozione dei poligoni non visibili e che quindi non vengono nè texturizzati nè interessati da tutte le successive operazioni di rendering (quindi ipoteticamente anche i pixel shader). Ati e Nvidia hanno solo dei sistemi di rimozione dei pixel non visibili solo per diminuire la banda passante richiesta.
E' vero ciò che dico?

Esatto. Diciamo che la tecnologia PowerVr renderizza la scena così come lo fa il GeForce fx 5900 Ultra nel 3D Mark 2003 non patchato con gli ultimi Detonator: non effettua i calcoli sulle superfici non visibili. La differenza è che i chip PowerVR effettuano questa operazione in hardware e sempre, mentre nVidia ha sfruttato il fatto di conoscere a priori il percorso del punto di osservazione per determinare cosa non elaborare e cosa elaborare (una cosa simile non sarebbe possibile in un gioco per il GeForce).

Teoricamente il chip PowerVR sarebbe molto avvantaggiato a parità di caratteristiche tecniche rispetto alle controparti ATi e nVidia visto che più andiamo avanti e più le scene 3D diventano complesse e conseguentemente più superfici nascoste diventano numerose.

Chi vivrà, vedrà.

Crisidelm

31-05-2003, 10:54

/me ridacchia sotto i baffi :rolleyes:
BTW, non aspettatevi che venga chiamata "KyroIII"...il nome Kyro era stato registrato da STM ai tempi...

Jaguar64bit

31-05-2003, 11:32

Mi chiedo del perche' ne Ati ne Nvidia hanno cercato di riprodurre la tecnologia del'HSR e TBR , che se pur molto complessa da sviluppare tecnicamente, se portata a livelli alti di sofisticazione , puo' fare miracoli , e gia' con il Kyro 2 si era intravisto qualcosa , non dimentichiamo che l' AA del Kyro era molto buono e aveva un'ottimo livello qualitativo , inoltre il Kyro gia' due anni fa' poteva mostrare 8 texture a video x singola passata , quando anche oggi molte schede 3d non possono permetterselo.

Xtian

31-05-2003, 13:10

Originally posted by "Jaguar64bit"

Mi chiedo del perche' ne Ati ne Nvidia hanno cercato di riprodurre la tecnologia del'HSR e TBR , che se pur molto complessa da sviluppare tecnicamente, se portata a livelli alti di sofisticazione , puo' fare miracoli , e gia' con il Kyro 2 si era intravisto qualcosa , non dimentichiamo che l' AA del Kyro era molto buono e aveva un'ottimo livello qualitativo , inoltre il Kyro gia' due anni fa' poteva mostrare 8 texture a video x singola passata , quando anche oggi molte schede 3d non possono permetterselo.
In realta' sia nvidia (grazie a gigapixel) che ati (grazie ad artx) hanno brevetti sul tipo TBR; il problema e' che non si sa quando li utilizzeranno.

Xilema

31-05-2003, 14:10

Il nome e la qualità intrinseca di ATI e NVidia sono ormai conosciuti, anche se uscisse una nuova Kiro... avrebbe poco successo, perchè ormai i programmatori prendono i catalyst e i detonator come i 2 modelli principlai sui quali creare e ottimizzare i propri giochi.
E francamente... ATI e nVidia non resterebbero di certo a guardare, buttando fuori nel giro di pochissimo chipset in grado di surclassare la Kiro 3 di turno: hanno troppo potere economico e decisionale...
Lasciano perdere questi discorsi, quello che voglio continuare a sottolineare è il fatto che non c' è assolutamente il bisogno di nuove tecnologie grafiche: guardando i filmatini di Half life 2 si capisce che ormai il fuoco è identico al fuoco reale, l' acqua pure, i vari materiali idem... insomma, le tecnologie ci sono, basta volerle implementare !
E quelli della Valve (che sono bravi programmatori) hanno capito che la vera differenza si fa usando tutte quelle features (che anche oggi stesso potrebbero essere utilizzate da qualsiasi programmatore decente per creare videogiochi talmente spettacolari da non poterli nemmeno immaginare) che vedremo appunto applicate in HL2 !
E' ora di finirla con le CPU da milioni di hertz, è ora che i programmatori comincino a svegliarsi per creare giochi che sfruttino al massimo le nostre fottutissime e costosissime schede video e non si appoggino in modo esasperato alla CPU (chi ha detto Unreal 2 ?).
La vera rivoluzione sarà quella di capire che i videogiochi devono basarsi per 70 % sulla scheda video e per il resto sulla CPU, non viceversa !

yossarian

31-05-2003, 14:20

Il TBR, dal punto di vista funzionale non differisce dagli altri metodi di HSR. Nessun chip dotato di algoritmo di HSR renderizza le superfici nascoste; la rimozione dei poligoni nascosti avviene dopo il processo di trasformazione, ossia di calcolo delle posizioni dei vertici prsenti in ogni tile o tessera che dir si voglia. In seguito, i dati relativi alle posizioni dei vertici visibili vengono trasferiti alle pipelines di rendering per il processo di texturizzazione. La differenza fondamentale è che la tecnologia PowerVR utilizza una cache interna al chip per stivare i dati relativi ai vertici dei poligoni di ogni tessera, mentra gli altri, per lo stesso scopo, utilizzano la ram video. Questo significa che i dati relativi ai vertici non compiono il viaggio di andata e ritorno tra chip e ram video ma vengono direttamente trasferiti alle pipelines di rendering per essere texturizzati. La conseguenza è che, come dice Vifani, una volta che i dati relativi alla singola tessera escono dal chip, sono già completi (sono già stati effettuato sia il clipping che la texturizzazione), con notevole risparmio della banda passante e maggior velocità d'elaborazione (si salta, rispetto al sistema tradizionale il passaggio dei dati relativi ai vertici, come detto, dal chip alla ram e dalla ram al chip (sezione relativa ai PS))

yossarian

31-05-2003, 14:23

Originally posted by "Xilema"

Il nome e la qualità intrinseca di ATI e NVidia sono ormai conosciuti, anche se uscisse una nuova Kiro... avrebbe poco successo, perchè ormai i programmatori prendono i catalyst e i detonator come i 2 modelli principlai sui quali creare e ottimizzare i propri giochi.
E francamente... ATI e nVidia non resterebbero di certo a guardare, buttando fuori nel giro di pochissimo chipset in grado di surclassare la Kiro 3 di turno: hanno troppo potere economico e decisionale...
Lasciano perdere questi discorsi, quello che voglio continuare a sottolineare è il fatto che non c' è assolutamente il bisogno di nuove tecnologie grafiche: guardando i filmatini di Half life 2 si capisce che ormai il fuoco è identico al fuoco reale, l' acqua pure, i vari materiali idem... insomma, le tecnologie ci sono, basta volerle implementare !
E quelli della Valve (che sono bravi programmatori) hanno capito che la vera differenza si fa usando tutte quelle features (che anche oggi stesso potrebbero essere utilizzate da qualsiasi programmatore decente per creare videogiochi talmente spettacolari da non poterli nemmeno immaginare) che vedremo appunto applicate in HL2 !
E' ora di finirla con le CPU da milioni di hertz, è ora che i programmatori comincino a svegliarsi per creare giochi che sfruttino al massimo le nostre fottutissime e costosissime schede video e non si appoggino in modo esasperato alla CPU (chi ha detto Unreal 2 ?).
La vera rivoluzione sarà quella di capire che i videogiochi devono basarsi per 70 % sulla scheda video e per il resto sulla CPU, non viceversa !

Esatto; i giochi dovrebbero sfruttare esclusivamente la scheda video per la sezione grafica, appoggiandosi alla cpu solo per altre operazioni (IA ecc.)

Cosimo

31-05-2003, 14:25

Non capisco perche ancora esiste tanta gente che sta in contro della evoluzione ai 3.0 :rolleyes:
Sono d'accordo che non esiste cuasi nemmeno un gioco che sfrutti le 2.0, ma ragazzi... Questa è l'evoluzione! Io ancora ricordo quelli che dicevano che con le DX 6 Bastava tutto.... :rolleyes:

Credo che sia buono che si studino nuove maniere di programmare i pixel ei vertex shaders, e che dopo ogni programmatore sfrutti quelle che più gli interessa. Così i produttori di GPU hanno tempo per creare nuovi chip capaci di sfruttare questa nuova versione che di sicuro offrirà benefici sostanziali, tanto in performance come in qualità grafica.

yossarian

31-05-2003, 14:36

Originally posted by "Cosimo"

Non capisco perche ancora esiste tanta gente che sta in contro della evoluzione ai 3.0 :rolleyes:
Sono d'accordo che non esiste cuasi nemmeno un gioco che sfrutti le 2.0, ma ragazzi... Questa è l'evoluzione! Io ancora ricordo quelli che dicevano che con le DX 6 Bastava tutto.... :rolleyes:

Credo che sia buono che si studino nuove maniere di programmare i pixel ei vertex shaders, e che dopo ogni programmatore sfrutti quelle che più gli interessa. Così i produttori di GPU hanno tempo per creare nuovi chip capaci di sfruttare questa nuova versione che di sicuro offrirà benefici sostanziali, tanto in performance come in qualità grafica.

Il problema è che, mentre con l'evoluzione dei chip, siamo arrivati alle DX9, con quella del SW siamo ancora alle DX7 con qualche contaminazione DX8 (v., ad esempio Morrowind). E' inutile andare troppo avanti se, come ha detto più di qualcuno, questi progressi non vengono sfruttati a dovere da chi produce i giochi o le applicazioni che dovrebbero beneficiare (in teoria) di questi progressi.

Jaguar64bit

31-05-2003, 14:57

Originally posted by "yossarian"

Il problema è che, mentre con l'evoluzione dei chip, siamo arrivati alle DX9, con quella del SW siamo ancora alle DX7 con qualche contaminazione DX8 (v., ad esempio Morrowind). E' inutile andare troppo avanti se, come ha detto più di qualcuno, questi progressi non vengono sfruttati a dovere da chi produce i giochi o le applicazioni che dovrebbero beneficiare (in teoria) di questi progressi.

Infatti , pensa che io sostengo che le possibilita' del chip KYRO2 sono state sfruttate al 30%.....fai un po' te'.....altro che Dx9...., ultimamente ho visto giochi nuovissimi avere una grafica che non sfrutta neanche al 50% una scheda come il Kyro 2 , che ha un EBM da spavento , e di bump mapping non ne vedo molto in giro.....altro che Vertex e Pixser Shader....

Jaguar64bit

31-05-2003, 15:02

x me' una Radeon 9700 e' sfruttata al 10% a dir tanto.... :rolleyes:

V|RuS[X]

31-05-2003, 15:04

Originally posted by "Jaguar64bit"

x me' una Radeon 9700 e' sfruttata al 10% a dir tanto.... :rolleyes:

Perchè dici che è sfruttata solo un decimo del suo potenziale? :confused:

Cosimo

31-05-2003, 15:07

Originally posted by "Jaguar64bit"

x me' una Radeon 9700 e' sfruttata al 10% a dir tanto.... :rolleyes:
Eddai raga... Ora stiamo esaggerando :rolleyes: Dire che le tecniche di ottimizzazione non sono raffinate, e che si potrebbe andare molto più in la è un fatto... (Vedi Dreamcast) Ma da qui, a dire che la raddy non è sfruttata ne al 10%... A che ti basi? Dove trovi questi dati?

Jaguar64bit

31-05-2003, 15:12

Originally posted by "Cosimo"

Eddai raga... Ora stiamo esaggerando :rolleyes: Dire che le tecniche di ottimizzazione non sono raffinate, e che si potrebbe andare molto più in la è un fatto... (Vedi Dreamcast) Ma da qui, a dire che la raddy non è sfruttata ne al 10%... A che ti basi? Dove trovi questi dati?

Pensa se fosse montata su di una console.....

Cosimo

31-05-2003, 15:16

Originally posted by "Jaguar64bit"

Pensa se fosse montata su di una console.....

Gioca a 640x480 sensa filtri e con un gioco fatto esclusivamente per il tuo pc. Allora dimmi.

Jaguar64bit

31-05-2003, 15:19

Originally posted by "V|RuS[X

"]

Perchè dici che è sfruttata solo un decimo del suo potenziale? :confused:

Chi viene dal mondo pc a volte non sa' bene cosa vuol dire ottimizzazione , o sfruttamento totale di un'hardware , come ho gia' scritto un famaso programmatore giapponese della Tecmo , ha detto che x sfruttare completamente le possibilita' di un'certo hardware bisogna programmare il chip "a cuore aperto" , senza i vincoli delle Dx e delle OpenGL che saranno anche librerie libere , ma x me' pongono dei limiti di programmazione , molti cadranno dalle nuvole a sentirmi fare questo discorso......ma credetemi , in campo pc l'hardware e' sfruttato pochissimo.....

V|RuS[X]

31-05-2003, 15:50

Originally posted by "Jaguar64bit"

Chi viene dal mondo pc a volte non sa' bene cosa vuol dire ottimizzazione , o sfruttamento totale di un'hardware , come ho gia' scritto un famaso programmatore giapponese della Tecmo , ha detto che x sfruttare completamente le possibilita' di un'certo hardware bisogna programmare il chip "a cuore aperto" , senza i vincoli delle Dx e delle OpenGL che saranno anche librerie libere , ma x me' pongono dei limiti di programmazione , molti cadranno dalle nuvole a sentirmi fare questo discorso......ma credetemi , in campo pc l'hardware e' sfruttato pochissimo.....

Capisco bene cosa vuoi dire, ma non è applicabile mica a questo discorso ma a tutto nel panorama dell'hardware/software moderno.

Prova a prendere un "vecchio" celeron 400mhz e facci girare su BeOS e vedrai come per magia che andrà più veloce del tuo ultimo Barton con su WindoZ ;)

E poi perchè anche solo un programma che mi genera il codice fiscale deve essere di ben 10mega byte quando lo si potrebbe scrivere in meno di 200 kappa byte? :confused:

Ma è un trend inarrestabile secondo me.

conan_75

31-05-2003, 17:39

Originally posted by "Hanamichi"

i giochi che supportono le direct x 8 sono abbastanza: MOTO GP, RALLY SPORT, SPLINTER CELL UT 2003 e U2 usano le direct x 8! :p ;)

Usare le Dx8 per me significa usare i PS 1.x e VS 1.1 e gli effetti di vario tipo tipici delle librerie DX8 e non che necessitano dell'installazione forzata delle Dx8, ma alla fine non usi nemmeno il T&L.
Questo avviene in pochissimi giochi, e a colpo d'occhio direi solo Rallisport.
Dubito fortemente pure di MotoGP.
Assolutamente non UT2k3 e UT2 che non sfruttano nemmeno gli effetti DX7 come bump mapping e DOT3 oltre che al famigerato T&L con cui ci hanno spaccato le pa@@e dal tempo della GF256.
Vedere che ancora oggi queste tecnologie non vengono sfruttate a circa 4 anni dalla loro uscita ci fà capire quando mai vedremo giochi full DX9.
Proprio il motore di UT2003 è l'esempio dello spreco di risorse + totale con un'utilizzo enorme di CPU e texture pesantissime, quando con l'utilizzo delle DX8 o almeno Full DX7 avremmo avuto un gioco + leggero e + bello graficamente.

Crisidelm

31-05-2003, 18:32

Un'altra cosuccia: gli Stencil. Già il KyroII, che è pur ormai una scheda ben vecchia, era anni avanti rispetto alle schede video sue contemporanee al riguardo degli Stencil (Shadow Volume: e sapete quale prossimo giochino dovrebbe farne largo uso, no?): se 2+2 fa 4, direi che un eventuale chip Series 5 brucerebbe qualsiasi altra scheda video presente in commercio al riguardo...

conan_75

31-05-2003, 20:49

Sapete come si dice: tra il dire e il fare c'è il mare ;)

Vifani

31-05-2003, 23:53

Originally posted by "yossarian"

Il TBR, dal punto di vista funzionale non differisce dagli altri metodi di HSR. Nessun chip dotato di algoritmo di HSR renderizza le superfici nascoste; la rimozione dei poligoni nascosti avviene dopo il processo di trasformazione, ossia di calcolo delle posizioni dei vertici prsenti in ogni tile o tessera che dir si voglia. In seguito, i dati relativi alle posizioni dei vertici visibili vengono trasferiti alle pipelines di rendering per il processo di texturizzazione. La differenza fondamentale è che la tecnologia PowerVR utilizza una cache interna al chip per stivare i dati relativi ai vertici dei poligoni di ogni tessera, mentra gli altri, per lo stesso scopo, utilizzano la ram video. Questo significa che i dati relativi ai vertici non compiono il viaggio di andata e ritorno tra chip e ram video ma vengono direttamente trasferiti alle pipelines di rendering per essere texturizzati. La conseguenza è che, come dice Vifani, una volta che i dati relativi alla singola tessera escono dal chip, sono già completi (sono già stati effettuato sia il clipping che la texturizzazione), con notevole risparmio della banda passante e maggior velocità d'elaborazione (si salta, rispetto al sistema tradizionale il passaggio dei dati relativi ai vertici, come detto, dal chip alla ram e dalla ram al chip (sezione relativa ai PS))

Il discorso non è proprio così. Il rendering tradizionale che viene effettuato dalle schede GeForce, Radeon e Matrox parte dal presupposto che l'immagine renderizzata sia 3D. La tecnologia PowerVR ed in particolare il Deferred Texturing (che è una cosa diversa dal Tile Based Rendering) invece tratta tutte le informazioni tenendo conto che indipendentemente dalla profondità della scena, dalla quantità di poligoni e di superfici alla fine, visto che l'immagine deve essere visualizzata su una superficie 2D (il monitor), comunque potrà essere visualizzato solo 1 texel (cioè un elemento di una texture) per pixel dello schermo.

I passi li ho spiegati più di una volta in passato. I chip PowerVR sconvolgono quello che è il normale processo di rendering (immediate rendering) andando a memorizzarsi le informazioni relative alla geometria della scena. A questo punto, sapendo quali superfici saranno nascoste e quali visibili, applicano le texture solo a quelle visibili. Naturalmente visto che sarebbe troppo pesante gestire le informazioni relative alla geometria di tutto lo schermo, si usa la suddivisione in Tile (Tile Based Rendering) per trattare una minore quantità di informazioni alla volta.

Le schede GeForce e Radeon, invece, prima applicano tutte le texture a tutte le superfici dopodiché usano lo Z-buffer per determinare quale texel visualizzare e quali no. E' proprio questo test della profondità a posteriori che li rende poco efficienti. I vari metodi di HSR di ATi e nVidia servono ad ottimizzazione alcune operazioni ma si basano comunque su una base di rendering classica. Solo il Deferred Texturing, usando algoritmi alla cui base ci sono le "infinite splines" (una spline è un concetto matematico, una funzione, che per brevità non vi sto a spiegare), può garantire al 100% l'applicazione delle sole texture visibili.

OverClocK79®

01-06-2003, 17:31

Originally posted by "DragonWizard"

A proposito, di DeltaForce niente? Ma ke dorme S3???!!!

si e i solidatini in Vietnam? :D
DeltaChrome forse :p :D

BYEZZZZZZZZZZZZ

Kyrandia

02-06-2003, 02:29

Originally posted by "Vifani"

"infinite splines" (una spline è un concetto matematico, una funzione, che per brevità non vi sto a spiegare

sai dove posso trovare informazioni su questo ? grazie Vifani:)

Crisidelm

02-06-2003, 08:42

Il Deltachrome sarà certamente usato come grafica integrata nei prossimi chipset Via (è stato scritto anche sulle news di HwUpgrade recentemente): non penso ci sarà mai una scheda stand-alone col DeltaChrome, sinceramente...staremo a vedere.

umile

02-06-2003, 09:55

powervr può fare schede decenti.......ma le commercializza troppo in ritardo.............

Vifani

02-06-2003, 11:25

Originally posted by "Kyrandia"

sai dove posso trovare informazioni su questo ? grazie Vifani:)

Per sapere cosa è una spline dovresti leggerti un bel libro di "Calcolo numerico" che è un'esame che si fa normalmente nelle facoltà di Informatica. Sapere come si applicano alla grafica è un po' più complesso saperlo anche perché si tratta di un brevetto di PowerVR Technologies e non di un approccio comunemente utilizzato.

pandyno

02-06-2003, 11:26

Vifani hai un PVT ;)

Kyrandia

02-06-2003, 11:59

si infatti ho visto che è anche una funzione di Matlab (faccio ingegneria tlc )..pero penso che non mi è dato sapere di piu...

Crisidelm

02-06-2003, 12:01

Se si cerca in internet qualcosa si trova (in Inglese) con pure esempi in Java...

yossarian

02-06-2003, 17:56

Originally posted by "Vifani"

Il discorso non è proprio così. Il rendering tradizionale che viene effettuato dalle schede GeForce, Radeon e Matrox parte dal presupposto che l'immagine renderizzata sia 3D. La tecnologia PowerVR ed in particolare il Deferred Texturing (che è una cosa diversa dal Tile Based Rendering) invece tratta tutte le informazioni tenendo conto che indipendentemente dalla profondità della scena, dalla quantità di poligoni e di superfici alla fine, visto che l'immagine deve essere visualizzata su una superficie 2D (il monitor), comunque potrà essere visualizzato solo 1 texel (cioè un elemento di una texture) per pixel dello schermo.

I passi li ho spiegati più di una volta in passato. I chip PowerVR sconvolgono quello che è il normale processo di rendering (immediate rendering) andando a memorizzarsi le informazioni relative alla geometria della scena. A questo punto, sapendo quali superfici saranno nascoste e quali visibili, applicano le texture solo a quelle visibili. Naturalmente visto che sarebbe troppo pesante gestire le informazioni relative alla geometria di tutto lo schermo, si usa la suddivisione in Tile (Tile Based Rendering) per trattare una minore quantità di informazioni alla volta.

Le schede GeForce e Radeon, invece, prima applicano tutte le texture a tutte le superfici dopodiché usano lo Z-buffer per determinare quale texel visualizzare e quali no. E' proprio questo test della profondità a posteriori che li rende poco efficienti. I vari metodi di HSR di ATi e nVidia servono ad ottimizzazione alcune operazioni ma si basano comunque su una base di rendering classica. Solo il Deferred Texturing, usando algoritmi alla cui base ci sono le "infinite splines" (una spline è un concetto matematico, una funzione, che per brevità non vi sto a spiegare), può garantire al 100% l'applicazione delle sole texture visibili.

Quello da te descritto, relativamente ai chip ATI, nVIDIA e Matrox, è il procedimento di rendering tradizionale, in assenza di algoritmi tipo Hyper-Z. Sulle Geforce2 venivano renderizzate tutte le superfici e successivamente erano rimossi quelli nascosti; su Radeon e Geforce3 questo non succedeva. Ad essere renderizzate erano solo le superfici visibili. Con i metodo utilizzati da ATI, Matrox e nVIDIA, escono dal chip tutte le superfici (visibili e non, non renderizzate); in seguito i poligoni così calcolati vengono sottoposti all'analisi per rimuovere le superfici nascoste; infine le superfici visibili sono renderizzate (ma solo quelle). Con il TBR, per ogni tile vengono calcolati tutti i vertici, le coordinate sono inviate ad una cache interna al chip; terminato il calcolo relativo ad una tessera, tutti i dati sono sottoposti all'esame per la rimozione dei poligoni nascosti. Quindi ad uscire dal chip sono solo le superfici visibili.
Il sistema di rendering in assenza di sistemi atti a individuare preventivamente le superfici nascoste (quello fino alle GF2), prevedeva invece le operazioni di calcolo dei vertici e di rendering e, solo in seguito, la rimozione delle superfici nascoste.
Però, ripeto, nessun algoritmo, né Matrox, né nVIDIA, né ATI, prevede il rendering delle superfici nascoste e la successiva rimozione delle stesse (questo è il metodo classico in assenza di Hyper-Z o tecniche simili)

Ciao

mistral80

02-06-2003, 18:53

RAGAZZI FINIAMOLA!
ANCORA E'PRESTO PER UPGRADERE LA SCHEDA VIDEO CON UNA DIRECTX9. FATEMI CAPIRE SERVIREBBE SOLTANTO PER IL 3DMARK2003?
IO ABBORRO IL 3DMARK. APPROPOSITO GUARDATE QUESTO SITO
http://basta.spam.basta.spam.com

Spike

02-06-2003, 19:25

:rolleyes:

Per yossarin: sono quasi sicuro che Geforce ed Ati utilizzino degli algoritmi per la rimozione dei pixel nascosti e non dei poligoni per la diminuzione della banda passante richiesta. Provo ad informarmi.

Spike

02-06-2003, 19:38

ecco, ho trovato questo PDF che descrive la light speed memory architecture. Se si legge il documento si nota che ad esempio nella descrizione dello z-occlusion culling si parla sempre di pixel e non di poligoni, comunque è spiegato tutto lì.

http://www.nvidia.com/docs/lo/1452/SUPP/LMAII.2.02.pdf

pandyno

02-06-2003, 19:43

Originally posted by "Spike"

:rolleyes:

:rolleyes: :rolleyes:

FreeMan

02-06-2003, 20:02

Originally posted by "mistral80"

RAGAZZI FINIAMOLA!
ANCORA E'PRESTO PER UPGRADERE LA SCHEDA VIDEO CON UNA DIRECTX9. FATEMI CAPIRE SERVIREBBE SOLTANTO PER IL 3DMARK2003?
IO ABBORRO IL 3DMARK. APPROPOSITO GUARDATE QUESTO SITO
http://basta.spam.basta.spam.com

Cosa non ti è chiaro della frase "LO SPAM E' VIETATO!!" .. ?

non è la prima volta che te lo dico, ma è l'ultima!

>bYeZ<

yossarian

02-06-2003, 20:15

Originally posted by "Spike"

:rolleyes:

Per yossarin: sono quasi sicuro che Geforce ed Ati utilizzino degli algoritmi per la rimozione dei pixel nascosti e non dei poligoni per la diminuzione della banda passante richiesta. Provo ad informarmi.

Non è possibile rimuovere le textures relative ai poligoni nascosti, senza rimuovere gli stessi. Il processo di rendering avviene sui poligoni.
L'immediate rendering è il procedimento adottato prima dell'introduzione degli algoritmi di "clipping preventivo". Ripeto: nessun chip, dal Radeon 256 in poi, applica textures su poligoni nascosti per poi rimuoverle in un secondo tempo. La light speed memory architecture, l'hyper-z o chi per esso, non serve a rendere più veloce e ottimizzata la procedura di rendering tradizionale ma elimina i poligoni nascosti prima dell'operazione di rendering (non viene affatto applicata le procedura di rendering immediato). Non ha senso implementare una funzione nuova che non cambia alcunchè rispetto al passato.

Crisidelm

02-06-2003, 20:22

La differenza, appunto, sta nel modo in cui vengono trattati i poligoni, non tanto le superfici da texturizzare: gli IMR (Immediate Mode Renderer) calcolano tutti i poligoni, per POI scartare quei poligoni, o parte di essi, che non serve elaborare ulteriorermente perchè 'non visibili' alla fine (questo negli IMR più avanzati). I Deferred Mode Renderer, come i chip PowerVR, memorizzano tutti i vertici nelle scena, e prima di far qualsiasi altra cosa, capiscono quali siano 'importanti', (ovvero visibili), ovvero quali andranno a formare poligoni all'interno della scena visibile: fatto ciò, passano a formare i poligoni e texturizzarli.
Gli algo tipo Hyper-Z, o i Culling, necessitano che i poligoni siano calcolati PRIMA, per decidere man mano quali siano visibili o no, ovvero non sanno 'predire' quali poligoni rientrino nella superficie visibile ancor PRIMA di renderizzarli/calcolarli. I chip PowerVr, nel momento stesso in cui danno 'vita' ai poligoni, sanno già quali sono visibili, e solo quelli renderizzano.
In quanto ai Tile, in pratica tutti sistemi di tutte le case ormai funzionano per Tile, nel senso che la scena intera, in tutti i sistemi e tutti i chip moderni, viene 'ritagliata' in porzioni più piccole di grandezza fissa per ovvie ragioni di praticità: il punto di forza dei Chip PowerVR non è il TBR in sè, ma il fatto che sono dei DTBR: Deferred Tile Based Renderer.

Vifani

02-06-2003, 21:14

Sono d'accordo con Crisidelm tranne che per il discorso del rendering a Tile.

Le attuali architetture non effettuano il calcolo per Tile, ma per Poligono. Al massimo viene effettuata una sorta di suddivisione, ma solo a livello software e non di certo hardware come accade per il Kyro. Quest'ultimo ha per l'appunto un buffer interno dedicao interamente a tutte le operazioni Tile per Tile: Z-Buffer, Stencil Buffer e Frame Buffer.

Crisidelm

02-06-2003, 21:24

No Vifani: tutti chip video moderni suddividono le scene in tile (magari non li chiamano tile, ma quello sono), ovvero le parcellizzano, perchè è più 'comodo' trasferirle, tenerle e trattarle nella ram onboard. Ora non mi ricordo i link esatti, li posso cercare domani, ma in pratica sia ATI che nVidia nei loro chip usano tecniche simili: anche lo Xabre lo fa, e in teoria di certo anche il chip della Trident (chi l'ha visto poi?)...in fondo non ci vuole molto a fare una cosa del genere, ed è molto efficiente. Altro discorso è parlare di DMR: quello sì che è difficile da implementare partendo da 0 o quasi... dubito fortissimamente che sia l'R400, sia l'NV40 saranno qualcosa di differente da degli IMR, ancora una volta. E gli Hyper-Z e Culling che dir si voglia possono essere efficienti quanto si vuole, ma sono solo una pezza, non una soluzione definitiva ai problemi cronici e strutturali degli IMR...

yossarian

02-06-2003, 21:27

Originally posted by "Vifani"

Sono d'accordo con Crisidelm tranne che per il discorso del rendering a Tile.

Le attuali architetture non effettuano il calcolo per Tile, ma per Poligono. Al massimo viene effettuata una sorta di suddivisione, ma solo a livello software e non di certo hardware come accade per il Kyro. Quest'ultimo ha per l'appunto un buffer interno dedicao interamente a tutte le operazioni Tile per Tile: Z-Buffer, Stencil Buffer e Frame Buffer.

E' esattamente quello che ho detto (a parte il discorso delle operazioni svolte via HW o via SW e della suddivisione o meno in tiles).
Non è che il Kyro2 è in grado di "prevedere" quali poligoni saranno visibili e quali no. Il metodo di lavoro è analogo a quello degli altri chip; la differenza sta nel dove vengono effettuati i calcoli. Il Kyro2 utilizza un buffer interno a cui invia i dati relativi a tutti i vertici di ogni singola tessera (tranne quelli dei poligoni di confine che hanno uno o due vertici in una tessera e i restanti in un'altra); quindi invia questi dati alla sezione che si occupa dell'eliminazione dei poligoni nascosti. Risultato è che i poligoni che escono dal chip sono esclusivamente quelli visibili. Gli altri operano in maniera analoga, però utilizzano la ram video per stivare i dati relativi ai vertici. Il risultato è che la scena in uscita (prima del processo di texturing) è comprensiva di tutti i poligoni, compresi quelli nascosti (si è ancora in modalità wireframe); quindi i dati dei vertici vengono sottoposti all'operazione di HSR (dopo essere stati inviati di nuovo al chip) e infine a quella di rendering.
Questa è l'unica differenza nella procedura di HSR tra PowerVR e gli altri.

yossarian

02-06-2003, 21:48

Originally posted by "Crisidelm"

No Vifani: tutti chip video moderni suddividono le scene in tile (magari non li chiamano tile, ma quello sono), ovvero le parcellizzano, perchè è più 'comodo' trasferirle, tenerle e trattarle nella ram onboard. Ora non mi ricordo i link esatti, li posso cercare domani, ma in pratica sia ATI che nVidia nei loro chip usano tecniche simili: anche lo Xabre lo fa, e in teoria di certo anche il chip della Trident (chi l'ha visto poi?)...in fondo non ci vuole molto a fare una cosa del genere, ed è molto efficiente. Altro discorso è parlare di DMR: quello sì che è difficile da implementare partendo da 0 o quasi... dubito fortissimamente che sia l'R400, sia l'NV40 saranno qualcosa di differente da degli IMR, ancora una volta. E gli Hyper-Z e Culling che dir si voglia possono essere efficienti quanto si vuole, ma sono solo una pezza, non una soluzione definitiva ai problemi cronici e strutturali degli IMR...

Hai ragione, infatti, ad esempio, ATI, negli ultimi chip, utilizza tiles 8x8.
Sulle difficoltà di implementazione di una tecnica di TBR e deferred rendering su chip come R400 o NV40, sono d'accordo a metà. La difficoltà principale risiede nell'aumentare della complessità, a livello di componentistica e, quindi di dimensioni, di chip già molto complessi e con un elevato numero di transistor, non tanto a livello di logica di funzionamento del chip stesso.

Spike

02-06-2003, 21:55

Scusate ma che differenza c'è tra calcolo di poligoni e vertici? Se si calcolano i vertici di una scena si hanno automaticamente i poligoni.

Vorrei inoltre far notare che sia l'hyper Z di ATI che il Light speed architecture di Nvidia riguardano solo i pixel e non i poligoni. Cioè una volta creata la scena nel virtual frame buffer vengono scritti solo i pixel che vengono realmente visualizzati il tutto per risparmiare banda passante (se vi ricordate le kyro2 avevano memorie sdr al contrario delle concorrenti che montavano ddr appunto per questo fatto: il chip Kyro necessita di meno banda passante perchè elabora di fatto meno "cose").

Leggete questo pdf alla voce PERFORMANCE:
http://www.ati.com/technology/hardware/radeon/whitepaperradeon.pdf

yossarian

02-06-2003, 22:01

Originally posted by "Spike"

Scusate ma che differenza c'è tra calcolo di poligoni e vertici? Se si calcolano i vertici di una scena si hanno automaticamente i poligoni.

Infatti i calcoli che vengono effettuati sono relativi alle coordinate dei vertici (le unità Vertex Shaders non fanno altro che manipolare dati relativi ai vertici dei poligoni che compongono la scena 3D). Si utilizza il termine poligoni, ma in effetti, il chip lavora partendo dalle coordinate dei vertici, anche quando deve effettuare le operazioni di rimozione delle superfici nascoste

Spike

02-06-2003, 22:05

ho aggiunto un pezzo

Vifani

02-06-2003, 22:08

Non sono d'accordo. I chip PowerVR indicano l'architettura Tile Based come un'esclusiva, mentre ATi e nVidia non ne hanno mai parlato.

Il discorso delle Tile dell'Hyper-Z è una cosa completamente diversa. Quella è solo la dimensione minima dello schermo sul quale viene effettuato il test di visibilità delle superfici, ma per quanto concerne il rendering puro i chip PowerVR sono gli unici che renderizzano Tile per Tile usando un buffer insito al chip. Quando tutte le operazioni su una Tile vengono effettuate, il risultato è inviato al Frame Buffer della memoria video..... I chip nVidia e ATi inviano ogni risultato alla memoria e lo riprendono per eventuali calcoli successivi, facendo quindi largo uso della banda passante tra memoria e chip. Inoltre solo la tecnica PowerVR di Deferring Texturing è in grado di garantire al 100% che siano renderizzati solo le texture realmente visibili. Le varie tecniche di HSR continuano in molti casi a disegnare le superfici nascoste (altrimenti non si spiegherebbe l'Hyper-Z, poi la versione II.... poi la versione III, ecc.... che, pertanto, non fanno altro che affinarsi ed aumentare la percentuale delle superfici escluse).

Vi ricordo che il VillageMark, test che misura l'efficienza nella gestione delle scene dotate di overdraw, ha un punteggio molto elevato sui chip Kyro II, migliore di quello delle schede Radeon 8500, 9000 Pro, 9100, 9200, GeForce 4 Ti e MX. E stiamo parlando di due pipeline con una TMU ciascuna non delle 4 pipeline con due TMU o delle due pipeline con due TMU suddette (per non parlare poi delle differenze a livello di frequenza).

Solo le più recenti architetture, e mi riferisco al GeForce Fx 5800/5900, Radeon 9700/9800, hanno raggiunto un punteggio di poco superiore a quello del Kyro II. Questo dovrebbe far riflettere sull'enorme differenza concettuale e di lavoro tra l'IMR + HSR ed il TBR + Deffered Texturing.

yossarian

02-06-2003, 22:22

Originally posted by "Spike"

Scusate ma che differenza c'è tra calcolo di poligoni e vertici? Se si calcolano i vertici di una scena si hanno automaticamente i poligoni.

Vorrei inoltre far notare che sia l'hyper Z di ATI che il Light speed architecture di Nvidia riguardano solo i pixel e non i poligoni. Cioè una volta creata la scena nel virtual frame buffer vengono scritti solo i pixel che vengono realmente visualizzati il tutto per risparmiare banda passante (se vi ricordate le kyro2 avevano memorie sdr al contrario delle concorrenti che montavano ddr appunto per questo fatto: il chip Kyro necessita di meno banda passante perchè elabora di fatto meno "cose").

Leggete questo pdf alla voce PERFORMANCE:
http://www.ati.com/technology/hardware/radeon/whitepaperradeon.pdf

Anche il TBR riguarda i pixel. Le tessere in cui viene divisa l'intera scena sono di nxn pixels (con n intero). Per determinare cosa è visibile in un determinato pixel, si devono avere informazioni sulle posizioni dei vertici dei poligoni che interessano quel pixel. Il Kyro non elabora meno cose; le elabora in maniera più razionale. Mentre ATI e nVIDIA hanno pensato ad una soluzione che non stravolgesse il sistema di rendering diretto, introducendo solo qualche passaggio intermedio tra le operazioni di trasformazione e quelle di illuminazione, PowerVR ha utilizzato una soluzione che, per le operazioni di calcolo dei vertici di una tile e per le operazioni di HSR sugli stessi, prescinde dall'utilizzo della ram video. Questo implica il risparmio di due passaggi, rispetto agli algoritmi utilizzati dai concorrenti: il trasferimento dei dati relativi ai vertici dalle unità preposte al calcolo dei vertici staessi alla ram video e il trasferimento di quegli stessi dati dalla ram video all'unità preposta alle operazioni di HSR.
Se poi ti fa piacere continuare a credere che i chip non PowerVR effettuino il rendering prima di rimuovere le superfici nascoste, ovviamente, sei libero di farlo, anche se non è così nel modo più assoluto.

yossarian

02-06-2003, 22:37

Originally posted by "Vifani"

Non sono d'accordo. I chip PowerVR indicano l'architettura Tile Based come un'esclusiva, mentre ATi e nVidia non ne hanno mai parlato.

Il discorso delle Tile dell'Hyper-Z è una cosa completamente diversa. Quella è solo la dimensione minima dello schermo sul quale viene effettuato il test di visibilità delle superfici, ma per quanto concerne il rendering puro i chip PowerVR sono gli unici che renderizzano Tile per Tile usando un buffer insito al chip. Quando tutte le operazioni su una Tile vengono effettuate, il risultato è inviato al Frame Buffer della memoria video..... I chip nVidia e ATi inviano ogni risultato alla memoria e lo riprendono per eventuali calcoli successivi, facendo quindi largo uso della banda passante tra memoria e chip. Inoltre solo la tecnica PowerVR di Deferring Texturing è in grado di garantire al 100% che siano renderizzati solo le texture realmente visibili. Le varie tecniche di HSR continuano in molti casi a disegnare le superfici nascoste (altrimenti non si spiegherebbe l'Hyper-Z, poi la versione II.... poi la versione III, ecc.... che, pertanto, non fanno altro che affinarsi ed aumentare la percentuale delle superfici escluse).

Vi ricordo che il VillageMark, test che misura l'efficienza nella gestione delle scene dotate di overdraw, ha un punteggio molto elevato sui chip Kyro II, migliore di quello delle schede Radeon 8500, 9000 Pro, 9100, 9200, GeForce 4 Ti e MX. E stiamo parlando di due pipeline con una TMU ciascuna non delle 4 pipeline con due TMU o delle due pipeline con due TMU suddette (per non parlare poi delle differenze a livello di frequenza).

Solo le più recenti architetture, e mi riferisco al GeForce Fx 5800/5900, Radeon 9700/9800, hanno raggiunto un punteggio di poco superiore a quello del Kyro II. Questo dovrebbe far riflettere sull'enorme differenza concettuale e di lavoro tra l'IMR + HSR ed il TBR + Deffered Texturing.

Sul fatto che i chip PowerVR siano gli unici ad utilizzare un buffer interno per le operazioni di "stivaggio" dei dati relativi ai vertici di una tile e alle operazioni di HSR sugli stessi penso siamo tutti d'accordo. Però, a parte questo, non ci sono altre differenze. I vari processi di affinamento dell'Hyper-Z e della Light Speed Architecture non avrebbero portato a risultati migliori di quelli del Kyro2 se ci fossero altre differenze oltre ad un miglior utilizzo della banda passante da parte del Kyro2. Se vengono renderizzate superfici non visibili, non dipende dal tipo di tecnica utilizzata, ma da un errore nell'algoritmo in uso. In tal caso un eventuale affinamento non è altro che l'eliminazione di quell'errore. E' ovvio che un chip che non utilizzi per le operazioni di deposito dati e HSR un buffer interno, debba, per lo stesso scopo, utilizzare la ram video, con occupazione della banda passante (anche su questo non ci piove). Però questa è l'unica differenza tra il metodo adottato da PowerVR e quello utilizzato dagli altri.
In questo contesto il numero delle pipeline e delle relative TMU non ha importanza, poichè parliamo di pipelines di rendering, cioè di un'operazione successiva a quella di HSR. Un test che misura l'efficienza dell'HSR non tiene conto della velocità con cui viene, successivamente, renderizzata la scena. E' ovvio che se teniamo conto di tutto, la 8500 o la GF4 TI sono, complessivamente, più veloci del Kyro2, come dimostra il più elevato framerate nei giochi, potendo compensare ampiamente la minor efficienza dell'HSR con la maggior velocità in fase di rendering. Quella che invece incide è la frequenza di funzionamento dei vari chip (e R3x0 e NV3x hanno frequenze più elevate rispetto ai loro predecessori). Inoltre esistono evidenti differenze anche tra gli algoritmi utilizzati da ATI e da NV e tra le architetture dei chip delle due case nordamericane (che si ripercuotono in una differenza prestazionale, in test come il Villagemark, a favore di ATI, mentre, invece Matrox utilizza un sistema di rendering tradizionale e questo è uno dei principali motivi delle non brillanti prestazioni della Parhelia nelle applicazioni 3D).

Vifani

02-06-2003, 23:00

Non sono d'accordo.

Spike

03-06-2003, 00:09

Quello che sto dicendo io è che Nvidia ed ATI non hanno nessun sistema per la rimozione dei poligoni nascosti ma solo dei pixel nascosti. Ovvero le schede Ati ed Nvidia calcolano anche i poligoni nascosti per costruire la scena(non tutti veramente, le mappe sono suddivise in blocchi quindi alcune parti della mappa non vengono nemmeno prese in considerazione). Nella fase di rendering subentrano i vari sistemi Hyper Z e LMA che determinano quali pixel sono visibili e quindi renderizzano solo quelli.

Il sistema del Kyro invece una volta calcolata la scena, come nel caso precedente, rimuove i poligoni che non si vedono e passa a renderizzare tutti i poligoni rimasti.

All'atto pratico il risultato è simile ma evidentemente il secondo è più efficiente dato che rispetto alle schede concorrenti il Kyro 2 era più performante in questo campo.

Secondo me è così, sono stato spiegato? :D

paso74

03-06-2003, 00:28

bella questa discussione, imho una delle più interessanti degli ultimi tempi sul forum.

atecnicamente: ricordo che nel 1997 volevo comprare il primo chip PowerVR, lo montava Videologic su una sua scheda. La caratteristica principale, rispetto al voodoo graphics che all'epoca era la "prima scelta", stava nel fatto che i 4mb onboard (come il voodoo) erano sfruttati diversamente. Una "particolare tecnologia" permetteva a questa scheda di fare a meno dello zbuffer, risparmiando così sulla memoria, e permettendo una risoluzione massima di addirittura 1024x768, laddove il voodoo graphics si fermava a 640x480 e il voodoo rush a 800x600... E inoltre già allora non disegnava ciò che non era visibile... ci dovrebbe essere anche un articolo su tomshardware che lo spiegava.

yossarian

03-06-2003, 00:33

Originally posted by "Spike"

Quello che sto dicendo io è che Nvidia ed ATI non hanno nessun sistema per la rimozione dei poligoni nascosti ma solo dei pixel nascosti. Ovvero le schede Ati ed Nvidia calcolano anche i poligoni nascosti per costruire la scena(non tutti veramente, le mappe sono suddivise in blocchi quindi alcune parti della mappa non vengono nemmeno prese in considerazione). Nella fase di rendering subentrano i vari sistemi Hyper Z e LMA che determinano quali pixel sono visibili e quindi renderizzano solo quelli.

Il sistema del Kyro invece una volta calcolata la scena, come nel caso precedente, rimuove i poligoni che non si vedono e passa a renderizzare tutti i poligoni rimasti.

All'atto pratico il risultato è simile ma evidentemente il secondo è più efficiente dato che rispetto alle schede concorrenti il Kyro 2 era più performante in questo campo.

Secondo me è così, sono stato spiegato? :D

Continuo a non capire come si fa a calcolare i pixel nascosti senza tener conto dei poligoni. Chiariamo alcuni concetti: il pixel è la più piccola area rettangolare in cui è suddiviso lo schermo (immagine 2D). Non è possibile che ci siano pixel nascosti ma, semmai, per ogni pixel o insieme di pixels, possono esserci superfici, intese come textures applicate, nascoste da altre superfici relative sempre allo stesso pixel. Avere uno o più pixel nascosti significa avere dei punti neri sullo schermo, ossia delle porzioni di schermo (non di immagine) che non sono visibili. L'intero quadro (non solo l'immagine 3D da rappresentare) è diviso in pixels; in ogni pixel possono capitare uno o più vertici relativi ai poligoni che costruiscono l'immagine 3D (e qui parliamo di 3D, non in riferimento ai pixels). Sui poligoni vengono applicate le textures, ossia delle skins, insomma vengono appiccicate delle superfici più o meno colorate, che riproducono più o meno effetti di luci e ombre, increspature, consistenza, ruvidità e sccidanti vari (stiamo sempre parlando di 3D). Ora i casi sono 2: queste superfici sono applicate prima che vengano rimossi i poligoni nascosti (da altri poligoni) oppure dopo. Il primo caso è quello di rendering immediato (quello fino alle Geforce2), il secondo è quello di rendering effettuato dopo l'operazione di HSR (quello di tutti i chip, a partire dal Radeon 256 in poi, con metodi più o meno diversi). Quindi non è assolutamente vero che i chip che non adottano il TBR effettuino il rendering sui poligoni nascosti; non è vero che il TBR è un'implementazione via HW e le altre solo via SW (utilizzano semplicemente strutture HW diverse: il TBR un buffer interno, gli altri metodi la ram video); non è assolutamente possibile che i chip che non adottano il TBR rimuoveno i pixels anzichè i poligoni nascosti (se trovate un chip che rimuove pixels riportatelo al negozio in cui lo avete preso e fatevelo cambiare :D )

yossarian

03-06-2003, 00:35

Originally posted by "paso74"

bella questa discussione, imho una delle più interessanti degli ultimi tempi sul forum.

atecnicamente: ricordo che nel 1997 volevo comprare il primo chip PowerVR, lo montava Videologic su una sua scheda. La caratteristica principale, rispetto al voodoo graphics che all'epoca era la "prima scelta", stava nel fatto che i 4mb onboard (come il voodoo) erano sfruttati diversamente. Una "particolare tecnologia" permetteva a questa scheda di fare a meno dello zbuffer, risparmiando così sulla memoria, e permettendo una risoluzione massima di addirittura 1024x768, laddove il voodoo graphics si fermava a 640x480 e il voodoo rush a 800x600... E inoltre già allora non disegnava ciò che non era visibile... ci dovrebbe essere anche un articolo su tomshardware che lo spiegava.

e permetteva anche di far girare le applicazioni in finestra, oltre che a pieno schermo.

yossarian

03-06-2003, 00:46

Originally posted by "Vifani"

Non sono d'accordo.

Ti cito 3 interventi nell'ordine in cui si sono succeduti: il primo e il terzo sono miei, il secondo è tuo

Il TBR, dal punto di vista funzionale non differisce dagli altri metodi di HSR. Nessun chip dotato di algoritmo di HSR renderizza le superfici nascoste; la rimozione dei poligoni nascosti avviene dopo il processo di trasformazione, ossia di calcolo delle posizioni dei vertici prsenti in ogni tile o tessera che dir si voglia. In seguito, i dati relativi alle posizioni dei vertici visibili vengono trasferiti alle pipelines di rendering per il processo di texturizzazione. La differenza fondamentale è che la tecnologia PowerVR utilizza una cache interna al chip per stivare i dati relativi ai vertici dei poligoni di ogni tessera, mentra gli altri, per lo stesso scopo, utilizzano la ram video. Questo significa che i dati relativi ai vertici non compiono il viaggio di andata e ritorno tra chip e ram video ma vengono direttamente trasferiti alle pipelines di rendering per essere texturizzati.

Il discorso delle Tile dell'Hyper-Z è una cosa completamente diversa. Quella è solo la dimensione minima dello schermo sul quale viene effettuato il test di visibilità delle superfici, ma per quanto concerne il rendering puro i chip PowerVR sono gli unici che renderizzano Tile per Tile usando un buffer insito al chip. Quando tutte le operazioni su una Tile vengono effettuate, il risultato è inviato al Frame Buffer della memoria video..... I chip nVidia e ATi inviano ogni risultato alla memoria e lo riprendono per eventuali calcoli successivi, facendo quindi largo uso della banda passante tra memoria e chip.

Non è che il Kyro2 è in grado di "prevedere" quali poligoni saranno visibili e quali no. Il metodo di lavoro è analogo a quello degli altri chip; la differenza sta nel dove vengono effettuati i calcoli. Il Kyro2 utilizza un buffer interno a cui invia i dati relativi a tutti i vertici di ogni singola tessera (tranne quelli dei poligoni di confine che hanno uno o due vertici in una tessera e i restanti in un'altra); quindi invia questi dati alla sezione che si occupa dell'eliminazione dei poligoni nascosti. Risultato è che i poligoni che escono dal chip sono esclusivamente quelli visibili. Gli altri operano in maniera analoga, però utilizzano la ram video per stivare i dati relativi ai vertici. Il risultato è che la scena in uscita (prima del processo di texturing) è comprensiva di tutti i poligoni, compresi quelli nascosti (si è ancora in modalità wireframe); quindi i dati dei vertici vengono sottoposti all'operazione di HSR (dopo essere stati inviati di nuovo al chip) e infine a quella di rendering.
Questa è l'unica differenza nella procedura di HSR tra PowerVR e gli altri.

Con quali sei in disaccordo?

Spike

03-06-2003, 01:21

Allora: fondamentalmente stiamo dicendo la stessa cosa, ma secondo me:

C'è inizialmente una fase comune a tutti i chip grafici che è la costruzione della scena 3D con tutti i vertici, facce, poligoni e via dicendo. Ora abbiamo la nostra scena 3D nuda e cruda pronta da renderizzare. E fin qui credo sia tutto chiaro.

Da questo punto in poi le cose cambiano, ecco come:

Nel chip kyro la scena nuda e cruda viene analizzata e un algoritmo rimuove i poligoni nudi non visibili, quindi la scena risultante dopo questa elaborazione è ancora non renderizzata e con dei "buchi" corrispondenti alle aree non visualizzate. E' da notare che fino ad ora la memoria on board non è stata interessata in quanto questo calcolo viene fatto nella cache dedicata a questo scopo. Ora si passa al rendering, ossia la scena privata di tutti i poligoni nascosti viene renderizzata e così nascono i pixel che vengono riprodotti sullo schermo.

Negli altri chip invece la scena nuda e cruda viene passata in memoria, quindi comincia il rendering. Ora grazie all'Hyper Z di ATI e al corrispondente Nvidia LMA durante la fase di rendering vengono processati solo i pixel visibili che vengono dunque sparati a monitor.

Il risultato finale è dunque lo stesso, ma il metodo fra le due architetture è duale ossia: una volta calcolata tutta la scena il chip kyro toglie i poligoni nascosti e renderizza tutto ciò che rimane, gli altri invece considerano tutta la scena ma renderizzano solo i pixel visibili. E un'approccio diverso per risolvere lo stesso problema.

Secondo me comunque, il metodo kyro è migliore in quanto utilizza una cache dedicata molto veloce, probabilmente se anche sulle geforce e sulle radeon venisse usato un sistema simile non occorrerebbe un bus a 256 bit e memorie DDR2, ma pio come giustificherebbero i prezzi sempre più alti? ;)

Spero di essere stato chiaro!

THE END http://forum.hwupgrade.it/faccine/26.gif

yossarian

03-06-2003, 01:39

Originally posted by "Spike"

Allora: fondamentalmente stiamo dicendo la stessa cosa, ma secondo me:

C'è inizialmente una fase comune a tutti i chip grafici che è la costruzione della scena 3D con tutti i vertici, facce, poligoni e via dicendo. Ora abbiamo la nostra scena 3D nuda e cruda pronta da renderizzare. E fin qui credo sia tutto chiaro.

Da questo punto in poi le cose cambiano, ecco come:

Nel chip kyro la scena nuda e cruda viene analizzata e un algoritmo rimuove i poligoni nudi non visibili, quindi la scena risultante dopo questa elaborazione è ancora non renderizzata e con dei "buchi" corrispondenti alle aree non visualizzate. E' da notare che fino ad ora la memoria on board non è stata interessata in quanto questo calcolo viene fatto nella cache dedicata a questo scopo. Ora si passa al rendering, ossia la scena privata di tutti i poligoni nascosti viene renderizzata e così nascono i pixel che vengono riprodotti sullo schermo.

Negli altri chip invece la scena nuda e cruda viene passata in memoria, quindi comincia il rendering. Ora grazie all'Hyper Z di ATI e al corrispondente Nvidia LMA durante la fase di rendering vengono processati solo i pixel visibili che vengono dunque sparati a monitor.

Il risultato finale è dunque lo stesso, ma il metodo fra le due architetture è duale ossia: una volta calcolata tutta la scena il chip kyro toglie i poligoni nascosti e renderizza tutto ciò che rimane, gli altri invece considerano tutta la scena ma renderizzano solo i pixel visibili. E un'approccio diverso per risolvere lo stesso problema.

Secondo me comunque, il metodo kyro è migliore in quanto utilizza una cache dedicata molto veloce, probabilmente se anche sulle geforce e sulle radeon venisse usato un sistema simile non occorrerebbe un bus a 256 bit e memorie DDR2, ma pio come giustificherebbero i prezzi sempre più alti? ;)

Spero di essere stato chiaro!

THE END http://forum.hwupgrade.it/faccine/26.gif

Tutto giusto tranne una cosa: anche gli altri chip eliminano i poligoni nascosti prima del processo di rendering. La differenza sta nel fatto che il Kyro2 non utilizza la ram video ma una cache interna per compiere questa operazione (quindi la ram video non viene occupata); il vantaggio sta nel fatto che si evita il passaggio attraverso il bus di collegamento tra ram e chip (evitando di intasarlo con dati superflui). Nel Kyro2, attraverso il bus, transitano solo i dati relativi ai poligoni visibili. Negli altri chip, in una prima fase (dopo il processo di trasformazione, ossia di calcolo dei vertici), transitano i dati relativi a tutti i poligoni; in una seconda fase questi dati vengono di nuovo recuperati dal chip (transitando ancora in versione integrale attraverso il bus) perchè venga effettuata l'operazione di clipping (rimozione dei poligoni nascosti), quindi, finalmente, passano solo i dati relativi ai poligoni realmente visibili. Se tieni conto che il canale di comunicazione tra buffer interno e unità preposte al calcolo e alla rimozioni dei vertici (nel caso del Kyro) è molto più veloce di quello esterno e che con il TBR si saltano le prime due fasi, descritte nel caso relativo ai chip che non utilizzano il TBR, che comportano il passaggio dei dati due volte attraverso il bus, puoi comprendere i vantaggi di un procedimento come il TBR che rappresenta sicuramente un approccio più razionale ed efficiente.

Bardak

03-06-2003, 09:28

Forse centra poco con il discorso del Kiro di per se ma tenendo conto di tutto il discorso cheavete fatto sui chip grafici vi potra interessare sapere che con un xp 2400+ e 512 mb di ram i sistema sono riuscito a far girare ut2003 con una s3 pci a 800X600 :D
questo solo per dimostrare a quanto servono le varie tecnologie che si pagano fior di euro :muro:

vulcanik

03-06-2003, 13:36

E basta con queste seghe mentali. :D

Vifani

03-06-2003, 13:41

yossarian il discorso che fai tu non è giusto.

Ecco la risposta di Kristof Beets, una delle menti di PowerVR Technologies, alla mia seguente domanda:

Hyper-Z and Lightspeed Memory Architecture are equal to Deferred Texturing used by PowerVR chip?

No, not even close. Biggest difference being that HyperZ and Lightspeed Memory Architexture are area based and not per pixel accurate and its dependend on the render order of the polygons. So, only PowerVR Deferred Texturing can guarantee that all elaborated texel are the pixel you can see on the screen.

Esattamente come vi dicevo io, solo il Deferred Texturing di PowerVR garantisce al 100% il calcolo dei soli pixel visibili. Hyper-Z e compani prendono in considerazione piccole zone di schermo e testano se all'interno di questa zona, esiste una superficie non visibile. In tal caso non la elaborano. Se c'è anche un solo texel visibile all'interno di quella zona, tutti gli altri texel verranno calcolati.

Inoltre, per rispondere a Crisidelm che afferma che anche gli altri chip lavorano Tile per Tile ho fatto anche questa domanda:

R3xx and NV3x do a Tile Based Rendering?

No, although some operations are done on blocks/tiles they are not what you would call a tile based renderer.

Solo alcune operazioni vengono effettuate suddividendo logicamente l'immagine per tessere, ma non possono essere considerate Tile Based. Quest'ultimo è un altro concetto di rendering, un altro modo di approcciarsi alla costruzione dell'immagine.

Crisidelm

03-06-2003, 18:46

Originally posted by "Crisidelm"

...In quanto ai Tile, in pratica tutti sistemi di tutte le case ormai funzionano per Tile, nel senso che la scena intera, in tutti i sistemi e tutti i chip moderni, viene 'ritagliata' in porzioni più piccole di grandezza fissa per ovvie ragioni di praticità: il punto di forza dei Chip PowerVR non è il TBR in sè, ma il fatto che sono dei DTBR: Deferred Tile Based Renderer.

Veramente la risposta di Kristof conferma che anche negli altri chip, alcune operazioni (quali secondo te? :) ) avvengono per 'blocks/tiles': non ho mai detto che gli altri chip usano pure forme di TBR, ma che anche quei chip recenti lavorano su parcelizzazioni della scena intera (una volta non facevano così), per scopi di praticità. :D
In quanto al nome TBR, continuo a sostenere che la definizione più corretta e completa sarebbe DTBR: Deferred Tile Based Rendering :)

yossarian

03-06-2003, 20:35

Originally posted by "Vifani"

yossarian il discorso che fai tu non è giusto.

Ecco la risposta di Kristof Beets, una delle menti di PowerVR Technologies, alla mia seguente domanda:

Hyper-Z and Lightspeed Memory Architecture are equal to Deferred Texturing used by PowerVR chip?

No, not even close. Biggest difference being that HyperZ and Lightspeed Memory Architexture are area based and not per pixel accurate and its dependend on the render order of the polygons. So, only PowerVR Deferred Texturing can guarantee that all elaborated texel are the pixel you can see on the screen.

Esattamente come vi dicevo io, solo il Deferred Texturing di PowerVR garantisce al 100% il calcolo dei soli pixel visibili. Hyper-Z e compani prendono in considerazione piccole zone di schermo e testano se all'interno di questa zona, esiste una superficie non visibile. In tal caso non la elaborano. Se c'è anche un solo texel visibile all'interno di quella zona, tutti gli altri texel verranno calcolati.

Inoltre, per rispondere a Crisidelm che afferma che anche gli altri chip lavorano Tile per Tile ho fatto anche questa domanda:

R3xx and NV3x do a Tile Based Rendering?

No, although some operations are done on blocks/tiles they are not what you would call a tile based renderer.

Solo alcune operazioni vengono effettuate suddividendo logicamente l'immagine per tessere, ma non possono essere considerate Tile Based. Quest'ultimo è un altro concetto di rendering, un altro modo di approcciarsi alla costruzione dell'immagine.

Scusa ma non mi pare affatto che smentisca quello che ho detto finora. Io sto parlando di come funziona il TBR, quello da te citato mi pare invece un messaggio pubblicitario che non spiega un bel niente. Inoltre, come ha detto Crisidelm, anche gli altri algoritmi suddividono l'intero quadro in Tiles (nel caso degli ultimi chip ATI delle dimensioni di 8x8 pixels). Inoltre ti faccio notare che anche il passo da te citato, sebbene non spieghi il funzionamento del TBR né le differenze con gli altri metodo adoperati, dice testualmente che i metodi in questione non sono "troppo prossimi", non mi pare che dica che esistano le differenze abissali da te citate nei precedenti interventi. Anche ammettendo che gli altri algoritmi operino per aree, si sta parlando di aree molto piccole (dell'ordine di pochi pixels) e non di vaste porzioni di schermo. In ogni caso la situazione da te prospettata è alquanto improbabile (non mi pare siano stati segnalati casi di malfunzionamento degli algoritmi di rimozione dei poligoni nascosti utilizzati da nVIDIA o ATI, che invece non presentavano problemi anche con il Kyro2 (quindi di bugs dovuti agli algoritmi utilizzati e non piuttosto al motore grafico del gioco)). Inoltre non ho afferrato il discorso sulle textures. Per ogni pixel è normale che ci sia almeno una texture visibile e sarà quella con la coordinata Z maggiore tra quelle aventi gli stessi valori di X e Y (queste sono informazioni già contenute nelle istruzioni shader che sono di tipo vettoriale, quindi non danno informazioni solo sulla qualità delle textures applicate ma anche sulle reciproche posizioni). Questo partendo dall'assunto che non ci sono pixels nascosti ma, semmai, superfici nascoste (i pixels sono sempre e comunque visibili e di conseguenza ogni pixel avrà, come ho detto, almeno una texture visibile).

yossarian

03-06-2003, 22:02

Inoltre, a voler sottilizzare, il vero punto forte del metodo adottato dal Kyro2 è rappresentato dalle elevate prestazioni (non ottenute attraverso il deferred rendering), ma grazie all'eliminazione di un paio di passaggi superflui (quelli di cui ho parlato in precedenza). Un rendering effettuato per pixel o per area, si può indifferentemente implementare sia utilizzando un buffer interno che facendo ricorso alla ram video.

Vifani

03-06-2003, 22:12

Forse dovresti rivedere il tuo inglese.

Io gli ho chiesto: sono l'Hyper-Z ed il Lightspeed Memory architecture uguali al Deferred Texturing?

Lui ha risposto: No, neanche vicini (not even close). La differenza più grande è che l'Hyper-Z ed il Lightspeed Memory architecture sono basati sulle aree....

Io non sto dicendo che gli algoritmi di ATi o nVidia siano difettosi o abbiano problemi, quello che sto tentando di dirti è che sono basati su un'impostazione di rendering che non ha niente a che fare con quella dei chip PowerVR.

I chip PowerVR creano per ogni tessera una triangle list in fase di setup dei triangoli, che viene poi utilizzata per sapere quali superfici sono visibili e quali no.

Quello che sto tentando di spiegarvi è che il Deferred Texturing ed il Tile Based Rendering sono due cose COMPLETAMENTE DISTINTE anche se complementari. Teoricamente se il buffer per la triangle list fosse abbastanza grande, i chip PowerVR potrebbero considerare la lista dei triangoli di tutta la scena e lavorare direttamente sull'intera scena. Il Tile Based Rendering gli consente di ridurre questo discorso a piccole zone di schermo andando ad ottimizzare anche ALTRE funzioni come lo Z-Buffer, lo Stencil Buffer ed il Frame Buffer che vengono quindi effettuante ONCHIP.

Le architetture di ATi e nVidia non effettuano nessuna delle operazioni suddette: non sono in grado di garantire al 100% l'applicazione dei soli texel visibili (e questo significa che in alcuni casi, seppur minimi, prelevano della memoria texture che di fatto alla fine non sono visualizzate), non effettuano nessuna operazione onchip (Z-Buffer, Stencil Buffer, Frame Buffer e compagnia bella sono tutti all'interno della memoria della scheda e pertanto per accerdervi si usa il bus delle memoria). Forse ci si sta avvicinando ad una concezione simile un po' con il F-Buffer di R350.... ma in quel caso l'uso è specifico per i Pixel Shader e non per altre funzioni.

Questa radicale diversità dalle altre architetture ha comportato per PowerVR moltissimi problemi di compatibilità con vari giochi (parlo principalmente dell'epoca della PowerVR Serie 1, cioè il PCX2 usato nella Matrox M3D).

yossarian

03-06-2003, 22:29

Originally posted by "Vifani"

Forse dovresti rivedere il tuo inglese.

Io gli ho chiesto: sono l'Hyper-Z ed il Lightspeed Memory architecture uguali al Deferred Texturing?

Lui ha risposto: No, neanche vicini (not even close). La differenza più grande è che l'Hyper-Z ed il Lightspeed Memory architecture sono basati sulle aree....

Io non sto dicendo che gli algoritmi di ATi o nVidia siano difettosi o abbiano problemi, quello che sto tentando di dirti è che sono basati su un'impostazione di rendering che non ha niente a che fare con quella dei chip PowerVR.

I chip PowerVR creano per ogni tessera una triangle list in fase di setup dei triangoli, che viene poi utilizzata per sapere quali superfici sono visibili e quali no.

Quello che sto tentando di spiegarvi è che il Deferred Texturing ed il Tile Based Rendering sono due cose COMPLETAMENTE DISTINTE anche se complementari. Teoricamente se il buffer per la triangle list fosse abbastanza grande, i chip PowerVR potrebbero considerare la lista dei triangoli di tutta la scena e lavorare direttamente sull'intera scena. Il Tile Based Rendering gli consente di ridurre questo discorso a piccole zone di schermo andando ad ottimizzare anche ALTRE funzioni come lo Z-Buffer, lo Stencil Buffer ed il Frame Buffer che vengono quindi effettuante ONCHIP.

Le architetture di ATi e nVidia non effettuano nessuna delle operazioni suddette: non sono in grado di garantire al 100% l'applicazione dei soli texel visibili (e questo significa che in alcuni casi, seppur minimi, prelevano della memoria texture che di fatto alla fine non sono visualizzate), non effettuano nessuna operazione onchip (Z-Buffer, Stencil Buffer, Frame Buffer e compagnia bella sono tutti all'interno della memoria della scheda e pertanto per accerdervi si usa il bus delle memoria). Forse ci si sta avvicinando ad una concezione simile un po' con il F-Buffer di R350.... ma in quel caso l'uso è specifico per i Pixel Shader e non per altre funzioni.

Questa radicale diversità dalle altre architetture ha comportato per PowerVR moltissimi problemi di compatibilità con vari giochi (parlo principalmente dell'epoca della PowerVR Serie 1, cioè il PCX2 usato nella Matrox M3D).

La differenza sostanziale è proprio nel fatto che i chip PowerVR effettuano determinate operazioni all'interno del chip. In base al tuo discorso gli altri chip non operano tramite una lista delle posizioni dei vertici dei triangoli componenti la scena? Se sai come funziona il multitexturing all'interno di chip come NV20, NV25, NV3x, R200, R300 dovresti sapere che esiste necessariamente una lista delle posizioni dei vertici dei triangoli, poichè, per ogni texture applicata per ciclo di clock le suddette posizioni non vengono ricalcolate ma prelevate dalla suddetta lista. Inoltre, ti ripeto, tutti i chip, a partire dal Radeon 256, utilizzano la suddivisione in aree o tessere o chiamale come vuoi, più o meno grandi. Questa è l'unica differenza tangibile (che fa aumentare le prestazioni); il fatto che poi ad eseere analizzato sia un singolo pixel o un gruppo di 4 o 8 non mi pare cambi di molto la situazione (visto che, in pratica, giochi che presentano problemi con ATI o nVIDIA e non con PowerVR non mi pare ne esistano).

Per l'inglese hai ragione (non so perchè ho pensato a not so close :D )

Ti consiglio di riguardare il mio primo intervento (quello su cui sei a tua volta intervenuto) e anche i successivi.

L'F-Buffer non è l'unico esempio di utilizzo di un buffer interno; anche il multitexturing viene effettuato utilizzando cache interne (ATI lo fece la prima colta con il Rage 128), sulle consolle l'utilizzo di embedded ram è la regola; fino all'avvento del Kyro2 nessuno lo aveva utilizzato per effettuare operazioni di HSR: questa è l'unica vera novità del TBR. Infatti l'idea di utilizzare piccole porzioni di quadro è nata proprio dal fatto che tale sistema è inapplicabile a tutta l'immagine.

Vifani

03-06-2003, 22:42

Lo so che il multitexturing avviene attraverso una cache interna, ma si tratta di una cache di dimensioni piccolissime perché lavora solo su un singolo pixel. Diciamo che c'è una porzione di cache per ogni pipeline. Comunque è un discorso ben diverso dal buffer del Kyro che viene usato intensamente per moltissime operazioni. E' proprio l'insieme di queste operazioni ONCHIP il vantaggio rispetto a tutti gli altri prodotti. Ed è proprio per questo discorso che ritengo sia molto probabile che PowerVR stupisca con un chip che supporti VS e PS 3.0. Implementare loop o un maggiore numero di istruzioni non è un problema in questo genere di architettura.

E' sempre un piacere discutere con voi :)

yossarian

03-06-2003, 23:03

Originally posted by "Vifani"

Lo so che il multitexturing avviene attraverso una cache interna, ma si tratta di una cache di dimensioni piccolissime perché lavora solo su un singolo pixel. Diciamo che c'è una porzione di cache per ogni pipeline. Comunque è un discorso ben diverso dal buffer del Kyro che viene usato intensamente per moltissime operazioni. E' proprio l'insieme di queste operazioni ONCHIP il vantaggio rispetto a tutti gli altri prodotti. Ed è proprio per questo discorso che ritengo sia molto probabile che PowerVR stupisca con un chip che supporti VS e PS 3.0. Implementare loop o un maggiore numero di istruzioni non è un problema in questo genere di architettura.

E' sempre un piacere discutere con voi :)

Anche per me è un piacere discutere con te, soprattutto quando ci si riesce a capire :D .
Io non ho mai messo in discussione la bontà della soluzione di PowerVR di ricorrere il più possibile a cache interne (ai tempi del Kyro2 lo fece sia per il TBR che per il multitexturing); a dimostrazione della validità di queste scelte, anche gli altri stanno facendo ricorso con sempre maggior frequenza all'utilizzo di embedded ram (l'ultimo esempio è proprio l'f-buffer da te citato, che, tra l'altro, rientra proprio nelle specifiche PS3.0).
Anche la cache utilizzata per il multitexturing sta via via aumentando di dimensioni (non dimenticare che, con un'architettura tipo R3x0, con 8 pipelines, in realtà si lavora su 8 pixels contemporaneamente, su cui, secondo le specifiche DX9 si possono applicare fino a 16 textures per una; quindi rispetto ai buffer utilizzati per scopi analoghi su prodotti DX8 compatibili, le dimensioni sono notevolmente maggiori; mettici poi anche un'area riservata all'F-Buffer (per chi lo implementa)).

Ciao

Vifani

03-06-2003, 23:37

E' proprio l'insieme di questi fattori che mi fa presumere un chip a 0.13 micron per la Serie 5. Buffer interni così voluminosi di certo porteranno ad un prodotto abbastanza complesso, anche se si parla di una soluzione multichip: Vertex Processor + Image Processor. Vedremo...

Crisidelm

04-06-2003, 09:16

Tch, no, escluderei a priori la soluzione multichip...alla fin fine conviene (ergonomicamente/economicamente) integrare tutto in chip unico, sebbene molto complesso. 0.13 micron di certo, considerando poi l'ipotesi VS/PS 3.0 come valida, siamo sicuramente mooolto sopra ai 100 milioni di transistor per chip (non credo che verrà via per una briciola di pane, come costo finale...)...poi vediamo: pipeline e TMU secondo voi?

Vifani

04-06-2003, 10:29

Beh... considerando che PowerVR ha sempre usato una sola TMU per pipeline in virtù della sua architettura.... secondo me un 4x1 potrebbe andare benissimo. Non si esclude una famiglia di prodotti dedicati a diversi segmenti di mercato. Magari un 4x1 ed un 8x1 per coprire tutto il mercato.

Crisidelm

04-06-2003, 10:38

Una 8x2 la escludi a priori? Dico per il chip di massiam prestazione (sì, anche io penso che siano auspicabili diversi 'tagli' di chip per le varie necessità, di fasce e di prezzo...)

yossarian

04-06-2003, 13:47

Allo stato attuale l'architettura migliore è quella 8x1 della serie R3x0 con 4 unità VS. Quindi l'ideale sarebbe, per un chip di fascia alta, avere almeno 8 unità PS (reali e non le 8 finte della 4x2 delle FX) e 4 VS. Però, come dimostrano i risultati ottenuti dall'o/c delle R3x0, anche quest'architettura presenta un limite legato alla presenza di una sola TMU (l'o/c della GPU dà risultati decisamente migliori rispetto a quello della ram, quindi il calo di prestazioni ad alte risoluzioni, non si verifica tanto per limitata bandwidth, quanto per limitata capacita di elaborazione); se pensiamo alle specifiche DX9 ci rendiamo conto che, per poter applicare 16 textures per pixel, 2 è il numero minimo di TMU necessarie per non avere cali drammatici delle prestazioni (per quanto siano veloci i buffer interni il tempo di trasferimento non sarà mai prossimo allo zero). Ancora meglio sarebbe un'architettura 16x2 o 8x4 (avevamo la 4x2 per chip PS1.3 o PS1.4 che non richiedono più di 4/6 textures per single pass e lo stesso Kyro2 era si capace di applicare fino a 8 textures p.s.p., però lo abbiamo visto all'opera in situazioni reali in cui non venivano applicate più di 2 textures (DX7) o, al massimo, 3 o 4 (PS1.3) in sporadici casi).
Questo senza tener conto delle specifiche PS3.0 e VS3.0, che prevedono addirittura l'utilizzo di "infinite loop", per la codifica di shader di lunghezza teoricamente infinita (in stile f-buffer).
Insomma, per realizzare un chip che sia realmente DX9 (e non solo a livello di compatibilità teorica) le complicazioni sono notevoli.

DragonWizard

04-06-2003, 17:20

Non vi sto + seguendo!! Postate alla velocità della luce, probabilmente questo è simbolo di PURA ESPERIENZA NEL SETTORE SK VIDEO da parte ci alcuni utenti, ma x i lettori....raga, un freno! :D http://forum.hwupgrade.it/faccine/23.gif

Crisidelm

04-06-2003, 18:29

Beh Dragon, c'è qualcosa che non ti è chiaro allora? Chiedi :D

Vifani

04-06-2003, 20:21

Originally posted by "yossarian"

Allo stato attuale l'architettura migliore è quella 8x1 della serie R3x0 con 4 unità VS. Quindi l'ideale sarebbe, per un chip di fascia alta, avere almeno 8 unità PS (reali e non le 8 finte della 4x2 delle FX) e 4 VS. Però, come dimostrano i risultati ottenuti dall'o/c delle R3x0, anche quest'architettura presenta un limite legato alla presenza di una sola TMU (l'o/c della GPU dà risultati decisamente migliori rispetto a quello della ram, quindi il calo di prestazioni ad alte risoluzioni, non si verifica tanto per limitata bandwidth, quanto per limitata capacita di elaborazione); se pensiamo alle specifiche DX9 ci rendiamo conto che, per poter applicare 16 textures per pixel, 2 è il numero minimo di TMU necessarie per non avere cali drammatici delle prestazioni (per quanto siano veloci i buffer interni il tempo di trasferimento non sarà mai prossimo allo zero). Ancora meglio sarebbe un'architettura 16x2 o 8x4 (avevamo la 4x2 per chip PS1.3 o PS1.4 che non richiedono più di 4/6 textures per single pass e lo stesso Kyro2 era si capace di applicare fino a 8 textures p.s.p., però lo abbiamo visto all'opera in situazioni reali in cui non venivano applicate più di 2 textures (DX7) o, al massimo, 3 o 4 (PS1.3) in sporadici casi).
Questo senza tener conto delle specifiche PS3.0 e VS3.0, che prevedono addirittura l'utilizzo di "infinite loop", per la codifica di shader di lunghezza teoricamente infinita (in stile f-buffer).
Insomma, per realizzare un chip che sia realmente DX9 (e non solo a livello di compatibilità teorica) le complicazioni sono notevoli.

Dubito altamente in una soluzione con più di una TMU. Andrebbe contro quella che è la concezione stessa del loro sistema di rendering e cioè elaborare al massimo un texel per pixel. Fare più di una passata per ciclo di clock non è molto dispendioso. L'importante è non calcolare più di una volta la geometria della scena.

Escluderei inoltre qualsiasi soluzione che vada oltre 8x1. Personalmente ritengo che una soluzione PowerVR 8x1 sarebbe notevolmente più veloce rispetto a quanto vediamo negli attuali chip. Tuttavia non credo che PowerVR abbia intenzione di entrare nel mercato high-end..... anche se questo è quanto dicono loro stessi. Sarebbe un impegno molto grande, che richiederebbe uno sviluppo profondo e costante nel tempo.... vedremo....

yossarian

04-06-2003, 20:59

Originally posted by "Vifani"

Dubito altamente in una soluzione con più di una TMU. Andrebbe contro quella che è la concezione stessa del loro sistema di rendering e cioè elaborare al massimo un texel per pixel. Fare più di una passata per ciclo di clock non è molto dispendioso. L'importante è non calcolare più di una volta la geometria della scena.

Escluderei inoltre qualsiasi soluzione che vada oltre 8x1. Personalmente ritengo che una soluzione PowerVR 8x1 sarebbe notevolmente più veloce rispetto a quanto vediamo negli attuali chip. Tuttavia non credo che PowerVR abbia intenzione di entrare nel mercato high-end..... anche se questo è quanto dicono loro stessi. Sarebbe un impegno molto grande, che richiederebbe uno sviluppo profondo e costante nel tempo.... vedremo....

Con il passaggio alle DX8 e, ancor di più, con quello alle DX9, molti degli effetti prima riproducibili diversamente (ad esempio le trasparenze o l'effetto nebbia), passeranno tutte attraverso i PS (tramite l'applicazione di più textures per pixel). Poter svolgere più operazioni in contemporanea potrebbe rappresentare un vantaggio non indifferente soprattutto per un chip che invia le superfici da renderizzare direttamente alle unità PS, eliminando i tempi morti di trasferimento "alla e dalla ram video". Inoltre, tenendo conto che ATI è riuscita a infilare circa 110 mln di transistor su un chip a 0,15 u, implementando un buffer per il multitexturing (a 16 textures p.s.p.), un buffer per la codifica di istruzioni di lunghezza qualunque (f-buffer) e un'architettura 8x1 con 4 unità VS, credo che il passaggio a 0,13 u possa permettere l'implementazioni di tutto ciò, con in più un'architettura 8x2 e un ulteriore buffer per il TBR. Tieni anche conto che, proprio grazie al TBR, non si rende necessaria l'adozione del bus a 256 bit (a patto di usare ram DDR): questo comporta un ulteriore, seppur minimo risparmio di spazio, destinabile ad altri scopi, all'interno del chip.
Comunque, dopo l'esperienza R300/NV30, credo sia ormai chiaro a tutti che la politica di ottenere le prestazioni solo alzando all'inverosimile le frequenze è poco redditizia; quella che permette un reale balzo in avanti dal punto di vista delle prestazioni è l'architettura del chip (e in quanto a questo, già una volta, PowerVR ha dimostrato di saperci fare).

Crisidelm

05-06-2003, 09:19

E per quel che riguarda l'AA, che ci dovremmo aspettare? :)

Vifani

05-06-2003, 12:15

Naturalmente effettuare ONCHIP tutta una serie di operazioni comporta un notevole vantaggio anche per l'antialiasing. Nel core mobile MBX usato da Intel, Hitachi, STMicroelectronics, ARM, Texas Instrument, ecc... esiste il FSAA4Free, cioè un antialiasing 4x senza perdita di informazioni.

Penso che potremo aspettarci un qualcosa del genere, magari un FSAA8Free.

ATi7500

05-06-2003, 12:57

quindi se ho capito bene..è per qst ke la 7500 rulla ancora...per via delle sue TRE tmu...

bYeZ!

Simon82

05-06-2003, 13:17

Originally posted by "Vifani"

Naturalmente effettuare ONCHIP tutta una serie di operazioni comporta un notevole vantaggio anche per l'antialiasing. Nel core mobile MBX usato da Intel, Hitachi, STMicroelectronics, ARM, Texas Instrument, ecc... esiste il FSAA4Free, cioè un antialiasing 4x senza perdita di informazioni.

Penso che potremo aspettarci un qualcosa del genere, magari un FSAA8Free.
Informazioni? Volevi dire di frames? ;):D;)

E' tutto da vedere che l'FSAA di cui parlano sia veramente Free cmq.. ;)

yossarian

05-06-2003, 14:01

Originally posted by "ATi7500"

quindi se ho capito bene..è per qst ke la 7500 rulla ancora...per via delle sue TRE tmu...

bYeZ!

Si. E' qualcosa che a suo tempo non fu sfruttata a dovere dal SW; le DX7 prevedevano fino a 2 textures p.s.p., quindi le 2 TMU delle GF2 erano più che sufficienti ad effettuare i calcoli in un solo ciclo di clock, oltre che in una sola passata, inoltre le GF2 traevano vantaggio dalle 4 pipelines contro le 2 sole delle Radeon. L'utilizzo di più di 2 textures per pixel ha riequilibrato la situazione, poichè la Radeon può svolgere il compito richiesto, ad esempio, dai PS1.4 (fino a 6 textures p.s.p.) in 2 sole passate, contro le 3 delle GF2.

Crisidelm

05-06-2003, 15:03

Il Fsaa4Free nell'MBX è dovuto anche ai limiti di risoluzione degli screen (massimo massimo 640x480) dei PDA e simili...uhm...

Simon82

05-06-2003, 15:12

Originally posted by "Crisidelm"

Il Fsaa4Free nell'MBX è dovuto anche ai limiti di risoluzione degli screen (massimo massimo 640x480) dei PDA e simili...uhm...
Esatto.. ;)

Con la potenza che c'e' oggi un R300 potrebbe far sparire l'aliasing di un tft magari da 4" anche con 100 milioni di poligoni a frames e texture da 100mb l'una alle risoluzioni dei palmari/handled.. :D:D

ATi7500

05-06-2003, 15:13

Originally posted by "yossarian"

Si. E' qualcosa che a suo tempo non fu sfruttata a dovere dal SW; le DX7 prevedevano fino a 2 textures p.s.p., quindi le 2 TMU delle GF2 erano più che sufficienti ad effettuare i calcoli in un solo ciclo di clock, oltre che in una sola passata, inoltre le GF2 traevano vantaggio dalle 4 pipelines contro le 2 sole delle Radeon. L'utilizzo di più di 2 textures per pixel ha riequilibrato la situazione, poichè la Radeon può svolgere il compito richiesto, ad esempio, dai PS1.4 (fino a 6 textures p.s.p.) in 2 sole passate, contro le 3 delle GF2.

sei stato molto chiaro..ma mi spieghi come può essere che un architettura come quella della geffo4mx (2*2) possa in alcuni casi (vedi quake3) superare l'efficienza di quella del radeon?

bYeZ!

Crisidelm

05-06-2003, 15:36

Peccato che una R300 su un palmare ti fonderebbe direttamente il palmare, mentre l'MBX nella sua configurazione migliore riesce a fare 320-350MFLOPs pur rimanendo un dispositivo per PDA...Lo sai, ad ATI piacerebbe da morire entrare nel mercato handheld/PDA, solo che non ha alcun progetto che possa arrivare a soddisfare appieno le specifiche OpenGL 1.0 ES, che sono state concordate da Imagination Technologies (aka PowerVR) ed ARM: probabilmente ATI presenterà qualcosa per quel mercato per la fine dell'anno, o per l'inizio del prossimo, ma cmq restando ben lontana dalle prestazioni di un MBX...

yossarian

05-06-2003, 16:16

Originally posted by "ATi7500"

sei stato molto chiaro..ma mi spieghi come può essere che un architettura come quella della geffo4mx (2*2) possa in alcuni casi (vedi quake3) superare l'efficienza di quella del radeon?

bYeZ!

Dove non viene utilizzata la terza TMU (Q3 è DX7) e a risoluzioni non elevatissime o con i filtri disattivati, quella che conta è la frequenza di funzionamento del chip. Con Q3 un'architettura 2x2 equivale ad una 2x3; la terza TMU inizia ad acuistare importanza quando le textures da applicare sono più di due per ogni pixel; particolari vantaggi si hanno nel caso di 3, o in quello di 5 o più textures (con 4 il vantaggio di avere 3 TMU è molto relativo poichè occorrono, comunque 2 cicli di clock sia per la 2x2 che per la 2x3).

ATi7500

05-06-2003, 16:26

Originally posted by "yossarian"

Dove non viene utilizzata la terza TMU (Q3 è DX7) e a risoluzioni non elevatissime o con i filtri disattivati, quella che conta è la frequenza di funzionamento del chip. Con Q3 un'architettura 2x2 equivale ad una 2x3; la terza TMU inizia ad acuistare importanza quando le textures da applicare sono più di due per ogni pixel; particolari vantaggi si hanno nel caso di 3, o in quello di 5 o più textures (con 4 il vantaggio di avere 3 TMU è molto relativo poichè occorrono, comunque 2 cicli di clock sia per la 2x2 che per la 2x3).

già, peccato che la 7500 abbia 290 MHz di clock...e poi il discorso si estende anche a UT 2003, 3dmark 2001 ed altri...ke dovrebbero a qnt so io utilizzare la 3 TMU..può essere secondo te ancora un'inefficienza di driver? personalmente credo ancora in possibili miglioramenti via driver della 7500...

bYeZ!

yossarian

05-06-2003, 19:40

Originally posted by "ATi7500"

già, peccato che la 7500 abbia 290 MHz di clock...e poi il discorso si estende anche a UT 2003, 3dmark 2001 ed altri...ke dovrebbero a qnt so io utilizzare la 3 TMU..può essere secondo te ancora un'inefficienza di driver? personalmente credo ancora in possibili miglioramenti via driver della 7500...

bYeZ!

Sicuramente i drivers giocano un ruolo importante. Purtroppo non è vero che i drivers unificati diano gli stessi risultati su tutti i chip (per quanto diversi tra loro); e sappiamo bene, anche, che i produttori di chip tendono a concentrare le attenzioni e, di conseguenza le ottimizzazioni, sugli ultimi prodotti usciti (ci sono quelli che abbandonano letteralmente i precedenti prodotti).

Vifani

05-06-2003, 23:01

Il FSAA4Free non è una tecnica senza perdita di informazioni perché viene applicata su uno schermo di piccole dimensioni e ad una risoluzione bassa. Questo discorso non è valido perché non stiamo parlando di R300 che lavora a 320x200, ma di un core mobile che lavora a 320x200. Pertanto il problema del degrado delle prestazioni esiste anche in questo campo (i sistemi Intel integrati et simila non la offrono e non è un caso). E' semplicemente un sistema che effettua l'antialiasing senza perdita di prestazioni. La cosa è fattibile con il TBR perché essendo una operazione ONCHIP, non va a gravare sulla banda passante (cosa che avviene anche su R300 e company). Non so se hanno ideato un sistema di calcolo dei subpixel senza perdita di cicli di clock....... tutto è possibile.

In ogni caso dovete tener conto che nei sistemi come i palmari o i cellulari, essendo la risoluzione molto bassa, l'antialiasing è quasi una priorità. Probabilmente il FSAA4Free potrebbe anche essere dispendioso da implementare in un chip grafico per PC. A mio parere un antialiasing Multisampling sarebbe più che sufficiente.

A livello più generico, dubito in architetture troppo complesse come una 8x2 o cose simili semplicemente per due motivi:

1) Sono convinto che PowerVR a parità di architettura e frequenza ha un notevole vantaggio in termini di prestazioni;
2) Sono altrettanto convinto che PowerVR, visto che dubito in una sua improvvisazione da produttore, non proporrebbe mai a nessun produttore un chip grafico costoso da realizzare.

Crisidelm

06-06-2003, 12:02

Da una pagina di Simon Fenney (chi è Simon Fenney? Beh, uno di PowerVR) :)
http://simonnihal.homestead.com/files/assorted3d/examples.gif

Vifani

06-06-2003, 18:49

Bene.... vedremo come va a finire.

Mecoita

06-06-2003, 20:08

Originally posted by "Vifani"

Bene.... vedremo come va a finire.

dimmi Vifani ... sei assolutamente certo che questo nuovo chip sarà un Deferred Renderer ? ^_^

Vifani

06-06-2003, 22:20

Originally posted by "Mecoita"

dimmi Vifani ... sei assolutamente certo che questo nuovo chip sarà un Deferred Renderer ? ^_^

Non sono certo io, è stata PowerVR a dire che la Serie 5 continuerà lo sviluppo della tecnologia Tile Based Rendering e Deferred Texturing con in più l'aggiunta di funzionalità di Vertex e Pixel Shading programmabili.

Queste sono cose certe. Le cose incerte sono sempre lo stesse: non si sa il produttore, non si sanno i tempi (dicono quest'anno ma non mi sorprenderebbe uno slittamento al CeBIT 2004), non si sanno le caratteristiche tecniche (frequenze, pipeline, TMU, antialiasing, ecc...).
Bisogna dire che PowerVR è sempre stata bravissima nel tener nascoste tutte le informazioni sui propri prodotti fino a 2-3 giorni prima del lancio ufficiale.

Crisidelm

07-06-2003, 10:18

Sul fatto che sarà un Deferred Renderer con TBR non c'è proprio da aver dubbi...è tutto il resto che è nebbioso :)
Già che ci sono, dico cosa mi sento io: verrà presentato quest'anno, si troverà in commercio per Natale, a un prezzo, diciamo 399€ vah (la versione più performante)...

Vifani

07-06-2003, 12:39

Originally posted by "Crisidelm"

Sul fatto che sarà un Deferred Renderer con TBR non c'è proprio da aver dubbi...è tutto il resto che è nebbioso :)
Già che ci sono, dico cosa mi sento io: verrà presentato quest'anno, si troverà in commercio per Natale, a un prezzo, diciamo 399€ vah (la versione più performante)...

Io, invece, sono fermamente convinto che verrà presentato durante una fiera. Imagination Technologies non è in grado di organizzare una presentazione in grande stile.... hanno sempre usato il CeBIT che del resto è la fiera più importante al mondo.

Magari se mi fate un elenco delle fiere con relative date che sono previste da ora alla fine dell'anno..... ci possiamo fare un'idea. Del resto anche ATi e nVidia, se non hanno fretta, presentano nuovi prodotti durante le fiere.