Hardware Upgrade Forum

Hardware Upgrade Forum (https://www.hwupgrade.it/forum/index.php)
-   Schede Video - Discussioni generali (https://www.hwupgrade.it/forum/forumdisplay.php?f=28)
-   -   [HWVintage] Retrogaming avanti tutta (https://www.hwupgrade.it/forum/showthread.php?t=991407)


Murakami 20-05-2008 10:09

Quote:

Originariamente inviato da shodan (Messaggio 22528271)
Ciao,
in parecchi articoli vecchiotti, Xbitlabs ribadisce che NV10/15 possono applicare trilinear in un solo clock. A me sinceramente questa affermazione sembra strana; non mi risulta che le TMU del GF3/4 potessero applicare il filtro trilineare in un solo clock.

Devo comunque leggermi bene la recensione... vediamo di capire! :stordita:

Guarda, la conclusione è sempre la stessa: tanti articoli sono pieni di baggianate (nemmeno le TMU attuali applicano il filtro trilineare al volo).
A mio modo di vedere, la Parhelia può usare le 4 texture unit in condizione di 2 texture per passata, trilinear e aniso, oltre naturalmente che in regime di multitexturing più spinto.

shodan 20-05-2008 10:22

Quote:

Radeon 8500LE:








Qualità del filtro trilineare:


Nota: la scheda è stata fatta funzionare in modalità PCI in quanto l'abilitazione di qualsiasi modalità AGP impediva ad X di avviarsi. Per avere questo risultato, ho usato l'opzione “BUSType” “PCI” nel file “/etc/X11/xorg.conf”. Pare che il problema sia dovuto al chipset Via Apollo Pro 133A.

Anche la Radeon 8500LE si è dimostrata un po' altalenante: ho ripetuto i test anche in questo caso.
Diciamo che possono applicarsi le stesse considerazioni fatte per la Radeon VE; anche la cache sembra ugualmente ampia. Questo perchè anche in questo caso c'è un calo diffuso con texture più grandi di 64x64 pixel, quindi possiamo ipotizzare la stessa cache di 16 KB.
Efficienza del solid fill rispetto ai valori teorici: 97,6%.
Efficienza del bilineare con texture di 256x256 pixel: 84,14%.
Efficienza del bilineare con texture di 256x256 pixel + S3TC: 87,43%.



Arrivati alla fine, che dire... spero che questa analisi vi sia piaciuta! :p
Aspetto i vostri commenti... ;)

Ciao. :)

PS: in allegato trovate il codice del benchmark!
Quoto questo mio post perchè i test che ho condotto qualche mese fa indicano chiaramente che, a differenza di quanto affermato da Xbitlabs, le TMU di R200 non possono fare trilinear in un solo clock (altrimenti i risultati sarebbero stati molto simili a quelli del bilinear+mipmaps).

Restano da vedere NV10/15: secondo me è estremamente improbabile che possano fare trilinear in un solo clock... vediamo se trovo in rete qualcosa che può schiarirci le idee... :)

Ciao. :)

shodan 20-05-2008 10:29

Quote:

Originariamente inviato da Murakami (Messaggio 22528638)
Guarda, la conclusione è sempre la stessa: tanti articoli sono pieni di baggianate (nemmeno le TMU attuali applicano il filtro trilineare al volo).
A mio modo di vedere, la Parhelia può usare le 4 texture unit in condizione di 2 texture per passata, trilinear e aniso, oltre naturalmente che in regime di multitexturing più spinto.

Da quanto posso immaginare, Parhelia utilizzerà le sue 4 TMU se:
-) devono essere applicate 4 texture a un singolo pixel;
-) in regime di single texture + trilinear + AF2X ( su entrabe le texture);
-) in regime di dual texture + trilinear (su entrabe le texture);
-) in regime di dual texture + AF2X bilinear (se, come dice Xbitlabs, Parhelia usa sempre il trilinear in caso di AF, quest'ultima ipotesi potrebbe non essere realizzabile).

A memoria, le uniche TMU che possono applicare trilinear in un solo colpo di clock sono quelle di G80 (occhio: G92 non lo fa!), che hanno 1 TAU (texture address unit) e 2 TFU (texture filter unit). Lo svantaggio principale è che, dovendo dotare una TMU di 2 TFU, tanto vale aggiungere un'altra TAU e creare 2 TMU separate: in questo modo, in bilineare hai un textel rate doppio ;)
E, guardacaso, G92 usa questo secondo approccio... ;)

