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)


Maury 02-11-2005 12:27

io ricordo che quando montai la TnT 2 Ultra al posto della TnT e provai un gioco di macchine incluso nel bundle, dissi.. ahhhahaha anche la risoluzione di 1600x1200 punti è sconfitta :D :p

che ricordi :cry:

ReDeX 02-11-2005 13:26

Quote:

Originariamente inviato da shodan
Già... FR era davvero bello, e ogni tanto lo faccio girare ancora oggi (se non altro per le musiche: bellissime! ;).

Però non era molto scalabile: anche con hardware odierno si ottengo risultati "solo" 15-20 volte maggiori del sistema di base (un P150 con VirgeVX :D).

Ciao. :)

Si, anche l'idea dell'agp test non era male, certo che oggi 36mb di texture sono ben poche per un test serio. :)

Romeo.d 02-11-2005 16:12

adesso c'è solo futuremark che produce benchmark decenti..
a me il 2001se mi andava brutalmente a scatti, ma sinceramente non ricordo il punteggio che facevo..
FR nel suo piccolo se la cavava bene, mi piaceva un sacco il suo modo di comparare i risultati, anche un utente ignorante come me capiva le differenze tra un driver o un altro.. bei tempi :)

Romeo D.

shodan 03-11-2005 10:01

Quote:

Originariamente inviato da shodan
Aaaargghhh! La scheda non mi entra nello slot AGP! :eek: :cry:

Ma cavolo, la Savage4 era un chip AGP4X no?
Possibile che sia stato montato su un PCB che supporta solo l'AGP2X (come all'epoca accadde con alcune TNT2)?!?

Devo trovare un'altro PC su cui effettuare i test...

Ciao. :)

Sempre più sfortunato... ho provato la scheda a lavoro ma mi da un mare di artefatti...

E pensare che l'ho vista funzionare fino a 2 giorni prima che venisse tolta dal case... :cry:

Ciao. :)

Murakami 03-11-2005 12:01

Quote:

Originariamente inviato da shodan
Sempre più sfortunato... ho provato la scheda a lavoro ma mi da un mare di artefatti...

E pensare che l'ho vista funzionare fino a 2 giorni prima che venisse tolta dal case... :cry:

Ciao. :)

Tra me e te, mi pare evidente che queste prove sul Savage 4 non s'hanno da fare! :O

shodan 03-11-2005 15:38

Quote:

Originariamente inviato da Murakami
Tra me e te, mi pare evidente che queste prove sul Savage 4 non s'hanno da fare! :O

Ma non mi arrendo: sto partecipando a un'asta per una Savage4 Xtreme e a un'altra per una Savage2000 con 64MB di SDRAM! ;)

Ciao. :)

yossarian 03-11-2005 16:00

Quote:

Originariamente inviato da shodan
Ma non mi arrendo: sto partecipando a un'asta per una Savage4 Xtreme e a un'altra per una Savage2000 con 64MB di SDRAM! ;)

Ciao. :)

ti stai Murakamizzando :D

shodan 03-11-2005 17:22

Quote:

Originariamente inviato da yossarian
ti stai Murakamizzando :D

Ehm... lo prendo come un complimento, ok?:D :sofico:

Murakami 03-11-2005 17:24

Quote:

Originariamente inviato da shodan
Ehm... lo prendo come un complimento, ok?:D :sofico:

Mi pare un grande complimento, altro che! :mad:
Savage 2000, eh? Interessantissimo: una delle poche schede che non ho avuto il piacere di avere...nemmeno di vedere! :cry:
Se te la aggiudichi, sono curiosissimo di vedere l'effetto di quell'embrione di motore T&L che so che gli ultimi driver beta permettono di attivare e disattivare... :fagiano:

yossarian 03-11-2005 18:22

Quote:

Originariamente inviato da shodan
Ehm... lo prendo come un complimento, ok?:D :sofico:


per me va bene e vedo che va bene anche per Davide ;)

ieri sera tavo guardando una vecchia recensione del Savage2000 (la Viper II)

Murakami 03-11-2005 18:24

Quote:

Originariamente inviato da yossarian
per me va bene e vedo che va bene anche per Davide ;)

:flower: :flower: :flower: :flower: :flower:

yossarian 03-11-2005 18:40

Quote:

Originariamente inviato da Murakami
:flower: :flower: :flower: :flower: :flower:


:)
sai che ti adoro quando fai l'archeologo del 3D. Anche perchè, secondo me, le vecchie vga hanno più fascino e nascondono più misteri delle nuove. Uno dei grandi misteri riguardava proprio il Savage2000 e il suo t&l che funzionava piuttosto bene in OGL e latitava completamente in D3D

Dark Schneider 03-11-2005 18:44

Ragà che ne pensante della Xabre? La Xabre 400, 600,ecc. Alla fine non erano male. Erano delle ibride DX7/DX8 se ben ricordo, però mi sa tanto che hanno avuto più successo queste vga per XGI che..la Volari. :)

conan_75 03-11-2005 19:01

Quote:

Originariamente inviato da Dark Schneider
Ragà che ne pensante della Xabre? La Xabre 400, 600,ecc. Alla fine non erano male. Erano delle ibride DX7/DX8 se ben ricordo, però mi sa tanto che hanno avuto più successo queste vga per XGI che..la Volari. :)

Nella Xabre 400 se attivavi il turbo mode nei registri andava meglio, ma la qualità visiva era pessima, texture slavate etc.
Questo mi ricordo della Xabre400 :(

pandyno 03-11-2005 19:53

Quote:

Originariamente inviato da yossarian
per me va bene e vedo che va bene anche per Davide ;)

ieri sera tavo guardando una vecchia recensione del Savage2000 (la Viper II)

ce l' ho nel cassetto :cool:

anzi l' ho messa su un altro pc e funziona egregiamente :)

Murakami 03-11-2005 20:09

Quote:

Originariamente inviato da pandyno
ce l' ho nel cassetto :cool:

anzi l' ho messa su un altro pc e funziona egregiamente :)

Allora procedi subito ai test del caso... :O
E ricorda che io sono l'archeologo del 3D: è Stefano che mi ha investito di questa carica, quindi è ufficiale! :O
Tornando a noi, ho avuto un Xabre 400 integrato in una mobo che ho comprato per il vecchio Duron: francamente, non ricordo marca e modello, forse perchè è durato un solo giorno nel mio PC... :fagiano:
La particolarità di quella mobo, basata su un chipset Ali (se non ricordo male) era si la scheda video integrata (assieme all'audio, la LAN etc.) ma con 64 mb di VRAM saldata sulla piastra, separata quindi dalla ram di sistema... :fagiano:
Il chip emulava in software i vertex shader, ma disponeva del supporto PS 1.3 in hardware: alcuni giochi andavano bene, altri non la riconoscevano come DX8 compatibile...avrei voluto testare più a lungo, ma continui blocchi di sistema me l'hanno impedito; mi disse poi il rivenditore (al quale l'ho restituita) che ero l'unico ad averla acquistata... :fagiano:

shodan 04-11-2005 00:01

Quote:

Originariamente inviato da Murakami
Allora procedi subito ai test del caso... :O
E ricorda che io sono l'archeologo del 3D: è Stefano che mi ha investito di questa carica, quindi è ufficiale! :O
Tornando a noi, ho avuto un Xabre 400 integrato in una mobo che ho comprato per il vecchio Duron: francamente, non ricordo marca e modello, forse perchè è durato un solo giorno nel mio PC... :fagiano:
La particolarità di quella mobo, basata su un chipset Ali (se non ricordo male) era si la scheda video integrata (assieme all'audio, la LAN etc.) ma con 64 mb di VRAM saldata sulla piastra, separata quindi dalla ram di sistema... :fagiano:
Il chip emulava in software i vertex shader, ma disponeva del supporto PS 1.3 in hardware: alcuni giochi andavano bene, altri non la riconoscevano come DX8 compatibile...avrei voluto testare più a lungo, ma continui blocchi di sistema me l'hanno impedito; mi disse poi il rivenditore (al quale l'ho restituita) che ero l'unico ad averla acquistata... :fagiano:

Te le vai proprio cercando però, eh? :D

shodan 04-11-2005 00:08

Quote:

Originariamente inviato da yossarian
:)
sai che ti adoro quando fai l'archeologo del 3D. Anche perchè, secondo me, le vecchie vga hanno più fascino e nascondono più misteri delle nuove. Uno dei grandi misteri riguardava proprio il Savage2000 e il suo t&l che funzionava piuttosto bene in OGL e latitava completamente in D3D

