Utilizzo di processori grafici nel trigger di NA

“Utilizzo di processori grafici nel trigger di NA 62” Incontro di lavoro della CCR INFN Napoli 26. 1. 2010 Gianluca Lamanna Scuola Normale Superiore and INFN Pisa

Perché utilizzare le GPU nel trigger? Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 PES 2010: FC Barcellona VS Liverpool Anello ricostruito dall’online monitor durante test beam del rivelatore Cherenkov di NA 62 (RICH) GPU = Graphics Processing Unit Architettura idonea al calcolo parallelo ottimizzata per applicazioni di grafica. Può essere adattata al calcolo scientifico? scientifico SI!!! E al realtime? realtime Forse! … velocità? … latenza? … stabilità? … robustezza? … affidabilità? 2

L’esperimento NA 62 CERN a LHC occupatum 2763 ab Urbe Condita M. Sozzi 3

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 NA 62: Introduzione Previsione nel modello standard con piccolo errore (“golden mode”) mode Ottima capacità di discriminazione tra modelli BSM Una sola traccia nello stato finale Eventi di fondo diversi ordini di grandezze più frequenti Buon sistema di veto e di PID Fascio adronico molto intenso Misura attuale con 7 candidati e errore totale di ~65% NA 62 è un esperimento su targhetta BR(K+→pnn)TH=(8. 22± 0. 84) · 10 -11 fissa all’acceleratore SPS del CERN Lo scopo principale è la misura del decadimento ultrararo K+→p+nn E’ in fase di costruzione e si prevede l’inizio della presa dati nel 2012 24 istituzioni, ~130 persone INFN: Ferrara, Firenze, Frascati, Napoli, Perugia, Pisa, Roma 1, Roma 2, Torino 4

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 NA 62: Introduzione Fascio non separato ad alta intensità: intensità identificazione positiva dei K nel fascio (CEDAR) CEDAR Misura di impulso e direzione dei K nel fascio (GTK) GTK a ~1 GHz Misura accurata dell’impulso dei prodotti di decadimento in vuoto (STRAW) STRAW Sistema di veto ad alta efficienza (LAV+LKR+IRC+SAC) LAV+LKR+IRC+SAC Identificazione del tipo di particella (RICH+MUV) RICH+MUV Ricostruzione cinematica della massa mancante: definizione di due regioni in massa mancante Fondo cinematicamente costretto: 92% Fondo non cinematicamente costretto: 8% Fascio molto intenso: intenso sistema di readout e trigger idonei Scopo NA 62: NA 62 O(100) eventi in 2 anni di presa dati + altre misure importanti nei K + ricerca di nuova fisica in decadimenti proibiti 5

READOUT & TRIGGER 6

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 NA 62 trigger Contesto sperimentale: Esperimento su targhetta fissa → no clock dalla macchina (eventi distribuiti nel burst) L’elettronica di Readout può essere posta vicino al FE per ogni detector No importanti problemi di dose Richieste al Readout & Trigger: decadimenti ultrarari → alto rate, alta efficienza di trigger, bassa probabilità di veto random no limitazione dal flusso di protoni → scalabilità in termini di banda Affidabilità dei veti → controllo delle inefficienze di lettura a 10 -8, lettura senza zero suppression per gli eventi candidati Altri canali di fisica e canali di controllo, aumenti dell’intensità → flessibilità Economicità → utilizzo di soluzioni già esistenti detector Rate (MHz) CEDAR 50 GTK 800 LAV (total) 9. 5 STRAW (each) 8 RICH 8. 6 LKR 10. 5 MUV 9. 2 SAC 1. 5 Sistema di readout e trigger (TDAQ) TDAQ completamente integrato e digitale → controllo e misura di inefficienze direttamente sui dati raccolti Hardware custom minimo → possibilità di pieno controllo della catena di trigger e di utilizzo di soluzioni già esistenti (HEP o commerciali) Uniformità tra i detectors → più semplice gestione 7

