[HWVintage] Retrogaming avanti tutta

[Murakami]

Originariamente inviato da sanford

Mmm, Descent 3 è la versione specifica per Voodoo 3 e mi sa che per partire gli serve proprio quella, sei avvisato.

Ho il Voodoo3 ma mi serve quella completa per fare delle comparazioni sull'efficienza delle diverse API: al solito, tutti hanno quella che veniva data in bundle e nessuna quella full retail...

[shodan]

Originariamente inviato da yossarian

non mi ricordo in quale contesto era stata posta. Però di sicuro, nessuna vga si avvicina al valore teorico in single multitexturing, in quanto quel valore presuppone l'applicazione di un texel per pixel (o due texel per pixel nel caso di vga con 2 tmu) per ciclo di clock (è utopistico anche solo pensarlo).
Nel caso specifico di NV15, se non ricordo male, passando da 16 a 32 bit c'era addirittura un calo così vistodo, da essere giustificato solo con il fatto che due pipeline facessero effettivamente multitexturing (sempre se non ricordo male); la stessa cosa non si verifica con NV2x o R200

Si parlava del fatto che fino a NV30 / R300 in una pipeline non potevano esserci dati di più pixel, ma di solo uno.
Sinceramente la cosa mi ha lasciato sorpreso, in quanto credevo che mentre uno stadio della pipeline compiva una determinata operazione sul pixel A, gli stadi precedenti stessero già elaborando i pixel B, C e compagnia varia. Per semplificare quello che intendo, credevo che, mentre le pipeline scrivevano nel framebuffer i dati del pixel corrente, le TMU, operando in uno stadio precedente e non interessate nell'operazione di scrittura del fb, potessero iniziare a fare textel fetch per il secondo pixel.

Ma da quello che ho capito, fino a NV30 / R300 questa cosa non viene fatta. Giusto?


Riguardo a NV15, in che senso a 32 bit le pipeline (si suppone) facciano multitexture?

Ciao.

[yossarian]

Originariamente inviato da shodan

Si parlava del fatto che fino a NV30 / R300 in una pipeline non potevano esserci dati di più pixel, ma di solo uno.
Sinceramente la cosa mi ha lasciato sorpreso, in quanto credevo che mentre uno stadio della pipeline compiva una determinata operazione sul pixel A, gli stadi precedenti stessero già elaborando i pixel B, C e compagnia varia. Per semplificare quello che intendo, credevo che, mentre le pipeline scrivevano nel framebuffer i dati del pixel corrente, le TMU, operando in uno stadio precedente e non interessate nell'operazione di scrittura del fb, potessero iniziare a fare textel fetch per il secondo pixel.

Ma da quello che ho capito, fino a NV30 / R300 questa cosa non viene fatta. Giusto?


Riguardo a NV15, in che senso a 32 bit le pipeline (si suppone) facciano multitexture?

Ciao.

i dati di più pixel potevano (anzi dovevano) esserci; non potevano essere elaborati più pixel nello stesso ciclo

[shodan]

Originariamente inviato da yossarian

i dati di più pixel potevano (anzi dovevano) esserci; non potevano essere elaborati più pixel nello stesso ciclo

Mmm... aspetta, fammi vedere se ho capito: una singola unità può operare solo su un determinato pixel (ad esempio, entrambe le TMU possono fare textel fetch per un solo pixel), mentre le altre unità stavo elaborando altri pixel negli altri stadi. Corretto? E ti prego non dirmi di no, altrimenti distruggi tutto quello che ho imparato sugli accelleratori grafici...

Ti ripropongo anche la domanda fatta sopra: in che senso in NV15 2 pipeline potevano solo fare multi-texture? Che in condizione di single-texture rimanevano in effetti completamente inattive?

Grazie mille per la tua pazienza!

[sanford]

Originariamente inviato da Murakami

Ho il Voodoo3 ma mi serve quella completa per fare delle comparazioni sull'efficienza delle diverse API: al solito, tutti hanno quella che veniva data in bundle e nessuna quella full retail...

Abbi fiducia, sto rimediando...

[ATi7500]

entrato in possesso di due pezzi da museo

S3 Trio64v+ PCI...


e [sconosciuta] EDIT è una SiS 6326


aggiungo altre foto dell'accrocchio:

nell'ultima foto si possono scorgere un altro P200 e un K6-3 400


