Torna indietro   Hardware Upgrade Forum > Componenti Hardware > Schede Video > Schede Video - Discussioni generali

ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono
Da ASUS un monitor particolare ma molto completo: principalmente indirizzato al videogiocatore, può essere sfruttato con efficacia anche per attività creative e di produzione multimediale
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza
Il nuovo robot aspirapolvere domestico di Dreame abbina funzionalità complete a un moccio flottante che raggiunge al meglio gli angoli delle pareti. Un prodotto tutto in uno semplice da utilizzare ma molto efficace, in grado di rispondere al meglio alle necessità di pulizia della casa
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere
HONOR ha introdotto con Magic6 Pro la funzione Magic Portal che consente, tramite intelligenza artificiale, di suggerire scorciatoie agli utenti in modo da permettere di passare e accedere facilmente ai servizi tra app e dispositivi con un semplice tocco. Vi spieghiamo qui come funziona
Tutti gli articoli Tutte le news

Vai al Forum
Rispondi
 
Strumenti
Old 12-08-2005, 00:03   #61
shodan
Senior Member
 
L'Avatar di shodan
 
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
Quote:
Originariamente inviato da capellone24
per essere dietro lo era io le ho avute entrambe...però c'è da dire che il Kyro costava circa il 40% in meno se non ricordo male...se avessero fatto un Kyro 3 (a quei tempi se ne parlava molto...poi invece lo abbandonarono...) di sicuro avrebbero recuperato il gap con Nvidia perchè sulla carta il kyro muove molti poligoni in meno del geffo2 solo che come dice Mc Turbo invece di renderizzare le texture indistintamente salvo poi fare il controllo sullo Zbuffer come faceva Geffo2 ,eseguiva prima il controllo sullo Zbuffer determinava le parti di scena effettivamente visibili e ne eseguiva il rendering diminuendo i calcoli dal 30 al 60% in media (mi pare che dichiarassero allora...)
un vero peccato anche perchè il Chip mi pare lo facessero a Catania se non sbaglio...
Ciauz.
Ciao,
in realtà le grandi prestazioni del Kyro non erano dovute a un non disegno dei poligoni nascosti, ma alla non renderizzazione delle loro superfici. La differenza può non essere palese, ma è significativa: il chip Kyro elabora TUTTI i poligoni . Per meglio spiegarmi:
-) la CPU elabora TUTTI i vertici della scena;
-) durante l'operazione di scan line l'unita di triangle setup del Kyro elabora TUTTI i poligoni;
-) durante la selezione dei poligoni e la costruzione della triangle list appartenente a un determinato tile vengono elaborati TUTTI i poligoni (o le parti di essi) presenti nel tile stesso;
-) durante l'operazione di rendering vengono elaborate SOLO le parti visibili dei poligoni contenuti nella triangle list, questo porta il chip Kyro a renderizzare SOLO le parti visibili del frame corrente (deferred rendering).

Anche il chip Kyro elabora quindi tutta la geometria della scena.
In pratica il vantaggio prestazionale è presente "solo" nella fase di rendering. Dato però che come sosteneva 3dfx "fill-rate is the king" (affermazione che ancora la sua validità, sebbene ridimensionata parecchio rispetto a qualche anno fa), il guadagno ottenibile nel rendering permetteva al chip Kyro di avvicinare parecchio le schede GeForce2 e in alcuni casi addirittura superarle (non molto spesso però e solo con giochi aventi un alto overdraw).

Ciao.

Ultima modifica di shodan : 12-08-2005 alle 00:06.
shodan è offline   Rispondi citando il messaggio o parte di esso
Old 12-08-2005, 02:20   #62
Vifani
Senior Member
 
Iscritto dal: Apr 2001
Città: Bari
Messaggi: 2774
Quote:
Originariamente inviato da shodan
Anche il chip Kyro elabora quindi tutta la geometria della scena.
In pratica il vantaggio prestazionale è presente "solo" nella fase di rendering. Dato però che come sosteneva 3dfx "fill-rate is the king" (affermazione che ancora la sua validità, sebbene ridimensionata parecchio rispetto a qualche anno fa), il guadagno ottenibile nel rendering permetteva al chip Kyro di avvicinare parecchio le schede GeForce2 e in alcuni casi addirittura superarle (non molto spesso però e solo con giochi aventi un alto overdraw).
La realtà è che "fill-rate is the king" è un'affermazione oggi ancora più valida che in passato anche se oggi potremmo evolverla in "pixel-shading is the king". Mi spiego: il Kyro non renderizzava le superfici nascoste e cioè, dal punto di vista poligonale le trattava come tutte le altre, solo che al momento del rendering, e cioè per l'epoca essenzialmente l'applicazione delle textures, evitava di caricare tutte quelle texture che non si vedevano. Risultato: molta banda passante risparmiata.

