4x2 = 8x1?

[mg13]

Originariamente inviato da yossarian
PC professionale ha anche detto che l'NV30 ha un'architettura 8x8, tanto per dirne una. SEcondo te qual è il senso di avere un'architettura interna a 256 bit e un memory bus a 512 bit effettivi (256 DDR equivale a 512 bit trasferiti per ciclo di clock)? Per avere un collo di bottiglia già in fase di progettazione, sulla carta?

Amesso che PC PRO abbia detto una castroneria, ma non menzioni il n. dove hai letto quello che dici, anche tu non ti sei tirato indietro dopo.

Mi sono girato i vari siti di: ATI, NVIDIA, MATROX E 3DLABS, e tutti confermano il bus verso la memoria locale ddr di 256bit.
NVIDIA conferma che il suo chip (nv3x) x le fx5900, fx5700 e fx5200 è di 256bit.
MATROX conferma che la Parhelia è 512bit.
Mentre gli altri due non specificano nulla.

Ora vorrei sapere le tue fonti di quello che hai scritto.
Altrimenti se vieni al workshop il 24 gennaio lo chiediamo direttamente a Paolo Corsini.

Ciao.

[yossarian]

Originariamente inviato da mg13
Amesso che PC PRO abbia detto una castroneria, ma non menzioni il n. dove hai letto quello che dici, anche tu non ti sei tirato indietro dopo.

Mi sono girato i vari siti di: ATI, NVIDIA, MATROX E 3DLABS, e tutti confermano il bus verso la memoria locale ddr di 256bit.
NVIDIA conferma che il suo chip (nv3x) x le fx5900, fx5700 e fx5200 è di 256bit.
MATROX conferma che la Parhelia è 512bit.
Mentre gli altri due non specificano nulla.

Ora vorrei sapere le tue fonti di quello che hai scritto.
Altrimenti se vieni al workshop il 24 gennaio lo chiediamo direttamente a Paolo Corsini.

Ciao.

NV35 è, in effetti, a 256 bit; infatti deriva da NV30 che ha l'interfaccia verso la memoria a 128 bit (non era possibile riprogettare tutto il chip per avere l'architettura interna a 512 bit; inoltre l'NV3x ha un'architettura delle pipeline piuttosto differente da quella degli altri, che gestisce il flusso di dati in maniera diversa).

R3x0 e P10 sono nate con interfaccia a 256 bit e architettura a 512 bit.