Ciao. :)

Murakami 20-05-2008 10:47

Quote:

Originariamente inviato da shodan (Messaggio 22528972)
Da quanto posso immaginare, Parhelia utilizzerà le sue 4 TMU se:
-) devono essere applicate 4 texture a un singolo pixel;
-) in regime di single texture + trilinear + AF2X ( su entrabe le texture);
-) in regime di dual texture + trilinear (su entrabe le texture);
-) in regime di dual texture + AF2X bilinear (se, come dice Xbitlabs, Parhelia usa sempre il trilinear in caso di AF, quest'ultima ipotesi potrebbe non essere realizzabile).

A memoria, le uniche TMU che possono applicare trilinear in un solo colpo di clock sono quelle di G80 (occhio: G92 non lo fa!), che hanno 1 TAU (texture address unit) e 2 TFU (texture filter unit). Lo svantaggio principale è che, dovendo dotare una TMU di 2 TFU, tanto vale aggiungere un'altra TAU e creare 2 TMU separate: in questo modo, in bilineare hai un textel rate doppio ;)
E, guardacaso, G92 usa questo secondo approccio... ;)

Ciao. :)

Come sei bravo, forte e potente: ti ammiro molto... :fagiano:
Per quanto concerne il grassettato, credo più a B3D... http://www.beyond3d.com/content/reviews/43/15

shodan 20-05-2008 11:08

Quote:

Originariamente inviato da Murakami (Messaggio 22529255)
Come sei bravo, forte e potente: ti ammiro molto... :fagiano:

Che fai, sfotti? :Prrr: :p
Quote:

Per quanto concerne il grassettato, credo più a B3D... http://www.beyond3d.com/content/reviews/43/15
Mmm... se non ricordo male, in quel caso è proprio Serious Sam a permettere di abilitare trilinear e AF dal gioco stesso. Magari Xbitlabs si riferisce alla forzatura dell'AF tramite passello di controllo che, potrebbe, forzare anche il trilinear.

Ciao. :)

Murakami 20-05-2008 11:30

Quote:

Originariamente inviato da shodan (Messaggio 22529576)
Mmm... se non ricordo male, in quel caso è proprio Serious Sam a permettere di abilitare trilinear e AF dal gioco stesso. Magari Xbitlabs si riferisce alla forzatura dell'AF tramite passello di controllo che, potrebbe, forzare anche il trilinear.

Ciao. :)

Si, ho capito, ma l'hanno presentata come fosse una limitazione hardware, quando è evidente che si tratta di una scelta di progettazione dei driver (che, secondo me, ha anche senso, a meno di non voler aggiungere un'altra voce -bilinear+aniso-, che non so a quanti potrebbe interessare).
Io non ti sfotto mai, tu sei il mio punto di riferimento costante... :O

shodan 20-05-2008 14:35

Quote:

Originariamente inviato da Murakami (Messaggio 22529946)
Si, ho capito, ma l'hanno presentata come fosse una limitazione hardware, quando è evidente che si tratta di una scelta di progettazione dei driver (che, secondo me, ha anche senso, a meno di non voler aggiungere un'altra voce -bilinear+aniso-, che non so a quanti potrebbe interessare).
Io non ti sfotto mai, tu sei il mio punto di riferimento costante... :O

Così mi commuoooovoooooo :cry: :nera: :D

shodan 20-05-2008 21:50

Dato che siamo in tema di qualità / prestazioni del filtro trilineare, posto un link interessante: http://alt.3dcenter.org/artikel/2003..._a_english.php

Ciao. :)

Murakami 21-05-2008 07:31

Quote:

Originariamente inviato da shodan (Messaggio 22541272)
Dato che siamo in tema di qualità / prestazioni del filtro trilineare, posto un link interessante: http://alt.3dcenter.org/artikel/2003..._a_english.php