Concordo...
a proposito di Savage2000 e misteri, mi spieghi questa?
http://www.sharkyextreme.com/hardwar...review/6.shtml
Come possono le 2 TMU dell'immagine di destra (rappresentante il Savage2000) fare il loro lavoro in uno solo ciclo di clock? Ne occorrerebbe uno per ogni TMU, dato che le operazioni di multitexture sono sequenziali (prima applichi questa texture e poi quest'altra), giusto? Posso capire se si parla di una condizione di pipeline piena, da cui effettivamene a ogni ciclo di clock "esce" un pixel multitexturizzato (che bella parola! :D), ma in questo caso allora sarebbe errata l'immagine di sinistra (dato che li i cicli di clock delle 2 TMU sono distinti).

Solo marketing?

Ciao. :)

yossarian 04-11-2005 03:11

Quote:

Originariamente inviato da shodan
Concordo...
a proposito di Savage2000 e misteri, mi spieghi questa?
http://www.sharkyextreme.com/hardwar...review/6.shtml
Come possono le 2 TMU dell'immagine di destra (rappresentante il Savage2000) fare il loro lavoro in uno solo ciclo di clock? Ne occorrerebbe uno per ogni TMU, dato che le operazioni di multitexture sono sequenziali (prima applichi questa texture e poi quest'altra), giusto? Posso capire se si parla di una condizione di pipeline piena, da cui effettivamene a ogni ciclo di clock "esce" un pixel multitexturizzato (che bella parola! :D), ma in questo caso allora sarebbe errata l'immagine di sinistra (dato che li i cicli di clock delle 2 TMU sono distinti).

Solo marketing?

Ciao. :)

entrambe le tmu fanno texture fetch nello stesso ciclo, però l'operazione di texture combine avviene nel ciclo successivo (quando l'output della prima tmu diviene l'input della seconda); nello schema di sinistra, invece, si ha il primo texture fetch, quindi un texture store (in una piccola texture cache), un secondo texture fetch e un texture combine.
Sarebbe stato più corretto dire che il S2000 effettua tutto in una sola passata, mentre il Gefo (il riferimento è esplicito) ha bisogno di 2 passate (anche se elabora 4 pixel per volta contro 2 del Savage)

shodan 04-11-2005 09:27

Quote:

Originariamente inviato da yossarian
entrambe le tmu fanno texture fetch nello stesso ciclo, però l'operazione di texture combine avviene nel ciclo successivo (quando l'output della prima tmu diviene l'input della seconda); nello schema di sinistra, invece, si ha il primo texture fetch, quindi un texture store (in una piccola texture cache), un secondo texture fetch e un texture combine.
Sarebbe stato più corretto dire che il S2000 effettua tutto in una sola passata, mentre il Gefo (il riferimento è esplicito) ha bisogno di 2 passate (anche se elabora 4 pixel per volta contro 2 del Savage)

Si, però questo è valido perchè il GF256 aveva solo una texture unit per pipe. Nello schema invece mi pareva ci si riferisse ad altri chip con 2 TMU per pipe, tipo GF2. Però, ora che ci penso, il GF2 non era ancora uscito... quindi lo schema deve riferirsi proprio al GF256. ;)

Ti faccio un'altra domanda: in un'architettura tipo quella di NV10, le 2 TMU presenti nelle pipeline devono operare per forza sullo stesso pixel oppure no? Cioè, la TMU 2 può applicare una texture su un pixel mentre la TMU 1 può iniziare a processare il pixel seguente, giusto? I pixel possono trovarsi anche su triangoli differenti (e questo mi pare più difficile: se non ricordo male una delle limitazioni del motore TwinTextel delle TNT1/2 era proprio che non potevano fare multitexture se i pixel si trovavano su triangoli differenti)? Oltre a questo, pipeline diverse possono operare su pixel presenti su triangoli differenti (es: 2 pipeline lavorano su un triangolo e le altre 2 su un altro)?

Ciao grazie! :)

yossarian 04-11-2005 13:52

Quote:

Originariamente inviato da shodan
Si, però questo è valido perchè il GF256 aveva solo una texture unit per pipe. Nello schema invece mi pareva ci si riferisse ad altri chip con 2 TMU per pipe, tipo GF2. Però, ora che ci penso, il GF2 non era ancora uscito... quindi lo schema deve riferirsi proprio al GF256. ;)

l'immagine trae in inganno; ci si rifewrisce ad un chip con una sola tmu per pipeline, presa in due cicli successivi.

Quote:

Originariamente inviato da shodan
Ti faccio un'altra domanda: in un'architettura tipo quella di NV10, le 2 TMU presenti nelle pipeline devono operare per forza sullo stesso pixel oppure no?

si (comunque è NV15 :) ). Le pipeline di NV15 possono elaborare un solo pixel per volta, anche a livello di calcoli matematici. La 2 tmu servono solo per le operazioni di multitexturing o per l'applicazione di filtri (trilinear ad esempio). D'altro canto le specifiche delle dx7 prevedono l'utilizzo di almeno due registri per le texture.

Quote:

Originariamente inviato da shodan
Cioè, la TMU 2 può applicare una texture su un pixel mentre la TMU 1 può iniziare a processare il pixel seguente, giusto?

no

Quote:

Originariamente inviato da shodan
I pixel possono trovarsi anche su triangoli differenti (e questo mi pare più difficile: se non ricordo male una delle limitazioni del motore TwinTextel delle TNT1/2 era proprio che non potevano fare multitexture se i pixel si trovavano su triangoli differenti)? Oltre a questo, pipeline diverse possono operare su pixel presenti su triangoli differenti (es: 2 pipeline lavorano su un triangolo e le altre 2 su un altro)?

Ciao grazie! :)

il TnT è una 2x1 e, in multitexturing, è costretto a ricorrere a due cicli, potendo processare solo 2 pixel per volta. La possibilità di processare pixel su triangoli differenti, se non ricordo male, è stata introdotta con l'NV20

shodan 04-11-2005 16:18

Quote:

Originariamente inviato da yossarian
l'immagine trae in inganno; ci si rifewrisce ad un chip con una sola tmu per pipeline, presa in due cicli successivi.



si (comunque è NV15 :) ). Le pipeline di NV15 possono elaborare un solo pixel per volta, anche a livello di calcoli matematici. La 2 tmu servono solo per le operazioni di multitexturing o per l'applicazione di filtri (trilinear ad esempio). D'altro canto le specifiche delle dx7 prevedono l'utilizzo di almeno due registri per le texture.



no



il TnT è una 2x1 e, in multitexturing, è costretto a ricorrere a due cicli, potendo processare solo 2 pixel per volta. La possibilità di processare pixel su triangoli differenti, se non ricordo male, è stata introdotta con l'NV20


Grazie mille per le spiegazioni.
Un'ultima domanda: nel chip con 2 TMU per pipe c'è poi un'unità dedicata che si occupa del blending tra le due texture? Perchè altrimenti, se se ne occupasse per esempio la seconda TMU, tra textel fetch e blending sarebbero necessari 2 cicli di clock, facendo "stallare" la pipeline.

Ciao. :)

Murakami 04-11-2005 18:04

Quote:

Originariamente inviato da yossarian
il TnT è una 2x1 e, in multitexturing, è costretto a ricorrere a due cicli, potendo processare solo 2 pixel per volta. La possibilità di processare pixel su triangoli differenti, se non ricordo male, è stata introdotta con l'NV20

Eppure, ricordo di aver letto, sul defunto Reactor Critical, che le 2 pipe potevano essere riconfigurate per lavorare in 1x2... :cry:

yossarian 04-11-2005 19:24

Quote:

Originariamente inviato da shodan
Grazie mille per le spiegazioni.
Un'ultima domanda: nel chip con 2 TMU per pipe c'è poi un'unità dedicata che si occupa del blending tra le due texture? Perchè altrimenti, se se ne occupasse per esempio la seconda TMU, tra textel fetch e blending sarebbero necessari 2 cicli di clock, facendo "stallare" la pipeline.

Ciao. :)


all'interno di ogni tmu c'è un texture combiner; quindi, in un'architettura con una singola tmu si fa texture fetch relativamente alla texture 1 e questa passa all'interno del combiner inalterata; nel xecondo ciclo si fa texture fetch dal registro successivo e si combinano le due texture all'interno del combiner.