Il numero di PC Pro di cui parlo è quello di gennaio 2003 in cui fa un roundup delle vga in commercio e una preview della FX5800 (dicendo diverse castronerie, tra l'altro).

Per le fonti, per R300, accontentati di questo (che sicuramente è più attendibile di PC pro)

http://www.3dcenter.de/artikel/2002/07-14_english_a.php


poi ci sono sempre Topolino e il manuale delle giovani marmotte


A Corsini puoi chiederlo anche subito, perchè aspettare il 24 gennaio?

[pandyno]

Originariamente inviato da mg13
Ora vorrei sapere le tue fonti di quello che hai scritto.

Non ti conviene iniziare una diatriba del genere, dai retta

[yossarian]

Originariamente inviato da pandyno
Non ti conviene iniziare una diatriba del genere, dai retta

ciao pandy; non si tratta di iniziare una diatriba, anche perchè non avrebbe senso (e poi non ho né il tempo né la voglia per mettermi a discutere); mg13 ha ragione sul fatto che non si trovano informazioni chiare sui vari chip neppure sui siti dei produttori (Matrox, in questo, fa eccezione in positivo). Un esempio emblematico è stato quello dell'NV30 su cui nVIDIA non solo ha cercato di far trapelare il meno possibile, ma le informazioni che filtravano (a livello di voci di corridoio) erano, spesso, anche distorte e non veritiere.

[pandyno]

Si infatti anche per la questione FP24/32 di Rxx è un macello, non ci sono fonti chiare e trovi subito smentita da un' altra parte.

cmq, ti mando un PVT

[mg13]

Non fraintendetemi, non volevo iniziare una diatriba ma sapere solo dove trovare quello che yossarian diceva, visto che i produttori non danno molte informazioni e anch'io non ho trovato nulla in merito.
La battuta del Topolino e del Manuale delle giovani marmotte, potevi anche risparmiartela visto che mi sembrava di discutere civilmente e seriamente.

[yossarian]

Originariamente inviato da pandyno
Si infatti anche per la questione FP24/32 di Rxx è un macello, non ci sono fonti chiare e trovi subito smentita da un' altra parte.

cmq, ti mando un PVT

pvt letto.

Per la questione FP24/FP32 effettivamente c'è stata un po' di confusione, almeno a livello di notizie diffuse in giro (e bisogna ringraziare anche ATi per questo); le cose stanno in questi termini:
R3x0 lavora, a livello di unità di calcolo, a FP24 (qualunque sia la chiamata), salvo poi scalare a FP32 o a FP16 a livello di profondità di colore e utilizza, per le texture, indirizzi a 32 bit. Questo per le unità PS e relativamente ai calcoli in floating point (i VS lavorano in full fp32 ma questo vale già dalle DX8). Questo vale per tutta la gamma R3x0 (i chip sono praticamente identici a livelli di architettura interna: gli unici a differenziarsi, in minima parte, sono quelli con memory bus controller a 128 bit).

[yossarian]

Originariamente inviato da mg13
Non fraintendetemi, non volevo iniziare una diatriba ma sapere solo dove trovare quello che yossarian diceva, visto che i produttori non danno molte informazioni e anch'io non ho trovato nulla in merito.
La battuta del Topolino e del Manuale delle giovani marmotte, potevi anche risparmiartela visto che mi sembrava di discutere civilmente e seriamente.

ok, scusa

hai un pvt

[pandyno]

Originariamente inviato da yossarian
pvt letto.

Per la questione FP24/FP32 effettivamente c'è stata un po' di confusione, almeno a livello di notizie diffuse in giro (e bisogna ringraziare anche ATi per questo); le cose stanno in questi termini:
R3x0 lavora, a livello di unità di calcolo, a FP24 (qualunque sia la chiamata), salvo poi scalare a FP32 o a FP16 a livello di profondità di colore e utilizza, per le texture, indirizzi a 32 bit. Questo per le unità PS e relativamente ai calcoli in floating point (i VS lavorano in full fp32 ma questo vale già dalle DX8). Questo vale per tutta la gamma R3x0 (i chip sono praticamente identici a livelli di architettura interna: gli unici a differenziarsi, in minima parte, sono quelli con memory bus controller a 128 bit).

yes, l' ho letto fino allo sfinimento

Tra l' altro ricordo che in una discussione avvenuta su nVitalia, postai un link dal sito ATI nel quale dichiarava FULL FP32, qualche giorno dopo svanito nel nulla....

[yossarian]

Originariamente inviato da pandyno
yes, l' ho letto fino allo sfinimento

Tra l' altro ricordo che in una discussione avvenuta su nVitalia, postai un link dal sito ATI nel quale dichiarava FULL FP32, qualche giorno dopo svanito nel nulla....

parli di quello all'uscita della 9800?
Ti dirò, per come la vedo (e per quello che so dell'R3x0), anche l'f-buffer non è una novità della 9800 (è una tecnica nota agli addetti ai lavori da circa due anni ed è di facile implementazione, soprattutto su un chip strutturalmemente nato per sfruttarla).
Una modifica delle ALU (nel caso di full FP32) e un aumento del numero dei registri temporanei (di circa il 25% per il passaggio da FP24 a FP32) e di una quantità imprecisata e dipendente dall'utilizzo che si vuole fare della funzionalità di f-buffer on chip, richiede la riprogettazione di gran parte delle pipeline di rendering (cosa del tutto impensabile nel passaggio da R300 a R350); molto più verosimile l'attivazione di alcune funzionalità fino ad allora tenute inattive o un diverso utilizzo di parte dei registri temporanei già presenti nel chip, nonchè di parte del frame buffer (gli f-buffer possono essere anche esterni al chip e allocati nel frame buffer o, addirittura, nella ram di sistema).

[pandyno]

Si, si parlava per R350 di FULL FP32, chiaramente smentito

Resta ancora un piccolo margine per 350 pero', si parla dell' 1% di distacco rispetto R300, ottimizzazione interna?

[yossarian]

Originariamente inviato da pandyno
Si, si parlava per R350 di FULL FP32, chiaramente smentito

Resta ancora un piccolo margine per 350 pro', si parla dell' 1% di distacco rispetto R300, ottimizzazione interna?

sicuramente; si può ottimizzzare anche semplicemente, ad esempio, modificando leggermente la logica di funzionamento di qualche unità di calcolo o lavorando sul compilatore o sul flusso di dati, per ottenere qualche piccolo margine di guadagno.
Di contro, in alcune applicazioni, il vantaggio che si avrebbe con l'f-buffer (qualora fosse presente su un chip e non sull'altro) sarebbe enorme, sia in termini di prestazioni che di qualità d'immagine (ad es. permette di renderizzare correttamente le superfici semitrasparenti, cosa che non sempre avviene con i metodi tradizionali).

[pandyno]

Spero di non vedere un' altra 9800Super XT in commercio

D' altro canto cosi' l' HW attuale sarà sfruttato a dovere

[mg13]

Originariamente inviato da yossarian
ok, scusa

hai un pvt

Sì ce l'ho e scuse accettate.

Ho anche letto il link che avevi postato prima, ma sul nv30 non aveva notizie precise, poi ho visto che della Parhelia diceva che ne applica solo 4 di texture x passata, mentre tu se non erro dicevi 16 come l'ATI.

[yossarian]

Originariamente inviato da mg13
Sì ce l'ho e scuse accettate.

Ho anche letto il link che avevi postato prima, ma sul nv30 non aveva notizie precise, poi ho visto che della Parhelia diceva che ne applica solo 4 di texture x passata, mentre tu se non erro dicevi 16 come l'ATI.

su NV30 non aveva notizie precise perchè nVIDIA non ha mai divulgato notizie sull'architettura del chip né prima né dopo l'uscita dell'NV30 (tanto che, per molto tempo, si era nell'incertezza se si trattasse di una 4x2, come sembrava dai test sintetici, o una 8x1 come aveva inizialmente lasciato trapelare NV).
La Parhelia può applicare solo 4 texture per passata (infatti è PS1.3 compliant, da questo punto di vista, anche se, per altri aspetti, è più avanzata rispetto alle specifiche suddette; questo perchè Matrox continua, in maniera inspiegabile, a rinunciare all'utilizzo di registri interni per l'immagazzinamento dei risultati intermedi dell'elaborazione: in tal modo, avendo 4 TMU riesce ad applicare fino a 4 texture sia per ciclo di clock che per single pass, mentre, ad esempio, l'R300, avendo una sola TMU ma utilizzando registri temporanei per le texture, riesce ad arrivare fino a 16 texture per single pass, pur applicando una sola texture per ciclo di clock).
La Parhelia ha introdotto una serie di novità (architettura a 512 bit, memory bus a 256 bit, 10 bit per colore nel frame buffer, tanto per dirne alcune); ha la migliore uscita 2D in assoluto, a livello di filtri, è l'unico chip ad applicare una funzione di AA anche in 2D ed è l'unico chip di tipo consumer a gestire fino a 3 monitor. Purtroppo, sul piamno delle prestazioni pure è penalizzata da alcune scelte, in parte obbligate: basse frequenze di funzionamento, ,ancanza di un algoritmo di HSR e, in caso di utilizzo massiccio di multitexturing, mancanza di registri temporanei e necessità di accedere al frame buffer quando si applicano più di 4 texel per pixel. Non teme confronti, invece, in termini di numero di unità logiche (5 per pipeline, per un totale di 20 contro, ad esempio, le 12 dell'NV35 e le 24 disposte, però su 8 pipeline, dell'R3x0). Inoltre, in caso di input contenente molti calcoli matematici e poche texture, la Parhelia può far lavorare in serie le ALU di 2 pipeline contigue, divenendo, a tutti gli effetti, una 2x4 (2 pipeline di rendering, ognuna con 4 TMU), con ciascuna pipeline dotata, però, di 10 ALU.