Ciao. :)

Gli articoli di 3D Center sono sempre chiari ed esaustivi (quello sull'AA è fantastico): se fossero tutti tradotti in inglese, anzichè il 10%, credo che molte persone avrebbero le idee più chiare su molti aspetti della grafica 3D.

P3pPoS83 22-05-2008 14:10

Domanda da un milione di €:D

I chip VP10 e Parhelia alla loro uscita erano stati dichiarati da 3DLabs e Matrox come DX9 compliant... ma poco dopo entrambe le società fecero marcia indietro... perchè??? I chip sono realmente in grado di effettuare calcoli dx9 o no??? Hanno dei problemi interni o cosa x aver dovuto fare marcia indietro???

A voi esperti la parola....:O

Bye:cool:

Saragot 22-05-2008 16:26

Quote:

Originariamente inviato da P3pPoS83 (Messaggio 22565820)
Domanda da un milione di €:D

I chip VP10 e Parhelia alla loro uscita erano stati dichiarati da 3DLabs e Matrox come DX9 compliant... ma poco dopo entrambe le società fecero marcia indietro... perchè??? I chip sono realmente in grado di effettuare calcoli dx9 o no??? Hanno dei problemi interni o cosa x aver dovuto fare marcia indietro???

A voi esperti la parola....:O

Bye:cool:

Nojn sono un esperto, ma ti rispondo ugualmente;)
Il chip non è mai stato dichiarato dx 9 compatibile, ma è stato presentato come un chip dx 8.1 che integrava al suo interno delle caratteristiche mooolto interessanti che avrebbero ripreso le dx 9: inanzitutto un bus a 256 bit (una enormità per l'epoca), poi l'hardware displacement mapping, i quad-vertex shader arrays e 10 bit per canale sui colori.
Poi un'altra delle caratteristiche è il 16x fragment aa, caratteristica unica della parhelia. caratteristica molto interessante che permette di applicare l'aa solo ai lati dei poligoni.

p.s. nn dimentichiamoci del surround gaming;)

Murakami 22-05-2008 19:04

Quote:

Originariamente inviato da P3pPoS83 (Messaggio 22565820)
Domanda da un milione di €:D

I chip VP10 e Parhelia alla loro uscita erano stati dichiarati da 3DLabs e Matrox come DX9 compliant... ma poco dopo entrambe le società fecero marcia indietro... perchè??? I chip sono realmente in grado di effettuare calcoli dx9 o no??? Hanno dei problemi interni o cosa x aver dovuto fare marcia indietro???

A voi esperti la parola....:O

Bye:cool:

Il Parhelia è un chip ibrido, con i vertex shader compatibili DX9 (2.0) ma non altrettanto i pixel shader, fermi allo step 1.3. Dato che le DX9 non permettono un funzionamento ibrido, funziona come DX 8.1.
Per il VP10 lascio la parola a qualcun altro, non ricordo con esattezza: mi sembra fosse dotato di un array di processori VLIW capaci, in teoria, di essere programmati per supportare lo standard OpenGL 2.0 (e quindi, in teoria, anche le DX9), ma ho ricordi confusi.
Trattasi comunque di chip nati a cavallo tra 2 generazioni di API, quando ancora non si conoscevano le specifiche precise delle librerie.
EDIT: ecco tutto sul VP10, quando ho un attimo rileggo e cerco di sintetizzare.
http://www.beyond3d.com/content/reviews/29/1

P3pPoS83 22-05-2008 23:52

Quote:

Originariamente inviato da Murakami (Messaggio 22571037)
Il Parhelia è un chip ibrido, con i vertex shader compatibili DX9 (2.0) ma non altrettanto i pixel shader, fermi allo step 1.3. Dato che le DX9 non permettono un funzionamento ibrido, funziona come DX 8.1.
Per il VP10 lascio la parola a qualcun altro, non ricordo con esattezza: mi sembra fosse dotato di un array di processori VLIW capaci, in teoria, di essere programmati per supportare lo standard OpenGL 2.0 (e quindi, in teoria, anche le DX9), ma ho ricordi confusi.
Trattasi comunque di chip nati a cavallo tra 2 generazioni di API, quando ancora non si conoscevano le specifiche precise delle librerie.
EDIT: ecco tutto sul VP10, quando ho un attimo rileggo e cerco di sintetizzare.
http://www.beyond3d.com/content/reviews/29/1