Oggi questo risparmio sarebbe ancora più significativo perché non si tratta più semplicemente di non applicare le texture, ma di non elaborare tutti i pixel shaders legati ai pixel delle superfici nascoste. Immaginate il risparmio non solo di banda passante, ma di calcolo in generale. Del resto PowerVR ha presentato recentemente la Serie 5 con un'architettura a shading unificato (teoricamente simile a quella di R500) e con specifiche che superano quelle delle DirectX 9.0c e OpenGL 2.0. Ahimè il suo impegno è ormai concentrato nel mercato mobile dove ovviamente è leader (poca potenza di calcolo e alte prestazioni = una manna per i chip a basso consumo energetico) e persino Intel ha acquisito la sua licenza per lo sviluppo di chip mobile. Un esempio è il chip grafico alla base del palmare Dell Axim X50v, ma sono in arrivo anche cellulari con tecnologia PowerVR prodotti da Philips ed altri.

Coloro che prevedevano un incremento mostruoso della complessità poligonale dei videogames e, quindi, una importanza sempre + secondaria del fill rate, hanno sbagliato completamente previsione perché tutte le tecniche così avanzate che vediamo oggi come il bump mapping o il parallax mapping sono volte proprio al massimo risparmio poligonale e personalmente ritengo che anche quando si inizierà ad usare il displacement mapping attraverso vertex fetch, comunque là dove si potrà risparmare geometria, lo si farà sempre. Insomma secondo me nella grafica in tempo reale si sarà sempre limitati dalla capacità di elaborare pixelshader/texture e mai limitati dalla scarsa capacità poligonale.
__________________
Raffaele Fanizzi
My Personal Web Site
Membro Jedi del HWU Star Wars Clan
Vifani è offline   Rispondi citando il messaggio o parte di esso
Old 12-08-2005, 11:36   #63
shodan
Senior Member
 
L'Avatar di shodan
 
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
Quote:
Originariamente inviato da Vifani
La realtà è che "fill-rate is the king" è un'affermazione oggi ancora più valida che in passato anche se oggi potremmo evolverla in "pixel-shading is the king". Mi spiego: il Kyro non renderizzava le superfici nascoste e cioè, dal punto di vista poligonale le trattava come tutte le altre, solo che al momento del rendering, e cioè per l'epoca essenzialmente l'applicazione delle textures, evitava di caricare tutte quelle texture che non si vedevano. Risultato: molta banda passante risparmiata.

Oggi questo risparmio sarebbe ancora più significativo perché non si tratta più semplicemente di non applicare le texture, ma di non elaborare tutti i pixel shaders legati ai pixel delle superfici nascoste. Immaginate il risparmio non solo di banda passante, ma di calcolo in generale. Del resto PowerVR ha presentato recentemente la Serie 5 con un'architettura a shading unificato (teoricamente simile a quella di R500) e con specifiche che superano quelle delle DirectX 9.0c e OpenGL 2.0. Ahimè il suo impegno è ormai concentrato nel mercato mobile dove ovviamente è leader (poca potenza di calcolo e alte prestazioni = una manna per i chip a basso consumo energetico) e persino Intel ha acquisito la sua licenza per lo sviluppo di chip mobile. Un esempio è il chip grafico alla base del palmare Dell Axim X50v, ma sono in arrivo anche cellulari con tecnologia PowerVR prodotti da Philips ed altri.

Coloro che prevedevano un incremento mostruoso della complessità poligonale dei videogames e, quindi, una importanza sempre + secondaria del fill rate, hanno sbagliato completamente previsione perché tutte le tecniche così avanzate che vediamo oggi come il bump mapping o il parallax mapping sono volte proprio al massimo risparmio poligonale e personalmente ritengo che anche quando si inizierà ad usare il displacement mapping attraverso vertex fetch, comunque là dove si potrà risparmare geometria, lo si farà sempre. Insomma secondo me nella grafica in tempo reale si sarà sempre limitati dalla capacità di elaborare pixelshader/texture e mai limitati dalla scarsa capacità poligonale.
Be', c'è da dire che ATI e Nvidia (rispettivamente da R300 e NV30) ormai hanno sviluppato algoritmi di HSR che permettono di scartare la maggior parte (se non la totalità) dei pixel non visibili. Infatti entrambi i chip, prima di renderizzare i pixel, controllano che questi siano visibili (prima tramite comparazione dei valori Z su una tabella pivot ottenuta precedentemente e poi, se necessario, direttamente caricando on chip la tile in questione e effettuando un controllo alla display resolution, quindi pixel per pixel).
In caso disegno back-to-front comunque il Kyro dovrebbe avere un certo vantaggio, situazione che si ribalta utilizzando un rendering front-to-back.