Con due tmu la prima fa texture fetch e la prima texture passa dentro il combiner a arriva a lla seconda che, nel frattempo, ha fatto texture fetch nel ciclo precedente e esegue texture combine nel successivo.

yossarian 04-11-2005 19:26

Quote:

Originariamente inviato da Murakami
Eppure, ricordo di aver letto, sul defunto Reactor Critical, che le 2 pipe potevano essere riconfigurate per lavorare in 1x2... :cry:


no; è una 2x1 e, in caso di multitexturing (sarebbe opportuno parlare di dual texturing), si avvale dell'utilizzo di due registri di sola lettura da cui prelevare i dati in due cicli successivi

Murakami 04-11-2005 19:33

Quote:

Originariamente inviato da yossarian
no; è una 2x1 e, in caso di multitexturing (sarebbe opportuno parlare di dual texturing), si avvale dell'utilizzo di due registri di sola lettura da cui prelevare i dati in due cicli successivi

Si, me l'hai già detto: ma io sono affezionato alla tesi del defunto Reactor Critical...mi manca tanto... :cry: :cry: :cry: :cry: :cry:

yossarian 04-11-2005 19:44

Quote:

Originariamente inviato da Murakami
Si, me l'hai già detto: ma io sono affezionato alla tesi del defunto Reactor Critical...mi manca tanto... :cry: :cry: :cry: :cry: :cry:


va bene: allora è una 2x1 che si riconfigura come una 1x2 (giusto perchè sei tu) :D

Murakami 04-11-2005 19:50

Quote:

Originariamente inviato da yossarian
va bene: allora è una 2x1 che si riconfigura come una 1x2 (giusto perchè sei tu) :D

Ecco, bravo, grazie: bisogna portare rispetto per i defunti, non infangare le loro tesi dopo la loro dipartita, quando non possono più difenderle e controbattere...poveri derelitti... :cry: :cry: :cry: :cry: :cry:

yossarian 04-11-2005 19:56

Quote:

Originariamente inviato da Murakami
Ecco, bravo, grazie: bisogna portare rispetto per i defunti, non infangare le loro tesi dopo la loro dipartita, quando non possono più difenderle e controbattere...poveri derelitti... :cry: :cry: :cry: :cry: :cry:


fatti una domanda e datti una risposta, direbbe Marzullo :D

Dark Schneider 04-11-2005 21:23

Cmq ragà riguardo la mitica GeForce 256..volevo dirvi che quel giorno l'ho cmq provata anche con The Cronicles of Riddick. Questo davvero totalmente ingiocabile.
Se HL2 va da dio e con un ottimo impatto grafico. Far Cry settando tutto al max(del possibile per una GF256) ed in 800x600 era tranquillamente giocabile. Doom 3 ho provato solo 640x480 e dettaglio basso: con ombre attivate ovviamente muore..con tutto attivo e solo le ombre disattivate abbastanza giocabile, anche se qlc volta con troppi nemici scendeva a 14-15 fps. Disattivando tutti gli effetti invece è totalmente giocabile. Sempre tra i 30-40 fps, con punte di 60...e picco minimo di 22 fps.

Senza alcun dubbio HL2 è quello che risulta più appagante.
Invece The Cronicles of Riddick è l'unico motore di nuova generazione che è proprio impossibile giocarci. Ho addirittura settato la risoluzione di 512x384, Shader 0.5 (che non so cosa intende..forse semplicemente per appunto le schede che non supportano i PS), tutto al minimo, tutti gli effetti disattivati. Risultato? Qualità del gioco uno schifo totale: persino il primo Wolfestein 3D è 10 pianeti sopra. Il tutto alla media di 7 fps con punte di 13 fps. Su un A64 2400 Mhz. :asd:

yossarian 04-11-2005 21:56

Quote:

Originariamente inviato da Dark Schneider
Cmq ragà riguardo la mitica GeForce 256..volevo dirvi che quel giorno l'ho cmq provata anche con The Cronicles of Riddick. Questo davvero totalmente ingiocabile.
Se HL2 va da dio e con un ottimo impatto grafico. Far Cry settando tutto al max(del possibile per una GF256) ed in 800x600 era tranquillamente giocabile. Doom 3 ho provato solo 640x480 e dettaglio basso: con ombre attivate ovviamente muore..con tutto attivo e solo le ombre disattivate abbastanza giocabile, anche se qlc volta con troppi nemici scendeva a 14-15 fps. Disattivando tutti gli effetti invece è totalmente giocabile. Sempre tra i 30-40 fps, con punte di 60...e picco minimo di 22 fps.

