di  -  mercoledì 10 giugno 2009

Oggi vorrei parlare di un elemento architetturale su cui si focalizza troppo poco l’attenzione rispetto a quella che è la sua reale importanza e la sua incidenza sulle prestazioni di un sistema come, ad esempio, un pc, o di un sottosistema, come quello grafico: il memory controller (MC). Con particolare riferimento alle vga, già nel 2001, alla presentazione della lightspeed memory architecture, nVidia definì, correttamente, il MC “uno dei componenti più critici di un sistema grafico”.

In effetti il MC è uno dei componenti più critici di qualunque sistema e il motivo è presto detto. Si parla tanto di potenze di calcolo, di MHz, di parallelismo, di unità di calcolo, ma si pensi essenzialmente ad una cosa: istruzioni e dati devono essere spostati di continuo dalla ram all’interno di un chip e viceversa; più dispositivi hanno necessità di accedere alle stesse risorse nello stesso tempo; è necessario permettere alle varie unità di cui è composto un sistema (alu, stream processor, core, ecc) di comunicare tra di loro e scambiarsi quanti più dati e istruzioni possibili ad ogni ciclo ed è necessario permettere che ciò avvenga nel più breve tempo possibile ed in maniera tale da minimizzare i colli di bottiglia.

Perchè ciò avvenga, si ha bisogno di “strade” per dati e istruzioni e di una serie di “semafori” di “vigili urbani” che “dirigano il traffico”. Un memory controller si occupa proprio di gestire questo intenso traffico utilizzando dei canali di comunicazione controllati da dispositivi definiti arbiter (con annessi sequencer). In questo articolo mi occuperò di introdurre soltanto alcuni tra i più noti (ed usati) MC che si possono rinvenire su piattaforme di tipo consumer e, in particolare, quelli presenti all’interno di chip quali cpu, gpu e north bridge. Questi tipi di connessioni rientrano tra quelle definite di tipo dinamico che sono contraddistinte dall’utilizzo di switch e strutture a bus, da contrapporre a quelle di tipo statico, in cui i nodi sono direttamente connessi tra di loro (mesh, ipercubi, ring, alberi, ecc).

Iniziamo col dire che il MC può essere interno ad una cpu o ad una gpu, oppure può essere contenuto all’interno di un altro chip. Ad esempio, nelle architetture per pc di tipo classico, il MC è integrato nel northbridge (NB) e si avvale anche di un hub che mette in comunicazione diretta la cpu e la vga con la ram, indirizza e smista le richieste di accesso alla memoria provenienti anche dal southbridge (SB).

Le richieste di accesso alla ram sono di due tipi: il primo coinvolge la cpu per l’intero processo di trasferimento dei dati e, di conseguenza, comporta un notevole impiego di risorse da parte dell’unità centrale di elaborazione; l’altro, su cui mi soffermerò brevemente, definito DMA (direct memory access), tipico di dispositivi più recenti, coinvolge la cpu solo nell’operazione di inizializzazione della rihciesta di accesso alla ram. In pratica, una volta che è stato assegnato uno specifico compito ad un determinato dispositivo, questo inoltra una comunicazione alla cpu attraverso cui  informa di essere a disposizione per una nuova elaborazione. La cpu invia gli indirizzi dei blocchi di memoria da cui prelevare i dati necessari a eseguire le istruzioni realtive a quel dispositivo. A questo punto, il dispositivo è pronto ad avviare una richiesta di accesso alla ram per prelevare ciò che gli serve. La richiesta è inoltrata al MC che la mette in coda all’interno di un buffer. Una volta che il buffer è pieno, il MC decide quali richieste evadere per prime. Il MC non è un dispositivo in order ed il suo buffer, di conseguenza, non è di tipo FIFO (first in first out), ma decide secondo criteri ben precisi, in base a come è stato ottimizzato il lavoro del sistema. Ad esempio, le richieste di accesso da parte della VGA potrebbero avere la precedenza rispetto a quelle del controller audio e, di conseguenza, anche se sono arrivate dopo vengono evase prima. Una volta che il dispositivo ha completato il suo lavoro, invia un interrupt alla cpu con cui, in pratica, comunica di essere di nuovo a disposizione per l’assegnazione di un nuovo compito.