Ciao.
shodan è offline   Rispondi citando il messaggio o parte di esso
Old 12-08-2005, 20:40   #64
Vifani
Senior Member
 
Iscritto dal: Apr 2001
Città: Bari
Messaggi: 2774
Quote:
Originariamente inviato da shodan
Be', c'è da dire che ATI e Nvidia (rispettivamente da R300 e NV30) ormai hanno sviluppato algoritmi di HSR che permettono di scartare la maggior parte (se non la totalità) dei pixel non visibili. Infatti entrambi i chip, prima di renderizzare i pixel, controllano che questi siano visibili (prima tramite comparazione dei valori Z su una tabella pivot ottenuta precedentemente e poi, se necessario, direttamente caricando on chip la tile in questione e effettuando un controllo alla display resolution, quindi pixel per pixel).
In caso disegno back-to-front comunque il Kyro dovrebbe avere un certo vantaggio, situazione che si ribalta utilizzando un rendering front-to-back.

Ciao.
Ormai il deferred shading in sè non è + un grandissimo vantaggio per PowerVR perché, come hai già detto tu, NVIDIA e ATI hanno sviluppato tecniche di HSR molto efficienti. Restano i vantaggi (e gli svantaggi) di un'architettura completamente Tile Based.

Il discorso back-to-front e front-to-back che fai è corretto, ma considera che è abitudine comune ormai nei motori grafici fare una prima passata solo di scrittura nello zbuffer in maniera da consentire ai processori grafici di fare HSR indipendentemente dall'ordine con cui successivamente il motore grafico invia i dati alla GPU. Quindi alla fine anche in questo campo grossi vantaggi PowerVR non ne ha più.
__________________
Raffaele Fanizzi
My Personal Web Site
Membro Jedi del HWU Star Wars Clan
Vifani è offline   Rispondi citando il messaggio o parte di esso
Old 13-08-2005, 01:16   #65
shodan
Senior Member
 
L'Avatar di shodan
 
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
Quote:
Originariamente inviato da Vifani
Ormai il deferred shading in sè non è + un grandissimo vantaggio per PowerVR perché, come hai già detto tu, NVIDIA e ATI hanno sviluppato tecniche di HSR molto efficienti. Restano i vantaggi (e gli svantaggi) di un'architettura completamente Tile Based.
Perfettamente d'accordo, ma non considerando l'ottimo HSR i vantaggi propri di questo approccio si riducono notevolmente. Rimane però la capacità di applicare i filtri (in particolare l'AA) in maniera più veloce rispetto a un approccio classico, questo perchè i calcoli relativi ai filtri vengono eseguiti direttamente a livello di tile, che è completamente contenuta nella cache del chip (si libera così parecchia banda dal frame buffer). Altri vantaggi che reputo molto interessanti sono la capacità di operare senza tenere uno z-buffer nel frame buffer e l'ottimizzazione degli accessi alla RAM video (essendo le tile sempre di dimensione fissa).
Gli svantaggi però sono abbastanza onerosi:
-) è richiesta parecchia potenza elaborativa da parte del chip grafico per creare la triangle list;
-) è richiesta una cache di notevoli dimensioni on-chip per effettuare il caching di tile sempre più grandi;
-) come conseguenza delle due indicazioni precedenti in genere i chip tile based soffrono parecchio nel salire di frequenza;
-) ci possono a volte essere problemi con le trasparenze (esempio: M3D, Neon250 e, in misura molto più limitata, Kyro).

Detto questo, devo comunque riconoscere che un'architettura completamente tile based mi affascina molto, e sarei stato molto curioso di vedere cosa stava combinando Gigapixel prima dell'acquisizione da parte di 3dfx. Inoltre credo sarebbe stato davvero interessante vedere sul mercato un chip completamente tile based con potenza "grezza" paragonabile ai chip odierni: probabilmente sarebbe venuto fuori qualcosa di veramente valido.

Quote:
Il discorso back-to-front e front-to-back che fai è corretto, ma considera che è abitudine comune ormai nei motori grafici fare una prima passata solo di scrittura nello zbuffer in maniera da consentire ai processori grafici di fare HSR indipendentemente dall'ordine con cui successivamente il motore grafico invia i dati alla GPU. Quindi alla fine anche in questo campo grossi vantaggi PowerVR non ne ha più.
Interessante... credevo che a usare questa tecnica fossero solo i motori di Doom3 (e derivati) e dei 3dmark2003-2005. Ci sono molto altri motori che fanno lo stesso?