RICH MUV STRAWS 1 MHz L 0 TP PC PC PC Giga. Eth SWITCH Trigger primitives Data PC PC CDR O(KHz) EB L 0 trigger L 2 PC PC PC L 1 PC CEDAR L 0: L 0 Livello 10 MHz hardware. Decisione basata sulle primitive LKR LAV prodotte nelle schede di RO dei detector che partecipano al trigger 1 MHz L 1: L 1 Livello Software. La decisione è presa su informazioni costruite PC PC al livello del singolo detector. L 2: L 2 Livello software. Le informazioni provenienti da diversi PC PC detector sono messe insieme L 0 Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Schema generale del trigger di NA 62 8

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Sistema integrato Trigger & DAQ L’acquisizione avviene tramite la TELL 1, TELL 1 una scheda “general purpose” sviluppata per LHCB (EPFL Lausanne) Nella stessa scheda si definiscono le primitive di trigger 5 FPGA (Altera Stratix) permettono una completa configurazione 4 connettori permettono di aggiungere daughter cards secondo le necessità La maggior parte dei detector Standard GBE network card (4 links) per la utilizzano TDCs raccolta dei dati in uscita Una mezzanina è stata sviluppata dal gruppo di Pisa, per fornire un’alta risoluzione temporale (100 ps) ps usando gli HPTDC (CERN) con un’alta densità di canali Una TDCB contiene 4 HPTDC per un totale di 128 canali, 4 daughter boards per TELL 1 = 512 canali 9

L 0 trigger Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Le primitive di trigger sono prodotte direttamente nella TELL 1 con gli stessi dati destinati al RO Esempio: molteplicità in bin di tempo di 3. 125 ns per identificare positivamente le particelle cariche (nel RICH o in un possibile odoscopio carico) Tramite un canale GBE le primitive sono inviate al L 0 TP che prende la decisione di trigger, con una latenza totale di 1 ms Diverse soluzioni per L 0 TP in studio: PC, TELL 1 o custom I dati aspettano la decisione di trigger nelle DDR della TELL 1 La memoria delle TELL 1 permette una latenza (per tutti i detector con TDC) molto più lunga (anche l’intero burst). burst Ma non tutti i detector hanno TELL 1 (GTK & LKR) La condizione di trigger: RICH+ RICH !MUV+ !MUV !LKR Permette una riduzione di un fattore 10 (da 10 MHz a 1 MHz) MHz 10

Livelli software Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Il livelli di trigger successivi sono completamente software Il L 2 è costituito da una farm di PC dopo uno switch GBE Le informazioni di tutti i detector sono Ogni PC (o gruppo di PC) del L 1 messe insieme per calcolare grandezze più riceve i dati e costruisce primitive complesse (ex: massa mancante, energia relative al solo detector cui si totale, …) riferisce (ex: L 1 -STRAWS calcolano l’impulso delle tracce, L 1 La latenza del L 2 non è definita, ma tutti i RICH costruisce i cerchi, …) dati devono essere trattati entro l’arrivo del burst successivo (circa 16 s) Il numero di PC del L 1 dipende s dalla quantità di dati e dal rate Il rate totale dopo i livelli software sarà all’uscita del L 0 dell’ordine di decine di k. Hz La latenza del L 1 non è definita, ma si assume che tutti i dati siano accettati o rigettati entro il termine del burst (circa 6 s) s 11

UTILIZZO DEI PROCESSORI GRAFICI (GPU) 12

NA 62: perché un trigger con GPU? Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 In un esperimento di ricerca di eventi rari un trigger efficiente e selettivo è essenziale Alta flessibilità: per Alta efficienza: permettere l’acquisizione di altri canali per non pregiudicare la statistica totale Alto rigetto: per non saturare la banda e i dischi con dati di scarso interesse Selezione di alta qualità fin dai primi livelli del trigger Processori di calcolo nei Livelli più bassi del trigger!!! 13

Supercomputing VS Real Time Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Calcolo scientifico Pochi dati da trasferire in input Tempo di esecuzione fluttuante Parallelizzazione sull’algoritmo Latenza poco rilevante Calcolo con alta precisione Tempo di esec. dipende dalla complessità Grande utilizzo della memoria video Real Time → → → → Ampia banda per trasferimento dati in input Tempo di esecuzione quasi-deterministico Parallelizzazione sugli eventi Latenza ridotta Calcolo con precisione sufficiente Tempo di esecuzione indipendente dal dato Limitato utilizzo della memoria video 14

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 NVIDIA Tesla C 1060 (GT 200) GPUs 1 Tesla GPU Single Precision Performance 933 Gigaflops Double Precision Performance 78 Gigaflops Memory 4 GB DDR 3 Memory speed 800 MHz Bandwidth 102 GB/s 15