bYeZ!

[Bescio]

Originariamente inviato da Murakami

Mi piacerebbe molto trovare "Expendable": ce l'hai?
Quanto alle domande per Yoss e al riassunto per Shodan, farò del mio meglio...

C'è

Chiedi e ti sarà dato

[sanford]

Originariamente inviato da sanford

Abbi fiducia, sto rimediando...

Rimediato...

[Murakami]

Bescio, Sanford: datemi ciò che mi spetta!

[sanford]

Non prendere impegni per sabato prossimo...

[Murakami]

Originariamente inviato da sanford

Non prendere impegni per sabato prossimo...

Ok...

[Simon82]

Ciao ragazzi.. sto' sistemando il pc per rifare i test perche' purtroppo vuoi per i titoli scelti, vuoi per i drivers i risultati sono venuti falsati..
Bisogna decidere una serie di demo/titoli da testare...

[Murakami]

Originariamente inviato da Simon82

Ciao ragazzi.. sto' sistemando il pc per rifare i test perche' purtroppo vuoi per i titoli scelti, vuoi per i drivers i risultati sono venuti falsati..
Bisogna decidere una serie di demo/titoli da testare...

Trovi anche questo nel corso del thread...
Domani vedo di fare un pò di ordine...

[Simon82]

Originariamente inviato da Murakami

Trovi anche questo nel corso del thread...
Domani vedo di fare un pò di ordine...

SI ne ho visti nelle diverse pagine.. solo dovremmo decidere UNO STANDARD!

Che' so' per l'opengl GLQuake e Quake2, per il Direct3D quel che volete..

E cosi' per tutti quelli che vogliono testare, magari con titoli che hanno bench incorporati e di cui si trova facilmente la demo.

[yossarian]

Originariamente inviato da shodan

Mmm... aspetta, fammi vedere se ho capito: una singola unità può operare solo su un determinato pixel (ad esempio, entrambe le TMU possono fare textel fetch per un solo pixel), mentre le altre unità stavo elaborando altri pixel negli altri stadi. Corretto? E ti prego non dirmi di no, altrimenti distruggi tutto quello che ho imparato sugli accelleratori grafici...

Ti ripropongo anche la domanda fatta sopra: in che senso in NV15 2 pipeline potevano solo fare multi-texture? Che in condizione di single-texture rimanevano in effetti completamente inattive?

Grazie mille per la tua pazienza!

ci sono una serie di registri in cui si immagazzinano i dati e altri che soo usati per i risultati temporanei delle elaborazioni. Una alu inizia a fare calcoli relativi ad un pixel; quando capita unì'operazione che richiede tempi lunghi, perchè il dato non è presente all'interno dei registri, ma deve essere recuperato altrove (vram, texture cache, ecc), quel pixel viene temporanemante messo in standby e la alu inixìzia ad operare sul successivo gruppo di dati. Questo finchè non si raggiunge il limite dei registri o dei buffer che possono essere utilizzati per tenere in standby dei thread. Quando non è più possibile switchare tra un thead e l'altro, la pipeline resta in idle, fino a che non si recuperano i dati relativi alla prima operazioni tra quelle messe in "parcheggio". (detta proprio in maniera rozza )

Per la seconda domenda la risposta è: nel senso che se si guarda il valore del multitexturing si scopre che è poco al di sotto di quello ottenibile con un'architettura 2x2, mentre in single texture funziona chiaramente come una 4x1

[shodan]

Originariamente inviato da yossarian

ci sono una serie di registri in cui si immagazzinano i dati e altri che soo usati per i risultati temporanei delle elaborazioni. Una alu inizia a fare calcoli relativi ad un pixel; quando capita unì'operazione che richiede tempi lunghi, perchè il dato non è presente all'interno dei registri, ma deve essere recuperato altrove (vram, texture cache, ecc), quel pixel viene temporanemante messo in standby e la alu inixìzia ad operare sul successivo gruppo di dati. Questo finchè non si raggiunge il limite dei registri o dei buffer che possono essere utilizzati per tenere in standby dei thread. Quando non è più possibile switchare tra un thead e l'altro, la pipeline resta in idle, fino a che non si recuperano i dati relativi alla prima operazioni tra quelle messe in "parcheggio". (detta proprio in maniera rozza )