Ciao.

Ultima modifica di shodan : 13-08-2005 alle 01:18.
shodan è offline   Rispondi citando il messaggio o parte di esso
Old 13-08-2005, 02:01   #66
Vifani
Senior Member
 
Iscritto dal: Apr 2001
Città: Bari
Messaggi: 2774
Quote:
Originariamente inviato da shodan
Perfettamente d'accordo, ma non considerando l'ottimo HSR i vantaggi propri di questo approccio si riducono notevolmente. Rimane però la capacità di applicare i filtri (in particolare l'AA) in maniera più veloce rispetto a un approccio classico, questo perchè i calcoli relativi ai filtri vengono eseguiti direttamente a livello di tile, che è completamente contenuta nella cache del chip (si libera così parecchia banda dal frame buffer). Altri vantaggi che reputo molto interessanti sono la capacità di operare senza tenere uno z-buffer nel frame buffer e l'ottimizzazione degli accessi alla RAM video (essendo le tile sempre di dimensione fissa).
Gli svantaggi però sono abbastanza onerosi:
-) è richiesta parecchia potenza elaborativa da parte del chip grafico per creare la triangle list;
-) è richiesta una cache di notevoli dimensioni on-chip per effettuare il caching di tile sempre più grandi;
-) come conseguenza delle due indicazioni precedenti in genere i chip tile based soffrono parecchio nel salire di frequenza;
-) ci possono a volte essere problemi con le trasparenze (esempio: M3D, Neon250 e, in misura molto più limitata, Kyro).
Non so come e se PowerVR abbia risolto i problemi relativi alle scene dotate di un grande numero di poligoni. Proponendo oggi un'architettura unificata, presumo di si, ma in generale comunque è ovvio che la loro architettura è fatta per sistemi fillrate/pixelshader limited e non di certo per scene geometricamente molto complesse.
La dimensione delle tile è fissa (32x16 sul Kyro e Kyro II), quindi la cache non varia.
I problemi della trasparenze sono una cosa completamente a parte e slegata dall'architettura PowerVR: PCX1, PCX2 e Neon250 non supportavano letteralmente molte modalità di blending. Tutto qui. Il Kyro di problemi di blending non ha mai sofferto, anzi ha sempre sfoggiato ottimi risultati qualitativi grazie al calcolo interno sempre a 32 bit.

Quote:
Originariamente inviato da shodan
Detto questo, devo comunque riconoscere che un'architettura completamente tile based mi affascina molto, e sarei stato molto curioso di vedere cosa stava combinando Gigapixel prima dell'acquisizione da parte di 3dfx. Inoltre credo sarebbe stato davvero interessante vedere sul mercato un chip completamente tile based con potenza "grezza" paragonabile ai chip odierni: probabilmente sarebbe venuto fuori qualcosa di veramente valido.


Interessante... credevo che a usare questa tecnica fossero solo i motori di Doom3 (e derivati) e dei 3dmark2003-2005. Ci sono molto altri motori che fanno lo stesso?

Ciao.
In generale una prima passata per motori come quello di Doom 3, Fear (che usa sempre stencil shadows) o quello del 3DMark05, è necessaria perché quando si usano le stencil shadows o le shadow maps, l'implementazione classica prevede una prima passata di rendering per inizializzare lo zbuffer, dopodiché non ci si scrive più e si fanno solo confronti usando lo stencil buffer in un caso e le depth map nell'altro. Per gli altri a dirla tutta non lo so, ma ormai penso che fare questa prima passata sia sempre conveniente a meno che non si preveda di far girare scene con un basso livello di overdraw.

P.S: Scusate per l'offtopic.
__________________
Raffaele Fanizzi
My Personal Web Site
Membro Jedi del HWU Star Wars Clan
Vifani è offline   Rispondi citando il messaggio o parte di esso
Old 13-08-2005, 08:51   #67
shodan
Senior Member
 