Uso in real time come trigger Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 I dati sono portati attraverso GBE (o GBE custom, vedi Il kernel inizia l’esecuzione sotto) alla RAM del PC Il PC trasferisce un pacchetto di N dati da esaminare alla scheda video La latenza massima del trigger fissa il tempo totale in cui la decisione di trigger deve essere presa Il rate di eventi fissa la velocità di elaborazione del singolo evento I tempi di trasferimento possono essere trascurati rispetto al tempo di esecuzione in quanto questa può essere contemporanea al trasferimento (streams) streams Il tempo per singolo evento può essere minimizzato facendo elaborare più eventi contemporaneamente Esempio: Esempio se il tempo di esecuzione di 1000 eventi è 1 ms, ms questo va bene per un trigger con latenza 1 ms (più qualcosa) e con rate di eventi di 1 ms/1000 → 1 MHz I risultati arrivano sul PC e vengono mandati al Trigger Processor t Il kernel finisce l’esecuzione. I risultati vengono trasferiti sul PC 16

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Possibile schema di trigger in NA 62 Le GPU possono essere impiegate al L 1 & L 2 (software) La latenza non è definita, il rate non è un problema Affidabilità e stabilità Utilità: Utilità diminuzione delle dimensioni delle farm di L 1 e L 2 Già teoricamente possibile! RICH MUV STRAWS L 0 TS PC GPU L 0 trigger Trigger primitives Data to L 1 RICH MUV STRAWS L 0 trigger primitives GPU L 0 TS GPU Le GPU possono essere impiegate al L 0 La latenza è di 1 ms, ms il rate di eventi è di 10 MHz (=100 ns) sui principali detector Affidabilità e stabilità Utilità: Utilità selezione più efficiente a L 0, possibilità di raccogliere eventi altrimenti eliminati dalla presa dati Trigger Reduced Data to L 1 17

PM T’ s Il RICH deve separare p/m tra 15 e 35 Ge. V Fattore di soppressione dei m: almeno 100 Risoluzione temporale : 100 ps Tubo di 17 m x 3 m, Neon 1 atm, specchio a mosaico (18 specchi esagonali) Focalizzazione su due spot da 1000 PMTs ognuno Presenza della beam pipe (dopo lo spettrometro) per evitare segnale dalle particelle del fascio p+ beam pipe 1 atm Ne gas PM T’ s Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Esempio: RICH mirror 17 m 18

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Esempio: RICH Ricerca di anelli nel rivelatore RICH 2 spot da ~1000 fototubi Ogni cerchio ha in media circa ~20 hits Il raggio è proporzionale alla velocità, velocità il centro è proporzionale all’angolo Rate totale ~10 MHz Contributo proveniente da muoni (paralleli) dell’alone del fascio (~1 MHz ) Possibilità di multipli cerchi La cosa più semplice per individuare la presenza di un cerchio è fare un trigger di molteplicità E’ stato dimostrato che un trigger di questo tipo, con buona efficienza a qualunque energia, implica un trasporto di dati tra le varie parti del sistema non sostenibile 19

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Algoritmo 1: Hough Transform Ogni hit è il centro di un cerchio di “test” di raggio assegnato. Il centro del cerchio Cherenkov è il punto comune dei cerchi di test posizione dei PMs → constant memory hits → global memory Prototipi dei cerchi di test → constant memory Spazio 3 D per istogrammi nella shared memory (2 D XYgrid VS raggio del cerchio di test) Limitazioni a causa delle limitazioni della shared memory Y (16 K) 16 K Un thread per ogni centro (hits) → 32 threads (in un thread block) per evento Pro: Pro parellizzazione naturale, piccolo numero di thread per evento Contro: Contro impredicibile accesso alla shared memory (conflitti in read & write), write uso massiccio della memoria veloce del chip X Radius 20

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Algoritmo 2: Problem-optimized multi histos (POMH) Ogni PM (1000) 1000 è considerato come centro di un cerchio Per ogni centro si costruisce un istogramma delle distanze tre il centro e gli hits (<32). L’intero processore è utilizzato per un singolo evento (visto il grande numero di centri): un thread = un centro Il singolo thread deve calcolare poche distanze Molti histogrammi sono calcolati nella shared memory. Non “naturale” per la GPU: non si sfrutta ottimamente la parallelizzazione Non è possibile processare più di un evento contemporaneamente (il parallelismo è completamente sfruttato per accelerare il calcolo) distance Pro: Pro Operazioni del kernel veloci e semplici Contro: Contro assegnamento delle risorse non naturale; l’intero processore è utilizzato per un solo evento 21

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Algoritmo 3: Device-Optimized multi histos (DOMH) Esattamente lo stesso algoritmo rispetto a POMH, ma con diversa assegnazione delle risorse. Il sistema è sfruttato in un modo più “naturale”: ogni blocco è dedicato a un singolo evento Nella shared memory è costruito un solo istogramma Ogni thread deve processare più di un centro Molti eventi sono processati in parallelo contemporaneamente Più facile evitare conflitti nella shared e global memory 1 event -> M threads (each thread for N PMs) S h a r e d G L O B A L M E MO R Y 22