A seconda della tipologia di network (in questo articolo tratteremo esclusivamente quelli a bus), il MC è impegnato per più o meno cicli di clock prima di tornare disponibile per evadere un’altra richiesta di accesso alla memoria. Uno schema tipico che include il MC (in questo caso può essre integrato nel NB ma anche all’interno della cpu) è quello riportato in figura

mc-pc.jpg

Il MC illustrato è, chiaramente, di tipo single channel, abbinato ad uno o più bus o crossbar switch e i dati in ingresso possono provenire da tutte le periferiche connesse al SB e, anche, dalla vga; c’è da osservare, però, che le moderne GPU hanno la possibilità di accedere direttamente alla ram di sistema (non solo alla vram), bypassando la cpu e il MC integrato in essa o nel NB.

Dopo questa breve digressione, passiamo brevemente in rassegna i principali tipi di bus con relativi MC che si sono visti sui vari sistemi nel corso  di questi anni.

Il più classico è il controller a canale unico a 64 bit, presente sulle piattaforme di tipo single channel visto poco sopra. Il suo funzionamento è schematizzabile con l’esempio in figura

mc-single-channel.jpg

Il canale dei dati (a forma di imbuto) rappresenta il collegamento con la ram di sistema) e l’arbiter è il rubinetto che regola i flussi. In realtà, più che di un rubinetto si può parlare di un semaforo “intelligente”, presente ad un incrocio, in grado di stabilire a chi mostrare il verde e per quanto tempo.

Un’evoluzione del MC single channel è il dual channel

mc-dual-channel.jpg

Come si vede, le “strade verso la memoria” diventano due, raddoppiando il traffico dei dati in ingresso e in uscita. Questo tipo di MC è in grado di trasferire 128 bit per cicli di clock.  Ulteriore evoluzione, il MC triple channel (192 trasferiti per ciclo). Nell’immagine in basso, è riportato uno schema a blocchi,  molto semplificato, di una cpu di tipo opteron, quad core, con MC dual channel integrato

mc-quad-core-amd.jpg

I due canali sono a 72 bit (anzichè 64) per supportare le ram ECC.

Per dovere di cronaca, riporto che un controller multichannel può essere di tipo  sincrono o asincrono: il primo offre prestazioni migliori ma pone qualche vincolo in più (le ram utilizzate devono avere stessa velocità stesse latenze e stessa capacità); il secondo ha prestazioni inferiori, ma permette di utilizzare banchi di ram di capacità differente (ma con identiche frequenze e latenze).

Analogamente a quanto visto per le cpu e per i MC integrati nei NB delle schede motherboard, anche all’interno dei chip grafici è integrato uno o più MC. Poichè questa rubrica si occupa principalmente di vga e gpu, presteremo un’attenzione superiore alle tecnologie utilzzate per queste ultime.

Anche nelle gpu, fino al 2000, si faceva uso di MC di tipo single channel a 64 o a 128 bit, come quello schematizzato in figura

