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

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

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

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.

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:

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:

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

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.

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.

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

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

i passaggi 1 e 2 non sono unificati

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

corretto

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.

dove lo hai preso?

Si può dire qui?