[shodan]

Originariamente inviato da yossarian
su NV30 non aveva notizie precise perchè nVIDIA non ha mai divulgato notizie sull'architettura del chip né prima né dopo l'uscita dell'NV30 (tanto che, per molto tempo, si era nell'incertezza se si trattasse di una 4x2, come sembrava dai test sintetici, o una 8x1 come aveva inizialmente lasciato trapelare NV).
La Parhelia può applicare solo 4 texture per passata (infatti è PS1.3 compliant, da questo punto di vista, anche se, per altri aspetti, è più avanzata rispetto alle specifiche suddette; questo perchè Matrox continua, in maniera inspiegabile, a rinunciare all'utilizzo di registri interni per l'immagazzinamento dei risultati intermedi dell'elaborazione: in tal modo, avendo 4 TMU riesce ad applicare fino a 4 texture sia per ciclo di clock che per single pass, mentre, ad esempio, l'R300, avendo una sola TMU ma utilizzando registri temporanei per le texture, riesce ad arrivare fino a 16 texture per single pass, pur applicando una sola texture per ciclo di clock).
La Parhelia ha introdotto una serie di novità (architettura a 512 bit, memory bus a 256 bit, 10 bit per colore nel frame buffer, tanto per dirne alcune); ha la migliore uscita 2D in assoluto, a livello di filtri, è l'unico chip ad applicare una funzione di AA anche in 2D ed è l'unico chip di tipo consumer a gestire fino a 3 monitor. Purtroppo, sul piamno delle prestazioni pure è penalizzata da alcune scelte, in parte obbligate: basse frequenze di funzionamento, ,ancanza di un algoritmo di HSR e, in caso di utilizzo massiccio di multitexturing, mancanza di registri temporanei e necessità di accedere al frame buffer quando si applicano più di 4 texel per pixel. Non teme confronti, invece, in termini di numero di unità logiche (5 per pipeline, per un totale di 20 contro, ad esempio, le 12 dell'NV35 e le 24 disposte, però su 8 pipeline, dell'R3x0). Inoltre, in caso di input contenente molti calcoli matematici e poche texture, la Parhelia può far lavorare in serie le ALU di 2 pipeline contigue, divenendo, a tutti gli effetti, una 2x4 (2 pipeline di rendering, ognuna con 4 TMU), con ciascuna pipeline dotata, però, di 10 ALU.

