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: |
Quote:
|
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. |
Quote:
E pensare che l'ho vista funzionare fino a 2 giorni prima che venisse tolta dal case... :cry: Ciao. :) |
Quote:
|
Quote:
Ciao. :) |
Quote:
|
Quote:
|
Quote:
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: |
Quote:
per me va bene e vedo che va bene anche per Davide ;) ieri sera tavo guardando una vecchia recensione del Savage2000 (la Viper II) |
Quote:
|
Quote:
:) 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. :)
|
Quote:
Questo mi ricordo della Xabre400 :( |
Quote:
anzi l' ho messa su un altro pc e funziona egregiamente :) |
Quote:
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: |
Quote:
|
Quote:
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. :) |
Quote:
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) |
Quote:
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! :) |
Quote:
Quote:
Quote:
Quote:
|
Quote:
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. :) |
Quote:
|
Quote:
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. |
Quote:
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 |
Quote:
|
Quote:
va bene: allora è una 2x1 che si riconfigura come una 1x2 (giusto perchè sei tu) :D |
Quote:
|
Quote:
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: |
Quote:
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.
|
Quote:
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. :) |
Quote:
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. :) |
Quote:
Quote:
|
Quote:
corretto |
Quote:
Che tu sappia anche NV20/25 e R200 soffrono di questa limitazione (immagino di si...)? Ciao. :) |
Quote:
|
Quote:
|
Quote:
|
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.