Ma questo vale per tutti i chip? Mi pare che mi precendemente avevi indicato che solo i chip di classe DX9 possano fare questo...
Per i chip più "tradizionali" (fino alle DX8) la pipeline funziona allo stesso modo?

Per la seconda domenda la risposta è: nel senso che se si guarda il valore del multitexturing si scopre che è poco al di sotto di quello ottenibile con un'architettura 2x2, mentre in single texture funziona chiaramente come una 4x1

Stiamo parlando sempre di una profondità a 32 bit per pixel giusto?
A titolo informativo, nel corso del thread abbiamo appurato come una GF2 MX utilizzi invece, anche a 32 bit per pixel, entrambe le pipeline. A questo punto inizio a pensare che un NV11 (GF2 MX) non fosse così limitato rispetto a un GF2 GTS (a parte per la bandwidth).

Ciao grazie.

[yossarian]

Originariamente inviato da shodan

Ma questo vale per tutti i chip? Mi pare che mi precendemente avevi indicato che solo i chip di classe DX9 possano fare questo...
Per i chip più "tradizionali" (fino alle DX8) la pipeline funziona allo stesso modo?

si; un conto è operrae su due (o più) thread nello stesso ciclo, un altro è fare switching tra un thread e l'altro in cicli successivi. La pipeline più "lunga" ti consente di fare la prima delle due operazioni; per l'altra servono un certo numero di registri costanti e temporanei (cosa che, in misura minore, hanno anche i chip precedenti alle dx9). Si tratta di due concetti completamente differenti

Originariamente inviato da shodan

Stiamo parlando sempre di una profondità a 32 bit per pixel giusto?
A titolo informativo, nel corso del thread abbiamo appurato come una GF2 MX utilizzi invece, anche a 32 bit per pixel, entrambe le pipeline. A questo punto inizio a pensare che un NV11 (GF2 MX) non fosse così limitato rispetto a un GF2 GTS (a parte per la bandwidth).

Ciao grazie.

sempre 32 bit per pixel (8 bit per canale(; se, le MX, a 32 bit, si comportano ancora come una 2x2 (li la limitazione diventa la bandwidth).

[MCA]

Ma guarda che bel thread e pensare che non l'avevo mai notato!?

Leggendo le prime pagine, mi sono tornate in mente la Matrox Mystique da 4Mb (espandibile a 8MB) PCI, la 3Dfx VooDoo Rush 6MB sempre PCI (la prima 3Dfx 2D/3D), la prima gpu: mitica geforce256 (una ASUS 6600 mi sembra con 32MB)... Tutte schede che ho avuto e che mi sono divertito a testare con i vari games dell'epoca... Mi ricordo Destruction Derby in versione accelerata per la Matrox Mystique...
Quanti ricordi...

[conan_75]

Originariamente inviato da MCA

Ma guarda che bel thread e pensare che non l'avevo mai notato!?

Leggendo le prime pagine, mi sono tornate in mente la Matrox Mystique da 4Mb (espandibile a 8MB) PCI, la 3Dfx VooDoo Rush 6MB sempre PCI (la prima 3Dfx 2D/3D), la prima gpu: mitica geforce256 (una ASUS 6600 mi sembra con 32MB)... Tutte schede che ho avuto e che mi sono divertito a testare con i vari games dell'epoca... Mi ricordo Destruction Derby in versione accelerata per la Matrox Mystique...
Quanti ricordi...

Benvenuto!!!

PS
Il tuo avatar mi scoppia gli occhi

[Murakami]

Originariamente inviato da MCA

Ma guarda che bel thread e pensare che non l'avevo mai notato!?

Leggendo le prime pagine, mi sono tornate in mente la Matrox Mystique da 4Mb (espandibile a 8MB) PCI, la 3Dfx VooDoo Rush 6MB sempre PCI (la prima 3Dfx 2D/3D), la prima gpu: mitica geforce256 (una ASUS 6600 mi sembra con 32MB)... Tutte schede che ho avuto e che mi sono divertito a testare con i vari games dell'epoca... Mi ricordo Destruction Derby in versione accelerata per la Matrox Mystique...
Quanti ricordi...

MCA, sei il benvenuto, ma se non cambi avatar chiedo ai mod di interdirti da questo thread: ci ho messo 5 minuti a capire che il mio strabismo non dipendeva dal fatto di essermi appena alzato...