Mi sto leggendo l'articolo... ma nel caso del parhelia... che senso ha avere i VS2.0 se poi non si possono sfruttare??? Oppure si O_o???

Bye:cool:

Murakami 23-05-2008 07:20

Quote:

Originariamente inviato da P3pPoS83 (Messaggio 22575321)
Mi sto leggendo l'articolo... ma nel caso del parhelia... che senso ha avere i VS2.0 se poi non si possono sfruttare??? Oppure si O_o???

Bye:cool:

Per come stanno le cose adesso, nessuno: per come sembrava stessero all'epoca della progettazione del chip, si pensava che le DX9 avrebbero consentito un funzionamento congiunto di parti DX9 compliant con parti DX8.
Dall'articolo di B3D sul P10: "One omission from this part of the pipeline is that the texture shader stage is currently an integer based process and DirectX9 and onwards will be moving to a floating point texture stage"; "The P10 hardware won't be able to support everything in OpenGL 2.0"; "P10 will not achieve DirectX9 compliance if floating point texture shading stages are a stipulation in DX9"... più o meno come la Parhelia, i pixel shader lavorano solo su interi.

P3pPoS83 23-05-2008 08:01

Ma teoricamente (via driver) non si potrebbe forzare il chip a lavorare con un apllicativo dx9 con gli interi??? Oppure è proprio impossibile???

Bye:cool:

Murakami 23-05-2008 08:18

Quote:

Originariamente inviato da P3pPoS83 (Messaggio 22576406)
Ma teoricamente (via driver) non si potrebbe forzare il chip a lavorare con un apllicativo dx9 con gli interi??? Oppure è proprio impossibile???

Bye:cool:

Evidentemente, non si può (o, quantomeno, i risultati di un simile shader replacement sarebbero ingiuriosi).

P3pPoS83 23-05-2008 08:48

Quote:

Originariamente inviato da Murakami (Messaggio 22576536)
Evidentemente, non si può (o, quantomeno, i risultati di un simile shader replacement sarebbero ingiuriosi).

Azz... ma da ignorante in materia... all'atto pratico qual'è la differenza tra interi e floating point sugli shaders???

Bye:cool:

Murakami 23-05-2008 08:53

Quote:

Originariamente inviato da P3pPoS83 (Messaggio 22576880)
Azz... ma da ignorante in materia... all'atto pratico qual'è la differenza tra interi e floating point sugli shaders???

Bye:cool:

La precisione del formato dei dati utilizzati (e di calcolo sugli stessi) e, di conseguenza, la fedeltà della rappresentazione visiva che si vuole ottenere.

P3pPoS83 23-05-2008 09:22

Quote:

Originariamente inviato da Murakami (Messaggio 22576955)
La precisione del formato dei dati utilizzati (e di calcolo sugli stessi) e, di conseguenza, la fedeltà della rappresentazione visiva che si vuole ottenere.

Quindi la differenza è solo nella qualità grafica:) grazie x le info... certo è un peccato che chip come il parhelia e VP10 siano rimasti inutilizzati al 70% ç_ç

Bye:cool:

Murakami 23-05-2008 09:27

Quote:

Originariamente inviato da P3pPoS83 (Messaggio 22577323)
Quindi la differenza è solo nella qualità grafica:) grazie x le info... certo è un peccato che chip come il parhelia e VP10 siano rimasti inutilizzati al 70% ç_ç

Bye:cool:

Macchè 70%: i pixel shader occupano la maggior parte dei transistor del chip, e quelli sono sfruttati al 100%, mentre i vertex shader 2.0 vengono usati in modalità compatibile DX 8.1... non è che rimanga tanto da sfruttare, se non il motore proprietario di displacement mapping (parlando della Parhelia).


Tutti gli orari sono GMT +1. Ora sono le: 00:28.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
Hardware Upgrade S.r.l.