Risultati algo 1 algo 2 algo 3 Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 us sio er F tv irs im n i M em in pt to s ce ac m e M ptim o s . im l e rn e K t op tip ul M σ~1. 5 us us le e n ve GPU 12 hits Best ring ts Hits generated NA 62 - G 4 MC Diversi step di ottimizzazione preliminare HOUGH e DOMH processano più eventi contemporaneamente, POMH uno solo In HOUGH i conflitti in shared memory sono difficili da gestire Lo spread nell’esecuzione del kernel è intorno al 1. 5 us (globale) Algorithm TESLA c 1060 Hough 85 us POMH 139 us DOMH 12. 4 us 23

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Ottimizzazione di DOMH I due parametri cruciali da ottimizzare sono: N: Numero totale di eventi da processare nello stesso kernel PM: PM numero di PM da processare nello stesso thread us 8 PMs x Thread Il tempo di esecuzione è lineare con il numero di eventi (si sceglie 1000 eventi) Il minimo per numero di PM si ha su 8 Working Point (N=1000, PM=8) → 10. 8 ms/evento Ulteriori ottimizzazioni: arrays dai local registers alla shared memory → 6 ms/evento Ottimizzazione di occupazione → 5. 9 ms/evento Ottimizzazione degli Istogrammi in shared memory → 5. 0 ms/evento Conflitti nella constant memory → 3. 1 ms/evento N events us 1000 events x kernel PM x Thread Tempi di trasferimento dati (per pacchetto): Dati dall’ host alla vram GPU → 70 us Risultati dalla vram GPU all’host → 7 us 24

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Sviluppi futuri Il risultato ottenuto (3. 1 us/evento) us/evento indica che con una latenza di 3. 1 ms e un rate di 320 k. Hz, k. Hz il trigger di L 0 sarebbe già fattibile a questo livello Per NA 62 (latenza 1 ms, rate 10 MHz) MHz è necessario usare 30 GPU (semplice calcolo distribuito) Raggiungere il livello di 1 us/evento sembra fattibile allo stato attuale attraverso nuovi algoritmi in studio Le nuove generazioni di processori video presentano caratteristiche fanno immaginare almeno un fattore 2 di miglioramento • Passo successivo: studio di altri algoritmi per il RICH e di algoritmi di pattern recognition per lo spettrometro GPUs NVIDIA FERMI ATI HD 5870 NVIDIA TESLA Single Precision Performance 2 Teraflops 2. 72 Teraflops 933 Gigaflops Memory 6 GB DDR 5 4 GB DDR 3 Memory speed ? 1. 2 GHz 800 MHz Bandwidth 230 GB/s 153 GB/s 103 GB/s Stream processors 512 1600 240 25

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Cosa manca per realizzare il L 0? La parte non deterministica di questo sistema è dovuta alla necessità di usare un PC per poter controllare il processore grafico Pensare di impiegare un sistema custom basato su FPGA senza PC è impossibile al momento (così come pensare di portare i dati sulla memoria video senza passare dalla RAM, almeno su TESLA) Il processore del PC deve fare il minor lavoro possibile 2 soluzioni per ridurre il contributo della CPU: Linux Real-Time (o simile) su macchina bi-processore Scheda GBE intelligente (con FPGA) connessa su PCI-ex gen 2 per “spacchettare” i dati e fornirli direttamente alla RAM limitando il lavoro del processore Tale scheda, in versione prototipale, è stata sviluppata dal gruppo TDAQ di NA 62 della sezione di Roma 2 26

