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:

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

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.

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

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

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:

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

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

: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

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 :(

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:

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

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)

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! :)