Mmm... moooolto interessante!
Due domande yossarian:

1) Le Parhelia può utilizzare le sue complessive 16 TMU per applicare su un singolo pixel 16 texture per passata? Un po' come le GeForce256 che avevano un'architettura 4x1 ma all'occorrenza potevano anche far lavorare tutte le 4 pipe su un unico pixel, permettendo cos' di raggiungere il quad texturing in singola passata (naturalmene per singolo pixel).

2) Nel caso in cui la parhelia dovesse trovarsi in "assetto" di 2x4, molto potenza di calcolo delle TMU non andrebbe persa (a meno che non ci siano 4 texture per pixel, ma mi pare di aver capito che la parhelia "sceglie" questa modalità in caso di poche texture e molti calcoli). Inoltre quando parli di unità logiche parli degli stage delle unità pixel shader (mi pare proprio siano 5 per pipe).

Un'ultima cosa: mica tu o pandyno mi potete linkare le discussioni a cui facevate riferimento?

Ciao grazie!

[yossarian]

Originariamente inviato da shodan
Mmm... moooolto interessante!
Due domande yossarian:

1) Le Parhelia può utilizzare le sue complessive 16 TMU per applicare su un singolo pixel 16 texture per passata? Un po' come le GeForce256 che avevano un'architettura 4x1 ma all'occorrenza potevano anche far lavorare tutte le 4 pipe su un unico pixel, permettendo cos' di raggiungere il quad texturing in singola passata (naturalmene per singolo pixel).

