Lo diciamo da qualche settimana, nello specifico da quando la RX 7600 è stata presentata e ha mostrato le sue prestazioni. Abbiamo lanciato un articolo molto interessante che sicuramente ricorderete affermando che questa GPU soffriva di un chiaro Overhead, ed oggi non solo conferma quanto detto, ma approfondisce anche tutto ciò mostrando le performance interne. La linea di fondo è chiara, l’RX 7600 ha una GPU Navi 33 con Architettura RDNA 3 Litesimile a RDNA 2 rispetto alle sorelle della serie RX 7000.
RDNA 3 è stato un balzo in avanti per alcuni aspetti rispetto a RDNA 2. Molte delle modifiche sono state introdotte dal sistema MCM dell’architettura e dall’incremento prestazionale che si voleva dare a Ray Tracing e AI con le rispettive unità. Il più grande cambiamento nel modo in cui funziona l’architettura viene raramente commentato e aiuta molto con problemi come il consumo e il disaccoppiamento subito nell’architettura, come l’indipendenza delle frequenze di Frontend e Shader, ma cosa c’entra questo con il carta maras?
Navi 33 non è una GPU RDNA 3 “grande”.
Abbiamo già spostato i diagrammi a blocchi tra RDNA 2 e RDNA 3 insieme ad altri dati chiave, che riportiamo qui, principalmente perché è il fondamento dell’intera spiegazione. Ma per capirlo, torniamo a quell’articolo, dove abbiamo discusso la questione dell’overhead e del processore dei comandi.
RX6600 | RX6650XT | RX7600 | |
---|---|---|---|
Architettura | RDNA 2 | RDNA 2 | RDNA 3 |
Shader | 1792 | 2.048 | 2.048 |
Shader di frequenza | 2,491MHz | 2,635MHz | 2,625MHz |
TMU | 112 | 128 | 128 |
POR | 64 | 64 | 64 |
L0 | 32KB di WGP | 32 KB per WGP | 32 KB per WGP |
L1 | 128 KB per matrice | 128 KB per matrice | 128 KB per matrice |
L2 | 2MB | 2MB | 2MB |
L3 | 32MB | 32MB | 32MB |
Autobus | 128 bit | 128 bit | 128 bit |
Frequenza RAM | 1.750 MHz o 14 Gbps | 2.190 MHz o 17,5 Gbps | 2.250 MHz o 18 Gbps |
VRAM | 8GB | 8GB | 8GB |
PTB | 132 W | 176W | 165W |
Come abbiamo detto, quello che abbiamo è un problema di Draw Calls e il processore dei comandi è nel mezzo. Non l’abbiamo commentato in detto articolo, anche se lasciamo i dati, ma oggi possiamo affermare ciò che non abbiamo osato fare in quell’occasione perché non abbiamo potuto testare la GPU in situ.
Ma sì, i cambiamenti in Navi 33 per quanto riguarda il la registrazione del vettore tramite SIMD è un problema. All’epoca, senza dati di riferimento in mano, pensavamo che il L0 più alto per i vettori avrebbe compensato il fatto che AMD in Navi 33 aveva incluso File di registro da 128 KB per SIMDqualcosa di simile a quello che NVIDIA ha fatto con i bus rispetto alla cache più grande.
Ma no, quei 128 KB di VRF sono esattamente gli stessi di quelli introdotti in RDNA 2 e la cache non può alleviare il calo delle prestazioni. Perciò, AMD avrebbe incluso praticamente lo stesso Command Processor in Navi 33 come in Navi 23, il che è logico se le prestazioni non sono danneggiate dall’aumento di L0 in VRF e anche la cache dei dati L1 non può fare la differenza. Lo vedremo di seguito con i dati estratti da i compagni Patatine e Formaggio.
Prestazioni del front-end e del processore di comando
Quello che sospettavamo all’epoca è che il processore dei comandi, all’interno del fine frontale, aveva prestazioni inferiori su Navi 33 rispetto a Navi 31, e lo è. Il disaccoppiamento delle frequenze del Front end e degli Shader fa sì che in una RX 7900 XT, ad esempio, le differenze di MHz siano maggiori, ma sulla RX 7600 si comportano come in RDNA 2poiché i loro valori sono molto vicini.
I valori affermano che la maggiore delle sorelle può vedere una variazione di tra il 5% e il 10% sulle loro frequenze, ma sulla RX 7600 questo non accade.
Pertanto, Navi 33 impiega più tempo per completare il lavoro per comando e questo è inevitabilmente influenzato dal processore di comandi che è adattato in questa architettura RDNA 3 Liteda qui il problema di Disegna le chiamate.
Ma non siamo davvero all’altezza, perché il problema più grande viene da file di registro vettorialiche hanno un collo di bottiglia nell’architettura che, a differenza dell’esempio e della similitudine di NVIDIA, I WGP non possono compensare.
Prestazioni su vettori limitati dai loro registri
È il punto grosso da affrontare dopo la spiegazione del processore di comando, poiché qui abbiamo il secondo collo di bottiglia che impedisce di aumentare le prestazioni della GPU. Scendere dai 192 KB che ha il Navi 31 ai 128 KB di questo Navi 33, anche raddoppiando la cache L0 di vettori e texture per CU, è un calo troppo grande che influisce sulle prestazioni di ciascuna unità.
Il VRF ha perso il 33,3% di capacità, la L0 è aumentata del 100%, risultato? Le CU non funzionano bene, soprattutto quando si parla di dover spostare dati o estrarli da L2 e L3. Lo si può vedere perfettamente da 64 thread le prestazioni di RDNA 3 Lite calano notevolmentee lì inizia a ridimensionarsi gradualmente in tempi più brevi per Thread allocato.
C’è un fatto chiave che sicuramente trascurerai, ed è che se presti attenzione, RDNA 3 Lite lo fa 16 su 16 incarichi da 64RDNA 3 Grandi cali a 96 e assegnare da 24 a 24 per i log, indicando che esiste effettivamente un collo di bottiglia perfettamente calcolato in RDNA 3 Lite per onda32che viene raddoppiato durante l’utilizzo onda64.
Lo hai perfettamente dettagliato nel più importante articolo di istruzioni di RDNA 3 che abbiamo lanciato questo fine settimana, ma parafrasando Lázaro:
- onde di onda32 Emettono ogni istruzione al massimo una volta.
- Onde onda64 in genere emettono ciascuna istruzione due volte: una per la metà inferiore (articoli di lavoro 31-0) e poi di nuovo per la metà alta (articoli di lavoro 63-32).
Quindi, al problema di Draw Calls e del Command Processor dobbiamo aggiungere i sospetti che avevamo (ora confermati) del VRF.
E la latenza tra scalari e vettore?
Bene, è quello che ci si aspettava vedendo tutto ciò che abbiamo visto intorno all’architettura da quando l’abbiamo dato all’epoca. Con una Infinity Cache da 32 KB L0, 128 KB L1, 2 MB L2 e 32 MB L3, puoi vedere chiaramente gli hop tra di loro in base alle dimensioni allocate rispetto alla latenza sia in Scalar che in Vector .
Il salto di prestazioni con la parte dell’architettura che mantiene RDNA 3 è notevole, la latenza è inferiore rispetto all’RX 6600 XT, il che aiuta a promuovere e alleviare quanto visto sopra.
Ma cosa succede se confrontiamo RDNA 3 Big con RDNA 3 Lite? Bene, puoi vedere le cuciture dell’architettura MCM nella maggior parte. Navi 33 impiega il 58% in meno rispetto a Navi 31 per ottenere dati da Infinity Cachequindi si vedono perfettamente i problemi di un’architettura eterogenea.
Questo contando sui problemi descritti del VRF, perché se guardi da vicino, in Scalar le differenze sono maggiori che in Vectordove il GAP è ridotto dai commenti.
Ridimensionamento della risoluzione, front-end, Command Processor e Hit Rate
Ora è quando tutto si riunisce e possiamo capire molto meglio i colli di bottiglia che si verificano e perché il pareggio chiama non può essere risolto in tempo. I clock finiscono per essere gli stessi tra Front end e Shader, non esatti, ma molto vicini, inoltre, AMD stabilisce che l’Hit Rate ottimale per 1080p è di 32 MB, il che significa che a una risoluzione più alta il tasso di errore aumenta se prendiamo in conto conta la somma di quanto detto.
va fuori portatainizia a perdere prestazioni perché gli Hit Rate aumentano e la minore dimensione del VRF logicamente non aiuta questo, anzi, insieme al Command Processor finisce per rovinarlo.
Aggiungiamo il fatto che c’è una piccola perdita di prestazioni dovuta al suo PCIe 4.0 x8, che sarà un problema sulle schede madri PCIe 3.0 con x8 in quanto tali (poche, sì). È un accumulo di dettagli, che ora avendo i dati, possiamo convenientemente spiegare.
Conclusione di RDNA 3 Lite e RX 7600
Perché AMD ha fatto questo con la RX 7600? Costi, chiaro e semplice. Ridurre PCIe 4.0 x16 a x8 è di per sé un notevole risparmio, questo in qualche modo trascina i cambiamenti dell’architettura, che sono anche spinti da un Nodo N6 che difficilmente aggiunge nulla rispetto all’N7 sopra, e non utilizzando l’N5, che ottiene vantaggi in termini di area e consumo, AMD è stata finalmente spinta a crearlo RDNA 3 Lite per quadrare il cerchio.
Ed è che mantenere il VRF al livello di RDNA 3 significa un’area del die più ampia, che in termini di costi non aiuta se le prestazioni non scalano e giustifica il prezzo più alto che questa carta avrebbe avuto. Riduci VRF, cambi CP, crei un problema di prestazioni interne che si aggiunge al problema di Draw Calls in cui la cache L0 e L1 più grande non compensa e tutto per ridurre l’area, non uscire da Hit Cache e non rilanciare il prezzo per chip.
Il risultato di tutto ciò che abbiamo visto negli articoli successivi è questo, un’architettura mista, che è “quasi” un rimaneggiamento di RDNA 2 piuttosto che un passo avanti rispetto a ciò che è RDNA 3, che non è una panacea in quanto tale, ma che almeno con l’MCM ha portato AMD a intraprendere più modifiche che se avesse visto un chip monolitico. Questo RX 7600 con Navi 33 ne è una piccola prova con RDNA 3 Lite.