Benefici del trigger GPU per NA 62 Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Molti vantaggi connessi all’uso di GPU a livello di trigger: Approccio quasi-triggerless : la maggior parte dei dati sono processati in PC (a L 0 e/o L 1/L 2) Ridotto numero di PC nelle L 1/L 2 farm (calcolo scientifico quasi standard) Possibilità di disegnare un livello di trigger L 0 molto versatile per raccogliere selettivamente diversi canali di fisica contemporaneamente Scalabile e Upgradabile: Upgradabile compatibile con upgrade di luminosità o estensioni del detector Sistema facilmente adattabile ad altri esperimenti Soluzione a basso costo, basata su tecnologia commerciale. a b RICH STRAWS RICH(r, (x, y)) +mp → (b, pp) + ptkick → (a, pp) + K → mm 2 27

Una possibile nuova architettura Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Standard trigger system FE digitiz ation pipeline L 1 PCs L 0 FE Trigger primitives Trigger processor Custom HW “Triggerless” Commercial PCs FE digitiz ation PCs Commercial GPU system “quasi-triggerless” with GPUs FE L 1 Digitization + buffer + (trigger primitives) L 0 PCs+GPU 28

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Conclusioni I processori grafici stanno dimostrando grandi capacità nel calcolo scientifico I recenti miglioramenti in termini di potenza di calcolo e conseguente riduzione della latenza, permettono di pensare ad applicazioni Real time L’esperimento NA 62, NA 62 dedicato alla misura del decadimento raro K→pnn, pnn potrebbe beneficiare molto dell’utilizzo nei primi livelli di trigger di una selezione basata su primitive di alta qualità, definite per mezzo di calcolo veloce su GPU L’impiego nei livelli software a latenza indefinita non presenta particolari problemi L’impiego nei livelli hardware è molto promettente, promettente anche in vista dei prossimi sviluppi tecnologici nelle schede video Grande vantaggio connesso all’utilizzo di una tecnologia commerciale in rapido e continuo sviluppo (Computer grafica, video games, …) La crescita in potenza e il prezzo competitivo, insieme con la versatilità dell’approccio, rendono l’idea di utilizzare le GPU molto interessante per scopi di trigger in esperimenti di fisica delle alte energie! 29

Per ulteriori informazioni: gianluca. lamanna@pi. infn. it marco. sozzi@pi. infn. it gianmaria. collazuol@pi. infn. it 30

SPARES

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Scopi NA 62 Scopo principale è misurare il BR(K→pnn) con O(100) eventi, ~10 % di fondo, in 2 anni di presa dati Diverse altre misure importanti per la determinazione di parametri nella descrizione della dinamica delle interazioni adroniche a bassa energia Ricerca diretta di processi esotici (es: Sgoldstino di piccola massa, LFV, …) e proibiti (es: K→pg, p 0→ggg, …) del K e del p Fascio adronico di alta intensità Ricostruzione completa della cinematica Ottima capacità di veto e PID 32

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 La “tecnica” sperimentale di NA 62 92% Kinematically constrained Ricostruzione cinematica completa → misura dell’impulso del K e del p prodotto dal decadimento in volo 8% Not Kinematically constrained Identificazione del fondo non escluso dalla cinematica → PID e Veti Segnale molto piccolo → fascio intenso, trigger efficiente e selettivo 33

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Beam line 75 Ge. V (± 1%) Kaon beam (~6%) ~50 MHz ~800 MHz 400 Ge. V SPS Proton beam 3· 1012 ppp ~10 MHz π ν ν Targhetta fissa Decadimento in volo Fascio non separato 34

TELL 1 Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 La TELL 1 è una scheda di acquisizione “general purpose” sviluppata per LHCB (EPFL Lausanne) Formato 9 U, crate speciale (senza bus e alimentazioni dedicate) 5 FPGA (Altera Stratix) permettono una completa configurazione 384 Mbytes di DDR ram per “bufferizzare” i dati in attesa della decisione di trigger di L 0 4 connettori permettono di aggiungere daughter cards secondo le necessità Un Credit Card PC (CCPC) CCPC per controllare la scheda, connessione TTC per trigger e clock Standard GBE network card (4 links) per la raccolta dei dati in uscita Semplice implementare procedure di controllo di flusso e monitor Sviluppo di una nuova versione con nuove FPGA 35 e caratteristiche più performanti