no, infatti, il principale motivo per cui la Parhelia viene considerata "solo" PS1.3 compliant è proprio la sua incapacità di applicare più di 4 texture per single pass; questo pur essendo, per molti altri aspetti, molto più avanzata delle DX8.1. Ad esempio ha 256 registri di tipo INT (non temporanei), esattamente quanti ne hanno NV30 e R300 (si tratta del numero minimo previsto per i PS2.0) e le pipeline lavorano in FP24 (come quelle dell'R300).

Originariamente inviato da shodan

2) Nel caso in cui la parhelia dovesse trovarsi in "assetto" di 2x4, molto potenza di calcolo delle TMU non andrebbe persa (a meno che non ci siano 4 texture per pixel, ma mi pare di aver capito che la parhelia "sceglie" questa modalità in caso di poche texture e molti calcoli). Inoltre quando parli di unità logiche parli degli stage delle unità pixel shader (mi pare proprio siano 5 per pipe).


Ciao grazie!

si, in assetto 2x4 andrebbero "perse" 8 TMU complessive, ma questo viene fatto quando si è in presenza di molti calcoli algebrici e poche texture. Questo perchè ogni due pipeline sono pilotate da una sorta di controller dei dati in input che gestisce la configurazione delle pipeline.
Si, si tratta delle unità PS

Originariamente inviato da shodan

Un'ultima cosa: mica tu o pandyno mi potete linkare le discussioni a cui facevate riferimento?

Ciao grazie!

lo farei volentiri se mi riuscissi a ripescarle (su nV Italia di discussioni su NV30 e R300 di questo tenore se ne sono fatte a iosa e non mi ricordo neppure qual è la discussione a cui fa riferimento pandyno, anche se mi ricordo bene che era venuta fuori la storia del full FP32 per l'R3x0)

ciao

[pandyno]

Originariamente inviato da shodan

Un'ultima cosa: mica tu o pandyno mi potete linkare le discussioni a cui facevate riferimento?

A boh, fai un search, in pratica su nvitalia non si parlava di altro

[yossarian]

credo che il link sia questo

http://www.nvitalia.com/forum/showth...threadid=22939

comunque, se sei interessato, ti consiglio di dare un'occhiata anche ad altre discussioni sul forum di nV Italia (ordinale per numero di risposte nell'ultimo anno e prendi buona parte di quelle delle prime due pagine in cui si fa cenno alle architetture di NV3x e R3x0).

ciao

[pandyno]

mmhh si il link ufficiale era questo

http://www.ati.com/technology/wp/directx9.html


e quanto si diceva era questo:

DirectX 9.0 is available as an update to Windows operating systems. To fully experience the benefits it provides, you will need one of the latest generation of high performance graphics accelerators that supports all the major new features, including 2.0 Vertex Shaders, 2.0 Pixel Shaders, and 128-bit floating point data formats. The first available products to support these features are the RADEON 9700 series and RADEON 9500 series VPUs from ATI. The demos described in this paper provide examples of how they can be used to achieve amazing new visual effects.

Chiaramente non si fa più menzione di quanto scritto sopra nel sito ATI, o per lo meno non ho trovato nulla di recente.

Ammetto pero' di non ricordare nello specifico di cosa si stava parlando e al momento non ho tempo per ''ripassare''

c' è sempre Yoass se volete