L'Avatar di shodan
 
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
Quote:
Originariamente inviato da Vifani
Non so come e se PowerVR abbia risolto i problemi relativi alle scene dotate di un grande numero di poligoni. Proponendo oggi un'architettura unificata, presumo di si, ma in generale comunque è ovvio che la loro architettura è fatta per sistemi fillrate/pixelshader limited e non di certo per scene geometricamente molto complesse.
La dimensione delle tile è fissa (32x16 sul Kyro e Kyro II), quindi la cache non varia.
D'accordo, anche se ricordo che la tendenza era quella di allargare sempre più le tile in modo da effettuare più velocemente i calcoli di overdraw (ma potrebbe essere una tecnica usata solo sulle architetture che utilizzano delle tabelle pivot per una prima comparazione, dovrei verificare ).
Quote:
I problemi della trasparenze sono una cosa completamente a parte e slegata dall'architettura PowerVR: PCX1, PCX2 e Neon250 non supportavano letteralmente molte modalità di blending. Tutto qui. Il Kyro di problemi di blending non ha mai sofferto, anzi ha sempre sfoggiato ottimi risultati qualitativi grazie al calcolo interno sempre a 32 bit.
Oltre alle modalità di blending non supportate (problema che giustamente non esisteva sul Kyro) il punto è che le superfici trasparenti sono teoricamente più ostiche da gestire su un'unità a piastrelle piuttosto che su una tradizionale. Guardando il Kyro non ci se ne accorge nemmeno, dato che PowerVR ha fatto davvero un ottimo lavoro, anche se a detta degli utenti di questo chip c'è qualche gioco che ha problemi proprio con le trasparenze...
Comunque il mio era un discorso teorico, non legato direttamente al chip Kyro; probabilmente mi sono espresso male.
Quote:
In generale una prima passata per motori come quello di Doom 3, Fear (che usa sempre stencil shadows) o quello del 3DMark05, è necessaria perché quando si usano le stencil shadows o le shadow maps, l'implementazione classica prevede una prima passata di rendering per inizializzare lo zbuffer, dopodiché non ci si scrive più e si fanno solo confronti usando lo stencil buffer in un caso e le depth map nell'altro. Per gli altri a dirla tutta non lo so, ma ormai penso che fare questa prima passata sia sempre conveniente a meno che non si preveda di far girare scene con un basso livello di overdraw.

P.S: Scusate per l'offtopic.
Già, su scene con alto overdraw questo approccio deve dare risultati notevoli, anche se a giudicare dei vari Doom3/Fear/3Dmark non mi sembra un fulmine...

Ciao.
shodan è offline   Rispondi citando il messaggio o parte di esso
Old 13-08-2005, 14:28   #68
Vifani
Senior Member
 
Iscritto dal: Apr 2001
Città: Bari
Messaggi: 2774
Quote:
Originariamente inviato da shodan
Già, su scene con alto overdraw questo approccio deve dare risultati notevoli, anche se a giudicare dei vari Doom3/Fear/3Dmark non mi sembra un fulmine...

Ciao.
Beh Doom3, Fear ed il 3DMark05 hanno motori grafici caratterizzati da illuminazione quasi completamente dinamica e, in tal senso, la proiezione delle ombre di tipo stencil o shadow map è un'operazione estremamente gravosa, ecco perché sono molto pesanti. Se disabiliti le ombre le prestazioni si risollevano alla grande.
__________________
Raffaele Fanizzi
My Personal Web Site
Membro Jedi del HWU Star Wars Clan
Vifani è offline   Rispondi citando il messaggio o parte di esso
Old 13-08-2005, 23:50   #69
shodan
Senior Member
 
L'Avatar di shodan
 
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
Quote:
Originariamente inviato da Vifani
Beh Doom3, Fear ed il 3DMark05 hanno motori grafici caratterizzati da illuminazione quasi completamente dinamica e, in tal senso, la proiezione delle ombre di tipo stencil o shadow map è un'operazione estremamente gravosa, ecco perché sono molto pesanti. Se disabiliti le ombre le prestazioni si risollevano alla grande.
Si, infatti con il mio sistema (XP 3000+ e Radeon 9800Pro) la disabilitazione delle ombre in Doom3 comporatava parecchi frame al secondo di differenza.
Ultima domanda OT e poi la smetto, prometto : giochi come Doom3 si avvantaggiano automaticamente della tecnologia ultrashadow tipica dei chip NV30/NV40 oppure il gioco deve essere programmato appositamente per sfruttarla?

Ciao.

PS: Murakami aspetto i risultati del test che ti ho chiesto...
shodan è offline   Rispondi citando il messaggio o parte di esso
Old 14-08-2005, 02:44   #70
Vifani
Senior Member
 
Iscritto dal: Apr 2001
Città: Bari
Messaggi: 2774
Quote:
Originariamente inviato da shodan
Si, infatti con il mio sistema (XP 3000+ e Radeon 9800Pro) la disabilitazione delle ombre in Doom3 comporatava parecchi frame al secondo di differenza.
Ultima domanda OT e poi la smetto, prometto : giochi come Doom3 si avvantaggiano automaticamente della tecnologia ultrashadow tipica dei chip NV30/NV40 oppure il gioco deve essere programmato appositamente per sfruttarla?