Senza alcun dubbio HL2 è quello che risulta più appagante.
Invece The Cronicles of Riddick è l'unico motore di nuova generazione che è proprio impossibile giocarci. Ho addirittura settato la risoluzione di 512x384, Shader 0.5 (che non so cosa intende..forse semplicemente per appunto le schede che non supportano i PS), tutto al minimo, tutti gli effetti disattivati. Risultato? Qualità del gioco uno schifo totale: persino il primo Wolfestein 3D è 10 pianeti sopra. Il tutto alla media di 7 fps con punte di 13 fps. Su un A64 2400 Mhz. :asd:

si, lo sm0,5 è quello delle dx7 (GF e GF2).
Quello che dici conferma che HL2 ha il motore grafico più ottimizzato e scalabile del lotto. Doom e Riddick sono ottimizzati per gli ultimi chip NV (e riddick è anche piuttosto bandwidth limited), che con i modelli fino a NV2x c'entrano poco o niente.

Murakami 04-11-2005 23:41

Ho comprato "Riddick" proprio oggi, alla incredibilmente modica cifra di 14.90 € (pazzesco, considerando che costava più di 50 € un mese fa); farò volentieri qualche prova con il GeForce 2 GTS.

shodan 05-11-2005 01:01

Quote:

Originariamente inviato da yossarian
all'interno di ogni tmu c'è un texture combiner; quindi, in un'architettura con una singola tmu si fa texture fetch relativamente alla texture 1 e questa passa all'interno del combiner inalterata; nel xecondo ciclo si fa texture fetch dal registro successivo e si combinano le due texture all'interno del combiner.

Con due tmu la prima fa texture fetch e la prima texture passa dentro il combiner a arriva a lla seconda che, nel frattempo, ha fatto texture fetch nel ciclo precedente e esegue texture combine nel successivo.

Mmm... quindi un'architettura 1x2 ha bisogno di 3 cicli di clock per elaborare un pixel in multi-texture.

1° ciclo: texture fetch delle 2 TMU;
2° ciclo: spostameno della prima texture fetch alla seconda TMU;
3° ciclo: blending fra le 2 texture, eseguito nel texture combiner della seconda TMU.

Oppure il primo texture fetch e il passaggio dei dati appena campionati al texture combiner della seconda TMU è fatto direttamente in un unico ciclo di clock, unificando così i passaggi 1 e 2?

Leggendo quanto da te riportato a proposito delle limitazioni relative al multitexture su 2 pixel distinti, mi viene un dubbio: i chip grafici con architettura a 2 TMU per pipe sono in genere accreditati di riuscire a sforanre un pixel con 2 texture ogni ciclo di clock. Finora pensavo che quest'affermazione fosse, relativamente al sunstained textel-rate, vera: infatti, anche se il primo pixel avrebbe impegato più cicli di clock per uscire, i pixel successivi, in base al principio di funzionamento delle pipeline, avrebbero impiegato solo 1 ciclo. Però, proprio leggendo delle limitazioni di cui sopra, mi chiedo se questa affermazione possa ancora ritenersi valida. Mi spiego: se la TMU 1 non può elaborare un altro pixel mentre la TMU 2 sta combinando i vari textel appena campionati, la pipeline va in stallo. Di conseguenza non otterrò _mai_ il raggiungimento di 1 pixel dual textured/clock.

E' corretto o mi sfugge qualcosa (probabile! :stordita: )?

Ciao. :)

shodan 05-11-2005 01:04

Quote:

Originariamente inviato da yossarian
no; è una 2x1 e, in caso di multitexturing (sarebbe opportuno parlare di dual texturing), si avvale dell'utilizzo di due registri di sola lettura da cui prelevare i dati in due cicli successivi

Quindi comunque, anche in caso di dual-texturing, non deve ricorrere al multi-pass dato che può fare affidamento sui registri interni per stoccare i passaggi intermedi, giusto?
Un funzionamento analogo lo aveva il Rage128: aveva una sola TMU ma, grazie al suo perfetto algoritmo di caching, poteva effettuare multi-texture in una sola passata.