TDC board (TDCB) Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 La maggior parte dei detector utilizzano TDCs Una mezzanina è stata sviluppata dal gruppo di Pisa, per fornire un’alta risoluzione temporale (100 ps) ps usando gli HPTDC (CERN) con un’alta densità di canali Una TDCB contiene 4 HPTDC per un totale di 128 canali 4 daughter boards per TELL 1 = 512 canali 128 Input LVDS (con 8 cavi da 16 Altera Stratix II per monitoring e coppie) preprocessing QPLL on board Seconda versione. Una nuova Connettori versione sarà pronta a metà del miniaturizzati (su prossimo mese ambedue i lati) Supporto I 2 C e JTAG DC-DC converter a basso noise con filtri analogici Connettore Lemo per diretto I/O TTL 1 MB SRAM 36

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Generalità sulle GPU I processori grafici (GPU) GPU sono stati sviluppati per il calcolo matematico intensivo, intensivo soprattutto per applicazioni di grafica Le GPU hanno superato le CPU in termini di GFLOPS Recentemente si è molto sviluppato l’utilizzo di questi device per computing in applicazioni non grafiche (GPGPU) GPGPU Grande sforzo da parte di NVIDIA permettere un accesso semplice alle funzionalità del driver (CUDA) CUDA 37

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Perché le GPU sono più potenti delle CPU? Nelle GPU molti più transistors sono utilizzati per il calcolo, calcolo rispetto al caching o al controllo di flusso I due processori non sono intercambiali (hanno funzioni differenti e affrontano i problemi in modo differente) Aggirata la legge di Moore: Moore per aumentare la capacità di calcolo i processori non diventeranno più veloci ma più grandi! Architettura e algoritmi massivamente paralleli 38

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Schema strutturale del GT 200 La struttura delle GPU è fortemente pensata per la parallelizzazione I core di calcolo sono raggruppati in 30 Multiprocessori (8 core per multiprocessore = 240 core) Ogni MP condivide uno stesso spazio di memoria (shared memory) memory per mezzo del quale i core “comunicano” In ogni MP i processi sono schedulati in modalità SIMD (Single Instruction Multiple data) Tutti i processi che vengono eseguiti su un MP eseguono le stesse istruzioni (Instruction pool) su dati differenti Le istruzioni vengo quadruplicate nel pool in modo da eseguire 32 processi concorrenziali (warp) warp Divergenze nei processi, nello stesso MP, MP generano perdita di parallelizzazione (recuperata appena possibile) Lo stesso MP può eseguire più di 32 processi, schedulati dal driver sequenzialmente Codice parallelo (molti threads Parallelizzazione in una struttura multicores Instruction pool PU PU D a t a p o o l lavorano sullo stesso problema) Eventi-Multipli (molti eventi sono processati nello stesso tempo) 39

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Schema di esecuzione Quello che la GPU deve fare viene definito nel Kernel, Kernel come una semplice funzione C Il Kernel è sempre lanciato da un programma Host che risiede sulla CPU Thread Per-thread Local Storage Block Per-block Shared Memory Il singolo processo (thread) thread viene descritto nel kernel e viene eseguito dal singolo core Un gruppo di threads (threads block) block è eseguito dal Multiprocessore. La struttura dei blocchi è definita al lancio del kernel. I thread nel blocco si parlano attraverso la shared memory. Grid. . . Per-device Global Memory: final result Ogni blocco può essere visto come il membro di una griglia (Grid). Grid I vari multiprocessori lavorano in parallelo, ma la priorità non è definita 40 (scalabilità) scalabilità

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 Gestione della memoria Memory In/out chip Cach ed Access Scope Lifetim e Register In no R/W 1 thread Thread Local Out no R/W 1 thread Thread Shared In no R/W 1 thread block Block Global Out no R/W All threads Kernel Constant Out yes R All threads Kernel Texture Out yes R All threads Kernel Le schede video dispongono di spazi di memoria differenti da quelli della CPU Il modo di utilizzo di questi spazi è completamente differente e deve tener conto dell’architettura del device L’ottimizzazione di un kernel deve necessariamente passare dalla corretta gestione della memoria Esempio: Esempio la shared memory ha una banda di 1 TB/s solo se si evitano conflitti per banchi in R/W, la global memory ha una banda di 100 GB/s solo se si accede con la coalescenza Global memory Shared memory Thr 1 Thr 3 Thr 6 Thr 7 Thr 12 Thr 15 41

Incontro CCR INFN – Gianluca Lamanna – Napoli 26. 1. 2010 NVIDIA FERMI (GT 300) In più: Gestione della memoria a 40 bit unificata Doppio DMA per trasferimento dati Esecuzione parallela multi-kernel 64 K shared memory Operazioni atomiche 10 X … 42