Ciao.

PS: Murakami aspetto i risultati del test che ti ho chiesto...
La tecnologia Ultrashadow si compone di diverse funzionalità. NV30/NV40/G70 elaborano il doppio dei pixel (anzi, sarebbe + corretto chiamarli fragment) al secondo quando scrivono nel solo zbuffer o nel solo stencil buffer, rispetto a quanti ne elaborano scrivendo verso il frame buffer. Per avvalersi di questo non si ha bisogno di alcuna ottimizzazione specifica: è sufficiente disabilitare la scrittura verso il frame buffer ed abilitare il solo z buffer o il solo stencil buffer. Una funzionalità che, invece, richiede una implementazione specifica è il depth bound test supportato dalla tecnologa ultrashadow e che, essenzialmente, nel calcolo delle stencil shadows consente di ridurre il numero di test effettuati con lo stencil buffer. Doom 3 supporta questa features.
__________________
Raffaele Fanizzi
My Personal Web Site
Membro Jedi del HWU Star Wars Clan
Vifani è offline   Rispondi citando il messaggio o parte di esso
Old 14-08-2005, 11:03   #71
shodan
Senior Member
 
L'Avatar di shodan
 
Iscritto dal: Sep 2001
Città: Pescara
Messaggi: 3695
Quote:
Originariamente inviato da Vifani
La tecnologia Ultrashadow si compone di diverse funzionalità. NV30/NV40/G70 elaborano il doppio dei pixel (anzi, sarebbe + corretto chiamarli fragment) al secondo quando scrivono nel solo zbuffer o nel solo stencil buffer, rispetto a quanti ne elaborano scrivendo verso il frame buffer. Per avvalersi di questo non si ha bisogno di alcuna ottimizzazione specifica: è sufficiente disabilitare la scrittura verso il frame buffer ed abilitare il solo z buffer o il solo stencil buffer.
Si, infatti ricordavo che la possibilità di scrivere due valori z per pipeline è una feature che non ha bisogno di implementazioni specifiche...
Quote:
Una funzionalità che, invece, richiede una implementazione specifica è il depth bound test supportato dalla tecnologa ultrashadow e che, essenzialmente, nel calcolo delle stencil shadows consente di ridurre il numero di test effettuati con lo stencil buffer. Doom 3 supporta questa features.
Ok, ricordavo bene anche in questo caso... questa feature è disponibile solo su NV30/NV40, vero? Non mi pare che i chip NV20/NV25 la supportassero (e infatti il loro vantaggio in giochi come Doom3 è ridotto...)
shodan è offline   Rispondi citando il messaggio o parte di esso
Old 14-08-2005, 13:30   #72
Maury
Senior Member
 
L'Avatar di Maury
 
Iscritto dal: Feb 2000
Messaggi: 10529
Complimenti per la prova, mi è piaciuta molto, poi che ricordi meravigliosi che mi ha suscitato
__________________
PC 1 : |NZXT 510i|MSI PRO Z690 A|I5 13600kf@5.6 Ghz (Pcore) 4.5 Ghz (Ecore)|AIO ENDORFY NAVI F280|32 GB BALLISTIX 3600@3900 cl 16 g1|GIGABYTE 4070 SUPER AERO OC|RM850X|850 EVO 250|860 EVO 1TB|NVMe XPG-1TB||LG OLED C1 - 55 |

PC 2 : |Itek Vertibra Q210|MSI PRO B660M-A|I5 12500|32 GB KINGSTON RENEGADE 3600|ARC A770 LE 16 Gb|MWE 750w|

ARC 770 LE 16 Gb Vs RTX 3070 - CLICCA QUI
Maury è offline   Rispondi citando il messaggio o parte di esso
Old 14-08-2005, 16:57   #73
Bescio
Senior Member
 
L'Avatar di Bescio
 
Iscritto dal: Dec 2003
Città: Merate
Messaggi: 1620
Quote:
Originariamente inviato da Martufo
bevo... e sono felice
Quote:
Originariamente inviato da Murakami
Ciao Bescio, basta bere...
'stardiiiiii ....
Bescio è offline   Rispondi citando il messaggio o parte di esso
Old 16-08-2005, 13:33   #74
conan_75
Senior Member
 