Ciao. :)

yossarian 05-11-2005 01:21

Quote:

Originariamente inviato da shodan
Mmm... quindi un'architettura 1x2 ha bisogno di 3 cicli di clock per elaborare un pixel in multi-texture.

1° ciclo: texture fetch delle 2 TMU;
2° ciclo: spostameno della prima texture fetch alla seconda TMU;
3° ciclo: blending fra le 2 texture, eseguito nel texture combiner della seconda TMU.

Oppure il primo texture fetch e il passaggio dei dati appena campionati al texture combiner della seconda TMU è fatto direttamente in un unico ciclo di clock, unificando così i passaggi 1 e 2?

i passaggi 1 e 2 non sono unificati

Quote:

Originariamente inviato da shodan
Leggendo quanto da te riportato a proposito delle limitazioni relative al multitexture su 2 pixel distinti, mi viene un dubbio: i chip grafici con architettura a 2 TMU per pipe sono in genere accreditati di riuscire a sforanre un pixel con 2 texture ogni ciclo di clock. Finora pensavo che quest'affermazione fosse, relativamente al sunstained textel-rate, vera: infatti, anche se il primo pixel avrebbe impegato più cicli di clock per uscire, i pixel successivi, in base al principio di funzionamento delle pipeline, avrebbero impiegato solo 1 ciclo. Però, proprio leggendo delle limitazioni di cui sopra, mi chiedo se questa affermazione possa ancora ritenersi valida. Mi spiego: se la TMU 1 non può elaborare un altro pixel mentre la TMU 2 sta combinando i vari textel appena campionati, la pipeline va in stallo. Di conseguenza non otterrò _mai_ il raggiungimento di 1 pixel dual textured/clock.

E' corretto o mi sfugge qualcosa (probabile! :stordita: )?

Ciao. :)

dipende dal chip; NV3x, ad esempio, può lavorare su pixel diversi contemporaneamente. NV15 no.

yossarian 05-11-2005 01:21

Quote:

Originariamente inviato da shodan
Quindi comunque, anche in caso di dual-texturing, non deve ricorrere al multi-pass dato che può fare affidamento sui registri interni per stoccare i passaggi intermedi, giusto?
Un funzionamento analogo lo aveva il Rage128: aveva una sola TMU ma, grazie al suo perfetto algoritmo di caching, poteva effettuare multi-texture in una sola passata.

Ciao. :)


corretto

shodan 05-11-2005 12:49

Quote:

Originariamente inviato da yossarian
i passaggi 1 e 2 non sono unificati



dipende dal chip; NV3x, ad esempio, può lavorare su pixel diversi contemporaneamente. NV15 no.

Quindi i 1600 Mtextel/sec dell'NV15 a 200 Mhz non prebbero _mai_ essere raggiunti né avvicinati, nemmeno se si avesse una bandwidth infinita. La pipeline infatti stallerebbe stroppe volte per raggiungere o avvicinare gli ipotetici 1600 Mtextel.
Che tu sappia anche NV20/25 e R200 soffrono di questa limitazione (immagino di si...)?

Ciao. :)

Franx1508 05-11-2005 12:52

Quote:

Originariamente inviato da shodan
Quindi i 1600 Mtextel/sec dell'NV15 a 200 Mhz non prebbero _mai_ essere raggiunti né avvicinati, nemmeno se si avesse una bandwidth infinita. La pipeline infatti stallerebbe stroppe volte per raggiungere o avvicinare gli ipotetici 1600 Mtextel.
Che tu sappia anche NV20/25 e R200 soffrono di questa limitazione (immagino di si...)?

Ciao. :)

da quello che ho potuto vedere no.

Franx1508 05-11-2005 12:53

Quote:

Originariamente inviato da Murakami
Ho comprato "Riddick" proprio oggi, alla incredibilmente modica cifra di 14.90 € (pazzesco, considerando che costava più di 50 € un mese fa); farò volentieri qualche prova con il GeForce 2 GTS.

dove lo hai preso?

Murakami 05-11-2005 13:12

Quote:

Originariamente inviato da Franx1508
dove lo hai preso?

Si può dire qui?


Tutti gli orari sono GMT +1. Ora sono le: 07:27.

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