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)


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: 10:32.

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