Iscritto dal: Sep 2002
Città: Cagliari
Messaggi: 16380
Eccomi, mi aggiungo ufficialmente alla discussione mettendo alcuni dati sulla V5 5500.
Al momento sto scaricando la demo di UT2003 con cui farò dei bench su D3D.
Per l'OGL userò Quake3.
Datemi giusto il tempo di trovare un monitor perchè quello del babbo da 14" che avrei dovuto usare per i test è saltato
conan_75 è offline   Rispondi citando il messaggio o parte di esso
Old 17-08-2005, 15:11   #75
Murakami
Senior Member
 
L'Avatar di Murakami
 
Iscritto dal: Nov 2004
Città: Padova
Messaggi: 13283
Quote:
Originariamente inviato da shodan
Test fantastici Murakami, quanti ricordi hai risvegliato...

Due note:
-) quando non sei riuscito a toglire il v-sync eri in regime di double buffer o triple buffer? Te lo chiedo perchè nel primo caso non c'è solo il problema che gli fps massimi non possono superare la frequenza di refresh del monitor, ma anche che non possono essere diversi da un sottomultiplo della frequenza stessa (sicuramente sei a conoscenza del problema, ma non ho trovato specificato nulla al riguardo... )
-) eseguiresti un test del fill-rate del 3dmark 2000 sulle GeForce2 a 1024x768x16 e 1024x768x32? Mi interesserebbero i risultati del test multitexture: in questo test infatti la banda passante NON rappresenta un limite, in genere neanche a 32 bit. Se le prestazioni dovessero decadere sarebbe confermata l'incapacità di NV15 di usare 2 delle sue 4 pipeline quando operante a 32 bit...

Ciao complimenti ancora!
Grazie dei complimenti...
Rispondo alle tue domande:
1) Non ho modo di appurarlo (driver troppo primitivi o malfunzionanti -vedi Volari-) ma ritengo di essere stato senz'altro in regime di doppio buffer (spesso gli fps erano inchiodati su un 60 troppo spaccato con un refresh di 120 hz), quindi sono conscio che quei test non hanno quasi alcuna validità...ma, come già detto, non ho trovato modo di fare altrimenti...
2) Volentieri, dammi un link al programma perchè di bench me ne intendo come di merletti...
Aggiungo anche che oggi ho incontrato Sanford (persona squisita) e mi ha prestato il suo Voodoo 5, quindi presto la metterò alla frusta...
Aggiungo, inoltre, che per scrivere questo post sono al mio posto di lavoro pur essendo in ferie...
Aggiungo, infine, che sto testando gli occhialini 3D stereo e che presto aprirò thread dedicato...
Murakami è offline   Rispondi citando il messaggio o parte di esso
Old 17-08-2005, 15:21   #76
Murakami
Senior Member
 
L'Avatar di Murakami
 
Iscritto dal: Nov 2004
Città: Padova
Messaggi: 13283
Quote:
Originariamente inviato da shodan
questa feature è disponibile solo su NV30/NV40, vero? Non mi pare che i chip NV20/NV25 la supportassero (e infatti il loro vantaggio in giochi come Doom3 è ridotto...)
I chip nv20 e nv25 non supportano ultrashadow nè posseggono l'abilità di renderizzare 2 valori z per pipe: l'ultrashadow comparso su nv30 è stato raffinato su nv40 (ultrashadow II).
Murakami è offline   Rispondi citando il messaggio o parte di esso
Old 17-08-2005, 15:24   #77
Murakami
Senior Member
 
L'Avatar di Murakami
 
