“Utilizzo di processori
grafici nel trigger di NA62”
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 NA62
(RICH)
GPU = Graphics Processing Unit
Architettura idonea al calcolo parallelo
ottimizzata per applicazioni di grafica.
Può essere adattata al calcolo scientifico? SI!!!
E al realtime? Forse!
… velocità?
… latenza?
… stabilità?
… robustezza?
… affidabilità?
2
L’esperimento
NA62
NA62
CERN a LHC
occupatum
2763 ab Urbe
Condita
M.Sozzi
3
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
NA62: Introduzione
Previsione nel modello standard con
piccolo errore (“golden 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%
NA62 è 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, Roma1, Roma2,
Torino
4
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
NA62: Introduzione
Fascio non separato ad alta
intensità: identificazione positiva
dei K nel fascio (CEDAR)
Misura di impulso e direzione dei
K nel fascio (GTK) a ~1 GHz
Misura accurata dell’impulso dei
prodotti di decadimento in vuoto
(STRAW)
Sistema di veto ad alta efficienza
(LAV+LKR+IRC+SAC)
Identificazione del tipo di
particella (RICH+MUV)
Ricostruzione cinematica della massa mancante:
definizione di due regioni in massa mancante
PK
Fondo cinematicamente costretto: 92%
Fondo non cinematicamente costretto: 8%
Fascio molto intenso: sistema di readout e trigger idonei
Scopo NA62: O(100) eventi in 2 anni di presa dati +
altre misure importanti nei K + ricerca di nuova fisica in
decadimenti proibiti
Pp
pK
Pn
Pn
5
READOUT & TRIGGER
6
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
NA62 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) 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
CEDAR
STRAWS
1 MHz
1 MHz
L0TP
PC
PC
PC
GigaEth SWITCH
L2
PC PC PC PC PC PC PC PC PC PC
L1
PC
L0: Livello
10 MHz hardware. Decisione
basata sulle primitive
LKR
LAV
prodotte nelle schede
di RO dei detector
che partecipano al
trigger
1 MHz
L1: Livello
Software. La
decisione è presa su
informazioni costruite
PC
PC
al livello del singolo
detector.
L2: Livello
software. Le
informazioni
provenienti da diversi
PC PC PC PC
detector sono messe
insieme
L0
O(KHz)
L0 trigger
Trigger primitives
Data
PC PC PC PC
CDR
EB
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
Schema generale del trigger di NA62
8
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
Sistema integrato Trigger & DAQ
L’acquisizione avviene tramite la TELL1, 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)
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 TELL1 = 512 canali
9
L0 trigger
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
Le primitive di trigger sono prodotte direttamente nella TELL1 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 L0TP che prende la
decisione di trigger, con una latenza totale di 1ms
Diverse soluzioni per L0TP in studio: PC, TELL1 o custom
I dati aspettano la decisione di trigger nelle DDR della TELL1
La memoria delle TELL1 permette una latenza (per tutti i detector con TDC)
molto più lunga (anche l’intero burst). Ma non tutti i detector hanno TELL1 (GTK
& LKR)
La condizione di trigger:
RICH+!MUV+!LKR
Permette una riduzione di un fattore 10 (da 10 MHz a 1 MHz)
10
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
Livelli software
Il livelli di trigger successivi sono
completamente software
Il L2 è costituito da una farm di PC dopo uno
switch GBE
Ogni PC (o gruppo di PC) del L1
riceve i dati e costruisce primitive
relative al solo detector cui si
riferisce (ex: L1-STRAWS
calcolano l’impulso delle tracce,
L1-RICH costruisce i cerchi, …)
Le informazioni di tutti i detector sono messe
insieme per calcolare grandezze più
complesse (ex: massa mancante, energia
totale, …)
Il numero di PC del L1 dipende
dalla quantità di dati e dal rate
all’uscita del L0
La latenza del L2 non è definita, ma tutti i
dati devono essere trattati entro l’arrivo del
burst successivo (circa 16 s)
Il rate totale dopo i livelli software sarà
dell’ordine di decine di kHz
La latenza del L1 non è definita,
ma si assume che tutti i dati siano
accettati o rigettati entro il termine
del burst (circa 6 s)
11
UTILIZZO DEI PROCESSORI
GRAFICI (GPU)
12
NA62: 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
permettere l’acquisizione
di altri canali
Alta efficienza:
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 C1060 (GT200)
Gflops1200
GPUs
1 Tesla GPU
Single Precision
Performance
933 Gigaflops
Double Precision
Performance
78 Gigaflops
Memory
4 GB DDR3
Memory speed
800 MHz
Bandwidth
102 GB/s
NVIDIA GPU
Intel CPU
1000
Tesla 10series
800
600
Tesla 8series
400
200
0
Intel Pentium
4
3.2 GHz
22/09/2002
04/02/2004
Intel Pentium 4
Dual-core 3.0
GHz
Intel Core2
Dual-core 3.0
GHz
18/06/2005
31/10/2006
Intel Xeon
Quad-core 3 GHz
14/03/2008
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)
Il tempo per singolo evento può essere
minimizzato facendo elaborare più eventi
contemporaneamente
Esempio: se il tempo di esecuzione di
1000 eventi è 1 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 NA62
Le GPU possono essere impiegate al L1
& L2 (software)
La latenza non è definita, il rate non è un
problema
Affidabilità e stabilità
Utilità: diminuzione delle dimensioni delle
farm di L1 e L2
Già teoricamente possibile!
RICH
MUV
STRAWS
L0TS
PC
GP
U
PC
GP
U
PC
GP
U
L0 trigger
Trigger primitives
Data to L1
RICH
MUV
GPU
L0TS
GPU
STRAWS
L0 trigger
primitives
Le GPU possono essere impiegate al L0
La latenza è di 1 ms, il rate di eventi è di 10
MHz (=100 ns) sui principali detector
Affidabilità e stabilità
Utilità: selezione più efficiente a L0, possibilità di
raccogliere eventi altrimenti eliminati dalla presa
dati
Trigger Reduced Data
Data to L1
17
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
Esempio: RICH
Il RICH deve separare p/m tra 15 e 35 GeV
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
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à, 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 3D per istogrammi nella shared
memory (2D XYgrid VS raggio del cerchio
di test)
Limitazioni a causa
delle limitazioni della
shared memory
Y
(16K)
Un thread per ogni
centro (hits) → 32
threads (in un thread
block) per evento
Radius
Pro: parellizzazione naturale,
piccolo numero di thread per
evento
Contro: impredicibile accesso
alla shared memory (conflitti in
read & write), uso massiccio
della memoria veloce del chip
20
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
Algoritmo 2: Problem-optimized multi histos (POMH)
Ogni PM (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)
Pro: Operazioni del kernel
veloci e semplici
Contro: assegnamento
delle risorse non naturale;
l’intero processore è
utilizzato per un solo evento
21
distance
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
1 event -> M threads
(each thread for N PMs)
S
h
a
r
e
d
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
GPU 12 hits
Best ring
Hits generated
NA62 - G4 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)
σ~1.5 us
us
Algorithm
TESLA c1060
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: 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) indica che con una latenza di 3.1 ms e
un rate di 320 kHz, il trigger di L0 sarebbe già fattibile a questo livello
Per NA62 (latenza 1 ms, rate 10 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 che fanno
immaginare almeno un fattore 2
GPUs
NVIDIA
ATI HD
NVIDIA
di miglioramento
• Passo successivo: studio di
altri algoritmi per il RICH e di
algoritmi di pattern recognition
per lo spettrometro
FERMI
5870
TESLA
Single
Precision
Performance
2 Teraflops
2.72 Teraflops
933 Gigaflops
Memory
6 GB DDR5
6 GB DDR5
4 GB DDR3
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 L0?
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 gen2 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
NA62 della sezione di Roma2
26
Benefici del trigger GPU per NA62
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 L0 e/o L1/L2)
Ridotto numero di PC nelle L1/L2 farm (calcolo scientifico quasi
standard)
Possibilità di disegnare un livello di trigger L0 molto versatile per
raccogliere selettivamente diversi canali di fisica contemporaneamente
Scalabile e 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 → mm2
27
Una possibile nuova architettura
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
Standard trigger system
FE
digitiz
ation
pipeline
L1
PCs
L0
FE
Trigger
primitives
Trigger
processor
Custom HW
“Triggerless”
Commercial PCs
FE
digitiz
ation
PCs
PCs
Commercial
GPU system
“quasi-triggerless” with GPUs
FE
L1
Digitization + buffer +
(trigger primitives)
L0
PCs+GPU
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 NA62, dedicato alla misura del decadimento raro K→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, 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: [email protected]
[email protected]
[email protected]
30
SPARES
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
Scopi NA62
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,
p0→ggg, …) del K e del p
Fascio adronico di alta intensità
Ricostruzione completa della
cinematica
Ottima capacità di veto e PID
32
La “tecnica” sperimentale di NA62
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
Pp
PK
2
miss
m
pK
Pn
Pn
92%
Kinematically
constrained
Pp
PK
2
PK Pp p2K
m 1
+
m
1
p
PK
Pp
2
K
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 GeV (±1%)
Kaon beam (~6%)
~50MHz
~800MHz
400 GeV SPS
Proton beam
3·1012 ppp
~10MHz
π
ν
ν
Targhetta fissa
Decadimento in volo
Fascio non separato
34
TELL 1
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
La TELL1 è una scheda di acquisizione “general
purpose” sviluppata per LHCB (EPFL Lausanne)
Formato 9U, 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 L0
4 connettori permettono di aggiungere daughter
cards secondo le necessità
Un Credit Card PC (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 e
35
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) 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 TELL1 =
512 canali
128 Input LVDS (con DC-DC converter
8 cavi da 16 coppie)
a basso noise con
Altera Stratix II per monitoring e
filtri analogici
QPLL
on
board
preprocessing
Connettore Lemo
Connettori
Seconda versione. Una nuova
per diretto I/O TTL
miniaturizzati
(su
versione sarà pronta a metà del
ambedue i lati)
1 MB SRAM
prossimo mese
Supporto I2C e JTAG
36
Incontro CCR INFN – Gianluca Lamanna – Napoli 26.1.2010
Generalità sulle GPU
I processori grafici (GPU) sono stati sviluppati per il calcolo matematico 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)
Grande sforzo da parte di NVIDIA per permettere un accesso semplice alle
37
funzionalità del driver (CUDA)
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, 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: 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 GT200
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) 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)
Divergenze nei processi, nello stesso 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
Instruction pool
PU
PU
PU
PU
D
a
t
a
p
o
o
l
lavorano sullo stesso problema)
Parallelizzazione in
una struttura
multicores
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, 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) viene
descritto nel kernel e viene eseguito dal
singolo core
Un gruppo di threads (threads 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). I vari multiprocessori
lavorano in parallelo, ma la
priorità non è definita
40
(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: 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
1
2
Thr 3
3
4
5
Thr 6
6
Thr 7
7
8
9
10
11
Thr
12
12
13
14
Thr
15
15
16
Thr 1
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
64K shared memory
Operazioni atomiche 10X
…
42