mc-gf2.jpg         Una simile architettura è estremamente semplice ma presenta alcuni colli di bottiglia: innanzitutto ha una granularità “grossa”, in quanto permette solo il trasferimento di blocchi da n bit per ciclo dove n è l’ampiezza del bus (64, 128, 256 bit, ecc) o, se ad esempio, si utilizzano ram di tipo DDR o DD2, ecc, di 2, 4 o più volte n per ciclo (ad esempio un bus da 128 bit abbinato ad una ram DDR permetterà il rasferimento di 256 bit per ciclo del core clock (le DDR hanno un data rate clock differente rispetto al core clock e multiplo di esso rispetto a potenze del 2). In secondo luogo, il MC di questo tipo di bus, in caso di richiesta di DMA deve eseguire le seguenti operazioni: ricevere la richiesta di accesso

inoltrare la stessa alle locazioni in memoria destinatarie della stessa

ricevere dalla ram i dati richiesti

inoltrare gli stessi alle unità di calcolo che ne hanno fatto richiesta

Dopo di che, può tornare a disposizione per una nuova operazione.

Per ovviare la primo dei due inconvenienti presentati, con la presentazione dell’NV20, noto come Geforce 3 e della lightspeed memory architecture, nVidia  introduce un nuovo tipo di controller, definito crossbar, schemattizato qui sotto, per confronto con quello a canale unico

mc-gf3.jpg   e riportato più in dettaglio nella prossima immagine

mc-crossbar.jpg

Come si può vedere, in realtà, il crossbar dell’NV20 è composto da 4 MC di tipo single channel, uno per ognuna delle ROP’s; ciascun MC serve un gruppo di unità di calcolo (alu, fpu e tmu) e ha accesso a ciascuno degli n blocchi di chip di vram presenti on board. Questa soluzione permette di ridurre notevolmnte la granularità dei dati in transito attraverso il bus. Il crossbar di NV20, di NV25 e di NV30, nonchè di R200, gestisce 4 canali da 32 bit ciascuno e lavora con chip di ram con interfaccia a 32 bit. Questo significa che, di fatto, ad ogni ciclo, per ogni MC, si ha transito di soli dati in lettura o scrittura, ma non è possibile sfruttare al meglio la peculiarità di ram, come le DDR, che presentano un fronte in lettura ed uno in scrittura all’interno dello stesso ciclo di core clock.

Questa interfaccia aumenta sensibilmente la complessità del MC ma permette una maggior ottimizzazione nel trasferimento dei dati e nell’inoltro delle richieste di accesso (che passano sempre attraverso gli stessi canali).

Un ulteriore passo in avanti lo fa ATi con R300, portando l’ampiezza del bus a 256 bit. L’architettura è formalmente identica a quella vista per il MC dell’NV20; il vantaggio consiste nel fatto che ogni canale permette il passaggio di un maggior quantitativo di dati anche se si perde in termini di granularità (nelle gpu, però, non si ha necessità di granularità particolarmente fine come nelle cpu, quindi , nel complesso, 4 canali da 64 bit si comportano meglio di 4 da 32). Questa soluzione ha, comunque, dei limiti: intanto non risolve il problema relativo all’utilizzo dell’arbiter che gestisce il singolo canale, che continua ad essere coinvolto in tutte e 4 le operazioni necessarie al trasferimento di dati da e verso la ram. Inoltre, benchè il crossbar sia un tipo di interconnessione studiato, in particolare, per i casi in cui il numero dei banchi o dei chip di ram sia superiore a quello delle unità di calcolo, qualora lo si fa lavorare con più di due chip per canale si ha un aumento delle latenze col risultato che, in elaborazioni che non risultino frame buffer limited, ovvero tali da richiedere più ram di quella presente sulla vga, un maggior quantitativo di chip  per canale ram porta ad un degrado delle prestazioni. Inoltre, la complessità di un crossbar cresce con il quadrato del numero di processori o, in alternativa, di MC utilizzati (nel caso delle gpu col quadrato del numero di MC controller presenti a valle delle ROP’s), ciascuno dei quali deve essere connesso a tutti i cluster di alu ed a tutti i gruppi di chip di ram.  Risulta evidente che il vantaggio del crossbar è che si riduce al minimo il rischio che più utilizzatori debbano concorrere per accedere alle stesse risorse, a patto di dimensionare correttamente il numero di nodi in relazione a quello delle unità di calcolo e dei chip di ram, ma la scalabilità, dal punto di vista dell’hardware, è pessima, poichè la complessità tende ad aumentare molto più rapidamente dei benefici ottenibili.

Un passo in una direzione diversa lo fanno ATi, con R520 prima ed R600 poi, e IBM con il CELL, adottando un bus ad anello. In una connessione a bus, la complessità delle interconnessioni resta costante all’aumentare del numero degli utilizzatori. Il risultato è un’ottima scalabilità sul piano dei costi e della complessità dell’hardware. Le prossime immagini riportano il ring bus di R580

mc-r580-ring-bus.jpg

e di R600

mc-r600-ring-bus.jpg

La prima differenza che salta all’occhio è che in R580 si ha un doppio anello con un MC centrale collegato con un crossbar. Tecnicamente non si può, quindi, parlare di ring bus fully distributed ma di ring bus di tipo ibrido, con le richieste di accesso che viaggiano lungo i canali del crossbar e i dati che sono messi in circolo lungo l’anello (anzi i due anelli, uno percorso in un verso e l’altro in verso opposto). Con R520 prima ed R580 poi, ATi abbandona la soluzione dei 4 canali a 64 bit per optare per 8 canali a 32 bit, in modo da ridurre la granularità ma, all’occorrenza, poter contare ancora su una via di comunicazione ampia 64 verso ciscun gruppo di chip di vram. Il ring bus di R580 presenta anche un altro vantaggio rispetto al crossbar: il MC è impegnato per un numero di operazioni minore e torna, quindi, più rapidamente a disposizione per le operazioni successive. Infatti, il gruppo di 4 MC centrali si occupa solo di ricevere le richieste di accesso alla ram e di inoltrarle alle locazioni interessate. Una volta giunta la richiesta, i dati sono inviati all’anello e, una volta giunti all’altezza del ring stop corrispondente al gruppo di alu che ne hanno fatto richiesta, vengono istradati. Con R520, per la prima volta, ATi fa uso anche di un bus di tipo asimmetrico, ampio 256 bit verso la ram (8 canali da 32) e 512 bit verso i 4 cluster di alu (8 canali da 64 bit). Se questa soluzione risolve il porblema delle elevate latenze del MC di tipo crossbar tradizionale, non risolve quello relativo alla complessità dell’architettura del bus e del relativo sistema di MC.

Con R600 si cerca di far fronte anche all’altro problema, ovvero quello della elevata complessità del crossbar e della sua pessima scalabilità a livello HW e di costi. Si pensa ad una soluzione con MC distribuiti e un gruppo di 4 anelli (2 per i dati e 2 per le richieste) con un sistema di ring stop ciascuno dei quali comprendente 2 MC e 2 canali da 64 bit verso le ram e da 128 verso le alu. In tal modo si elimina il crossbar centrale e si riduce la complessità dell’architettura, migliorandone la scalabilità. Inoltre, ciascun MC si limita a ricevere soltanto le richieste di accesso; qundi le mette in circolo all’interno di uno dei due anelli deputati al trasporto delle stesse. Ogni richiesta è “etichettata” in base alla locazione di memoria a cui è indirizzata; una volta giunta a destinazione, il MC del ring stop corrispondente a quel gruppo di ram si occupa di istradarla. Così il numero delle operazioni di cui si deve far carico ogni MC è ridotto a una. In realtà, le connessioni di tipo crossbar non spariscono del tutto dai MC ma appaiono notevolmente semplificate e ridotte a servire un numero imitato di nodi: sono infatti presenti all’altezza di ogni ring stop, come illustrato mnella successiva figura

mc-r600-particolare.jpg

Anche il ring bus presenta, comunque, difetti e criticità. Una di queste è da ricercarsi nel numero di processori o di cluster di alu destinati ad utilizzare una connessione ad anello di questo tipo. Se è vero che dal punto di vista della scalabilità HW si tratta di una soluzione ottima, è altrattanto vero che, all’aumentare del numero di utilizzatori, peggiora la scalabilità delle performance, al punto che l’ottimizzazione di questo tipo di architettura può diventare un fattore critico. Ad esempio, nel cell, di cui riporto l’immagine,

mc-cell.jpg

il fatto di avere 8 SPE più il PPE e il traffico di dati verso l’esterno del chip da gestire, rende l’ottimizzazione dell’arbiter centrale dell’EIB piuttosto complessa e permette il trasferimento dei dati da un SPE all’altro secondo modalità ben precise, pena un forte decadimento delle prestazioni complessive (che possono arrivare anche a dimezzarsi rispetto al picco massimo raggiungibile). Una delle raccomandazioni è quella, ad esempio, di limitare il trasferimento di dati tra processori molto distanti tra loro  lungo i 4 anelli, oppure di limitare il numero di accessi contemporanei alla ram di sistema o i trafserimenti, lungo l’anello, che seguano tutti lo stesso verso (orario o antiorario); questo perchè nell’EIB (element interconnect bus) del cell 2 anelli sono percorsi in un verso e 2 in verso opposto (quindi la raccomandazione è quella di intasare una strada lasciando sgombra l’altra). Una curiosità che riguarda l’EIB è questa: inizialmente, IBM aveva pensato di utilizzare un crossbar e solo in un secondo tempo, per tentare di risparmiare transistor, ha optato per il ring.

Con le gpu di ultima generazione, da un lato nVidia ha continuato con il tradizionale crossbar, aumentandone l’ampiezza e portandolo, nelle sue versioni di punta, a 512 bit verso la ram (8 canali da 64 bit ciascuno con altrettanti MC) ma adottando una soluzione asimmetrica, con un’ampiezza di 1024 bit verso il chip (16 canali da 64 bit, ciascuno dei quali serve 15 delle 240 alu di GT200), mentre ATi ha abbandonato il ring bus per tornare ad una sorta di crossbar distribuito, con ampiezza pari a 256 bit verso le ram e 2048 (32 canali da 64 bit) bit verso le alu.  In tal modo, ogni canale serve un gruppo di 5 unità vliw, per un totale di 25 alu. L’adozione di ram GDDR5 ha permesso anche di svincolarsi dal limite dei 64 MB per banco (ram GDDR da 128 MB esistono ma sono piuttosto rare e costose) e ha permesso di adottare soluzioni con 1 GB di ram continuando a rispettare la regola dei due chip per canale. In figura, il MC di RV770

mc-rv770.jpg

in cui si notano due cose, in particolare: la presenza di un hub attraverso cui passano tutti i segnali che non riguardano l’elaborazione 3D che in R600 erano gestiti dai MC del ring bus e che in RV770 hanno un canale dedicato a parte (in modo da non interferire negativamente con le elaborazioni grafiche); la presenza di 4 cache, per un totale di poco più di 5 MB, dedicate ai 4 MC e utilizzate per immagazzinare i dati più frequentemente utilizzati, ottimizzando l’occupazione della banda passante verso la ram.

Sulle tipologie di MC e di ram utilizzate ci sarebbero tante cose da aggiungere; ci si potrebbe soffermare sul cell per capire, magari, come sono gestiti i DMA con i SPE che fanno uso di memoria non cached, oppure come si interfaccia con le XDR. O magari si potrebbe parlare delle RDRAM e dei relativi MC. Poichè, però, lo spazio è limitato (e credo di averne abusato già a sufficienza) e l’argomento principale di questa rubrica sono le gpu, mi fermo qui, con una considerazione su quanto visto oggi. I problemi da affrontare sono noti: ci sono sempre più utilizzatori potenziali che devono essere messi in condizione di fruire delle risorse disponibili senza colli di bottiglia. Ciò ha spinto alla ricerca di una serie di soluzioni, nel corso degli anni e se nVidia è stata la prima ad innovare con l’introduzione del crossbar, in seguito si è seduta, puntando sulla forza bruta, ovvero sull’utilizzo di un tipo di connessione verso la ram molto complesso e che non le ha permesso, però, di adottare ram ad elevato bit rate come le GDDR5. Sicuramente, in futuro, anche in vista dell’aumento del numero di alu, sarà costretta a modificare l’architettura del MC. Dall’altra parte ATi ha due strade: aumentare ancora il numero di alu (e di cluster) e, in tal caso, sarà da vedere se un crossbar distribuito di soli 256 bit e con 4 MC sarà sufficiente e che tipo di ottimizzazioni  si renderanno, eventualmente, necessarie, oppure limitare l’aumento del numero di alu su singolo chip e tentare la strada del multicore. In tal caso, il problema si sposterebbe sull’ottimizzazione del lavoro delle 2 o più gpu che intende mettere nello stesso package o sullo stesso die.

Nello stesso tempo, vediamo che Intel pare intenzionata, con Larrabee, a rilanciare l’idea del ring bus, come mostrato in figura

mc-larrabee.jpg

Quello che è certo è che la prossima generazione di GPU, sotto il profilo delle architetture dei MC vedrà ancora delle novità, poichè, all’aumentare delle potenze di calcolo e del parallelismo, la sfida si sposta sempre più sul campo delle architetture preposte al trasferimento ed alla sincronizzazione di questa enorme mole di dati che i futuri chip dovrebbero essere in grado di elaborare.

6 Commenti »

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.

  • # 1
    j
     scrive: 

    articolo molto interessante yoss, complimenti e grazie ;)

    se ti va di approfondire, avrei un quesito, nato da un thread su HWUp e purtroppo non chiarito in modo soddisfacente sul forum, riguardante la famigerata scheda madre intel DX58SO (peculiare per via della presenza dei 3+1 slot dimm connessi elettricamente su tre canali ddr3)
    nella fattispecie il funzionamento in presenza di banchi completamente popolati per un quantitativo di memoria, in GB “non multiplo di 3″, e il motivo per cui tale configurazione comporterebbe prestazioni non ottimali
    nella documentazione è espressamente mezionata una gestione interleaved della memoria da parte dell’ i7, che rende possibile l’ impiego di ram in quantitativi differenti (o assente) sui singoli canali

    ora, questa flessibilità appare logica conseguenza dell’ essere i recenti MC intel, asincroni (come appaiono dal momento che iirc già l’ i925 permetteva di mischiare moduli non perfettamente simmetrici come timings), ma più nel dettaglio questo come funzionerebbe?

  • # 2
    yossarian (Autore del post)
     scrive: 

    nell’articolo sono stato un po’ generico sulle definizioni di MC sincrono e asincrono; un MC sincrono è tale da rendere sincrone sia la ricerca defli indirizzi che le operazioni di scrittora nella memoria. Un MC asincrono può esserlo nei confronti della ricerca degli indirizzi e delle operazioni di scrittura, ma esistono anche soluzioni ibride, come, ad esempio, MC sincroni rispetto al bus e asincroni rispetto all’interfaccia di I/O.
    In un MC asincrono gli accessi in memoria non sono sincronizzati e, di conseguenza, la “scansione” della ram non termina dopo lo stesso numero di cicli di clock. Ovvero, ogni canale può avere velocità di ricerca differenti. In tal caso, le latenze aumentano in quanto dettate dal canale più lento, nel caso, non infrequente, che i dati siano allocati o vadano scritti su banchi facenti serviti da differenti canali.
    Per quanto riguarda il MC interleaved di cui parla Intel, è un MC a tre canali asincrono con un crossbar che permette a ciascuno dei 3 gruppi di arbiter più sequencer di controllare ancha il quarto canale (che, quindi, come ovvio, non è servito da un MC dedicato). Questo significa che l’accesso al quarto banco è di tipo sequenziale (con la regola del primo che si rende disponibile all’esecuzione di un’operazione) e non parallelo, rispetto agli altri 3 e questo porta ad un immancabile decadimento delle prestazioni

  • # 3
    j
     scrive: 

    ah ecco, ora è più chiaro, grazie :)

  • # 4
    Architetture multicore: solo moda o reale necessità? - Appunti Digitali
     scrive: 

    […] del memory controller, permette di ridurre le latenze relative agli accessi alla memoria e riduce la necessità di avere […]

  • # 5
    ATi vs nVidia, the neverending war, III parte: il ritorno di ATi - Appunti Digitali
     scrive: 

    […] dove le richieste di accesso alla ram e le istruzioni viaggiano sui bracci del crossbar mentre i dati si muovono lungo i due anelli del ring bus. […]

  • # 6
    Elementi funzionali di una GPU: le ALU - Appunti Digitali
     scrive: 

    […] unità funzionali di un chip in generale e di una gpu in particolare. Dopo aver fatto cenno al memory controller, voglio infatti introdurre quelle che sono le unità deputate ad eseguire le istruzioni id tipi […]

Scrivi un commento!

Aggiungi il commento, oppure trackback dal tuo sito.

I commenti inseriti dai lettori di AppuntiDigitali non sono oggetto di moderazione preventiva, ma solo di eventuale filtro antispam. Qualora si ravvisi un contenuto non consono (offensivo o diffamatorio) si prega di contattare l'amministrazione di Appunti Digitali all'indirizzo info@appuntidigitali.it, specificando quale sia il commento in oggetto.