Iscritto dal: Nov 2004
Città: Padova
Messaggi: 13283
Quote:
Originariamente inviato da shodan
...rimane però la capacità di applicare i filtri (in particolare l'AA) in maniera più veloce rispetto a un approccio classico...
Il supersampling del Kyro impatta meno di quello del GeForce 2 -risparmio di banda dovuto all'architettura-, ma i filtri trilinear e anisotropic comportano un drastico calo di prestazioni, non so se per l'architettura tile based o le sole 2 pipeline con 1 unità di texturing per pipe.
Murakami è offline   Rispondi citando il messaggio o parte di esso
Old 17-08-2005, 15:53   #78
Murakami
Senior Member
 
L'Avatar di Murakami
 
Iscritto dal: Nov 2004
Città: Padova
Messaggi: 13283
Quote:
Originariamente inviato da conan_75
Eccomi, mi aggiungo ufficialmente alla discussione mettendo alcuni dati sulla V5 5500.
Al momento sto scaricando la demo di UT2003 con cui farò dei bench su D3D.
Per l'OGL userò Quake3.
Datemi giusto il tempo di trovare un monitor perchè quello del babbo da 14" che avrei dovuto usare per i test è saltato
Riesci a fare gli stessi test che ho fatto io, "Forsaken" e "Quake 2"?
Murakami è offline   Rispondi citando il messaggio o parte di esso
Old 17-08-2005, 15:54   #79
Vifani
Senior Member
 
Iscritto dal: Apr 2001
Città: Bari
Messaggi: 2774
Quote:
Originariamente inviato da Murakami
Il supersampling del Kyro impatta meno di quello del GeForce 2 -risparmio di banda dovuto all'architettura-, ma i filtri trilinear e anisotropic comportano un drastico calo di prestazioni, non so se per l'architettura tile based o le sole 2 pipeline con 1 unità di texturing per pipe.
Quello non è uno svantaggio dell'architettura Kyro, ma un vantaggio di quella GeForce 2 che possiede due TMU per pipeline e quindi è in grado di applicare il filtro trilineare in una sola passata di rendering. Oggi architetture come quella del GeForce 2 non esistono più, sono tutte con una sola TMU per pipeline e per effettuare il filtro trilineare comunque in una sola passata si usano trucchetti come il filtro brilineare, ecc...
__________________
Raffaele Fanizzi
My Personal Web Site
Membro Jedi del HWU Star Wars Clan
Vifani è offline   Rispondi citando il messaggio o parte di esso
Old 17-08-2005, 16:11   #80
Murakami
Senior Member
 
L'Avatar di Murakami
 
Iscritto dal: Nov 2004
Città: Padova
Messaggi: 13283
Quote:
Originariamente inviato da Vifani
Quello non è uno svantaggio dell'architettura Kyro, ma un vantaggio di quella GeForce 2 che possiede due TMU per pipeline e quindi è in grado di applicare il filtro trilineare in una sola passata di rendering. Oggi architetture come quella del GeForce 2 non esistono più, sono tutte con una sola TMU per pipeline e per effettuare il filtro trilineare comunque in una sola passata si usano trucchetti come il filtro brilineare, ecc...
Certo, ma non mi risulta che il GeForce 1 (4x1) calasse così tanto con i filtri applicati: ecco una spiegazione del brusco calo di prestazioni del Kyro.

Ultima modifica di Murakami : 17-08-2005 alle 16:23.
Murakami è offline   Rispondi citando il messaggio o parte di esso
 Rispondi


ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ultrawide si fondono ASUS ROG Swift OLED PG49WCD: quando QD-OLED e ul...
Dreame L10s Pro Ultra Heat: la pulizia di casa tutta sostanza Dreame L10s Pro Ultra Heat: la pulizia di casa t...
HONOR Magic6 Pro: come funziona Magic Portal, il modo ''intelligente'' di condividere HONOR Magic6 Pro: come funziona Magic Portal, il...
L'innovazione richiede fiducia: Workday si propone come guida nell'era dell'IA L'innovazione richiede fiducia: Workday si propo...
Recensione HONOR Pad 9: ampio display e audio top per il tablet per l'intrattenimento Recensione HONOR Pad 9: ampio display e audio to...
Xbox Series X si veste di bianco, ma &eg...
La Porsche Boxster elettrica beccata in ...
L'iPad da 10,9" (Wi-Fi, 64GB) è sceso a ...
Dell, calo del mercato PC: licenziati 13...
Alfa Romeo Milano, scopriamo profilo e l...
Hisense vende un TV FHD 32 pollici con Q...
Cisco Webex anche in auto: ora è ...
Phil Schiller, il boss dell'App Store di...
Lola in Formula E insieme a Yamaha, due ...
Motorola MA1 è l'accessorio ideale per u...
Tineco e aspirapolveri senza fili, la nu...
Blocco note, c'è un modo per ripr...
Relic Entertainment dice addio a SEGA: l...
SPATIUM M580 FROZR, il nuovo SSD PCIe Ge...
Le schede video NVIDIA GeForce RTX con i...
Chromium
GPU-Z
OCCT
LibreOffice Portable
Opera One Portable
Opera One 106
CCleaner Portable
CCleaner Standard
Cpu-Z
Driver NVIDIA GeForce 546.65 WHQL
SmartFTP
Trillian
Google Chrome Portable
Google Chrome 120
VirtualBox
Tutti gli articoli Tutte le news Tutti i download

Strumenti

Regole
Non Puoi aprire nuove discussioni
Non Puoi rispondere ai messaggi
Non Puoi allegare file
Non Puoi modificare i tuoi messaggi

Il codice vB è On
Le Faccine sono On
Il codice [IMG] è On
Il codice HTML è Off
Vai al Forum


Tutti gli orari sono GMT +1. Ora sono le: 12:50.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Served by www2v