General-Purpose Computing on Graphic Processing Unit (GPGPU): metodi e tecnologie per lo sviluppo di applicazioni

Microprocessori basati su singolo processore (CPU), hanno visto una rapida crescita di performances ed un abbattimento dei costi per circa venti anni. Questi microprocessori hanno portato una potenza di calcolo nell’ordine del GFLOPS (Giga Floating Point Operation per Second) sui PC Desktop e centinaia di GFLOPS su clusters di server. Questa ascesa ha portato nuove funzionalità nei programmi, migliori interfacce utente e tanti altri vantaggi. Tuttavia questa crescita ha subito un brusco rallentamento nel 2003 a causa di consumi energetici sempre più elevati e problemi di dissipazione termica, che hanno impedito incrementi di frequenza di clock. I limiti fisici del silicio erano sempre più vicini. Per ovviare al problema i produttori di CPU (Central Processing Unit) hanno iniziato a progettare microprocessori multicore, scelta che ha avuto un impatto notevole sulla comunità degli sviluppatori, abituati a considerare il software come una serie di comandi sequenziali. Quindi i programmi che avevano sempre giovato di miglioramenti di prestazioni ad ogni nuova generazione di CPU, non hanno avuto incrementi di performance, in quanto essendo eseguiti su un solo core, non beneficiavano dell’intera potenza della CPU. Per sfruttare appieno la potenza delle nuove CPU la programmazione concorrente, precedentemente utilizzata solo su sistemi costosi o supercomputers, è diventata una pratica sempre più utilizzata dagli sviluppatori. Allo stesso tempo, l’industria videoludica ha conquistato una fetta di mercato notevole: solo nel 2013 verranno spesi quasi 100 miliardi di dollari fra hardware e software dedicati al gaming. Le software houses impegnate nello sviluppo di videogames, per rendere i loro titoli più accattivanti, puntano su motori grafici sempre più potenti e spesso scarsamente ottimizzati, rendendoli estremamente esosi in termini di performance. Per questo motivo i produttori di GPU (Graphic Processing Unit), specialmente nell’ultimo decennio, hanno dato vita ad una vera e propria rincorsa alle performances che li ha portati ad ottenere dei prodotti con capacità di calcolo vertiginose. Ma al contrario delle CPU che agli inizi del 2000 intrapresero la strada del multicore per continuare a favorire programmi sequenziali, le GPU sono diventate manycore, ovvero con centinaia e centinaia di piccoli cores che eseguono calcoli in parallelo. Questa immensa capacità di calcolo può essere utilizzata in altri campi applicativi? La risposta è si e l’obiettivo di questa tesi è proprio quello di constatare allo stato attuale, in che modo e con quale efficienza pùo un software generico, avvalersi dell’utilizzo della GPU invece della CPU.

Gpu-based many-core architecture emulation: A double level approach

The efficient emulation of a many-core architecture is a challenging task, each core could be emulated through a dedicated thread and such threads would be interleaved on an either single-core or a multi-core processor. The high number of context switches will results in an unacceptable performance. To support this kind of application, the GPU computational power is exploited in order to schedule the emulation threads on the GPU cores. This presents a non trivial divergence issue, since GPU computational power is offered through SIMD processing elements, that are forced to synchronously execute the same instruction on different memory portions. Thus, a new emulation technique is introduced in order to overcome this limitation: instead of providing a routine for each ISA opcode, the emulator mimics the behavior of the Micro Architecture level, here instructions are date that a unique routine takes as input. Our new technique has been implemented and compared with the classic emulation approach, in order to investigate the chance of a hybrid solution.

Conversione a OpenCL di un simulatore cardiaco parallelo

In questa tesi discuteremo come è possibile effettuare la traduzione di un software parallelo scritto in linguaggio CUDA ad uno in linguaggio OpenCL. Tratteremo le tecnologie utilizzate per lo sviluppo di un simulatore cardiaco parallelo e discuteremo in particolar modo come derivare da queste una versione che ne permetta l’esecuzione su schede video e processori arbitrari. Questa versione verrà messa poi a confronto con quelle già esistenti, per analizzarne prestazioni ed eventuali cambiamenti strutturali del codice. Quanto affermato sopra è stato possibile in gran parte grazie ad un wrapper chiamato SimpleCL pensato per rendere la programmazione OpenCL simile a quella in ambiente CUDA. OpenCL permette di operare con le unità di calcolo in maniera molto astratta, ricordando vagamente i concetti di astrazione di memoria e processori della controparte NVIDIA. Ragionevolmente SimpleCL fornisce solamente una interfaccia che ricorda chiamate CUDA, mantenendo il flusso sottostante fedele a quello che si aspetterebbe OpenCL.

Multi-GPU support on the marrow algorithmic skeleton framework

Dissertação para obtenção do Grau de Mestre em Engenharia Informática

Large-scale Network Analysis on Distributed Architectures

Questa dissertazione esamina le sfide e i limiti che gli algoritmi di analisi di grafi incontrano in architetture distribuite costituite da personal computer. In particolare, analizza il comportamento dell'algoritmo del PageRank così come implementato in una popolare libreria C++ di analisi di grafi distribuiti, la Parallel Boost Graph Library (Parallel BGL). I risultati qui presentati mostrano che il modello di programmazione parallela Bulk Synchronous Parallel è inadatto all'implementazione efficiente del PageRank su cluster costituiti da personal computer. L'implementazione analizzata ha infatti evidenziato una scalabilità negativa, il tempo di esecuzione dell'algoritmo aumenta linearmente in funzione del numero di processori. Questi risultati sono stati ottenuti lanciando l'algoritmo del PageRank della Parallel BGL su un cluster di 43 PC dual-core con 2GB di RAM l'uno, usando diversi grafi scelti in modo da facilitare l'identificazione delle variabili che influenzano la scalabilità. Grafi rappresentanti modelli diversi hanno dato risultati differenti, mostrando che c'è una relazione tra il coefficiente di clustering e l'inclinazione della retta che rappresenta il tempo in funzione del numero di processori. Ad esempio, i grafi Erdős–Rényi, aventi un basso coefficiente di clustering, hanno rappresentato il caso peggiore nei test del PageRank, mentre i grafi Small-World, aventi un alto coefficiente di clustering, hanno rappresentato il caso migliore. Anche le dimensioni del grafo hanno mostrato un'influenza sul tempo di esecuzione particolarmente interessante. Infatti, si è mostrato che la relazione tra il numero di nodi e il numero di archi determina il tempo totale.

Tecniche di ottimizzazione del software per sistemi su singolo chip per applicazioni di Nomadic Computing

I moderni sistemi embedded sono equipaggiati con risorse hardware che consentono l’esecuzione di applicazioni molto complesse come il decoding audio e video. La progettazione di simili sistemi deve soddisfare due esigenze opposte. Da un lato è necessario fornire un elevato potenziale computazionale, dall’altro bisogna rispettare dei vincoli stringenti riguardo il consumo di energia. Uno dei trend più diffusi per rispondere a queste esigenze opposte è quello di integrare su uno stesso chip un numero elevato di processori caratterizzati da un design semplificato e da bassi consumi. Tuttavia, per sfruttare effettivamente il potenziale computazionale offerto da una batteria di processoriè necessario rivisitare pesantemente le metodologie di sviluppo delle applicazioni. Con l’avvento dei sistemi multi-processore su singolo chip (MPSoC) il parallel programming si è diffuso largamente anche in ambito embedded. Tuttavia, i progressi nel campo della programmazione parallela non hanno mantenuto il passo con la capacità di integrare hardware parallelo su un singolo chip. Oltre all’introduzione di multipli processori, la necessità di ridurre i consumi degli MPSoC comporta altre soluzioni architetturali che hanno l’effetto diretto di complicare lo sviluppo delle applicazioni. Il design del sottosistema di memoria, in particolare, è un problema critico. Integrare sul chip dei banchi di memoria consente dei tempi d’accesso molto brevi e dei consumi molto contenuti. Sfortunatamente, la quantità di memoria on-chip che può essere integrata in un MPSoC è molto limitata. Per questo motivo è necessario aggiungere dei banchi di memoria off-chip, che hanno una capacità molto maggiore, come maggiori sono i consumi e i tempi d’accesso. La maggior parte degli MPSoC attualmente in commercio destina una parte del budget di area all’implementazione di memorie cache e/o scratchpad. Le scratchpad (SPM) sono spesso preferite alle cache nei sistemi MPSoC embedded, per motivi di maggiore predicibilità, minore occupazione d’area e – soprattutto – minori consumi. Per contro, mentre l’uso delle cache è completamente trasparente al programmatore, le SPM devono essere esplicitamente gestite dall’applicazione. Esporre l’organizzazione della gerarchia di memoria ll’applicazione consente di sfruttarne in maniera efficiente i vantaggi (ridotti tempi d’accesso e consumi). Per contro, per ottenere questi benefici è necessario scrivere le applicazioni in maniera tale che i dati vengano partizionati e allocati sulle varie memorie in maniera opportuna. L’onere di questo compito complesso ricade ovviamente sul programmatore. Questo scenario descrive bene l’esigenza di modelli di programmazione e strumenti di supporto che semplifichino lo sviluppo di applicazioni parallele. In questa tesi viene presentato un framework per lo sviluppo di software per MPSoC embedded basato su OpenMP. OpenMP è uno standard di fatto per la programmazione di multiprocessori con memoria shared, caratterizzato da un semplice approccio alla parallelizzazione tramite annotazioni (direttive per il compilatore). La sua interfaccia di programmazione consente di esprimere in maniera naturale e molto efficiente il parallelismo a livello di loop, molto diffuso tra le applicazioni embedded di tipo signal processing e multimedia. OpenMP costituisce un ottimo punto di partenza per la definizione di un modello di programmazione per MPSoC, soprattutto per la sua semplicità d’uso. D’altra parte, per sfruttare in maniera efficiente il potenziale computazionale di un MPSoC è necessario rivisitare profondamente l’implementazione del supporto OpenMP sia nel compilatore che nell’ambiente di supporto a runtime. Tutti i costrutti per gestire il parallelismo, la suddivisione del lavoro e la sincronizzazione inter-processore comportano un costo in termini di overhead che deve essere minimizzato per non comprometterre i vantaggi della parallelizzazione. Questo può essere ottenuto soltanto tramite una accurata analisi delle caratteristiche hardware e l’individuazione dei potenziali colli di bottiglia nell’architettura. Una implementazione del task management, della sincronizzazione a barriera e della condivisione dei dati che sfrutti efficientemente le risorse hardware consente di ottenere elevate performance e scalabilità. La condivisione dei dati, nel modello OpenMP, merita particolare attenzione. In un modello a memoria condivisa le strutture dati (array, matrici) accedute dal programma sono fisicamente allocate su una unica risorsa di memoria raggiungibile da tutti i processori. Al crescere del numero di processori in un sistema, l’accesso concorrente ad una singola risorsa di memoria costituisce un evidente collo di bottiglia. Per alleviare la pressione sulle memorie e sul sistema di connessione vengono da noi studiate e proposte delle tecniche di partizionamento delle strutture dati. Queste tecniche richiedono che una singola entità di tipo array venga trattata nel programma come l’insieme di tanti sotto-array, ciascuno dei quali può essere fisicamente allocato su una risorsa di memoria differente. Dal punto di vista del programma, indirizzare un array partizionato richiede che ad ogni accesso vengano eseguite delle istruzioni per ri-calcolare l’indirizzo fisico di destinazione. Questo è chiaramente un compito lungo, complesso e soggetto ad errori. Per questo motivo, le nostre tecniche di partizionamento sono state integrate nella l’interfaccia di programmazione di OpenMP, che è stata significativamente estesa. Specificamente, delle nuove direttive e clausole consentono al programmatore di annotare i dati di tipo array che si vuole partizionare e allocare in maniera distribuita sulla gerarchia di memoria. Sono stati inoltre sviluppati degli strumenti di supporto che consentono di raccogliere informazioni di profiling sul pattern di accesso agli array. Queste informazioni vengono sfruttate dal nostro compilatore per allocare le partizioni sulle varie risorse di memoria rispettando una relazione di affinità tra il task e i dati. Più precisamente, i passi di allocazione nel nostro compilatore assegnano una determinata partizione alla memoria scratchpad locale al processore che ospita il task che effettua il numero maggiore di accessi alla stessa.

Ottimizzazione delle performance del framework biolabicaocheck

I documenti cartacei vengono attualmente rimpiazzati dalle loro versioni elettroniche, che contengono anche alcune caratteristiche biometriche; questo ha permesso il controllo automatico, sia quando il documento viene rilasciato, sia quando l'identità della persona deve essere verificata. Per rendere questo possibile è necessario che la fotografia rispetti degli standard di qualità. Lo standard ISO/IEC 19794-5 fornisce alcune guide linea ed esempi di immagini di volto accettabili e non-accettabili. Negli ultimi anni, molte aziende hanno sviluppato SDK con lo scopo di implementare i test proposti dallo standard. La tesi si prefigura il compito di fornire un framework che fornisca buone prestazioni, sia per quanto riguarda i tempi sia per l'accuratezza dei risultati.

Firmware development and testing for L1/L2 IBL upgrade

Il lavoro di questa tesi riguarda principalmente l'upgrade, la simulazione e il test di schede VME chiamate ReadOut Driver (ROD), che sono parte della catena di elaborazione ed acquisizione dati di IBL (Insertable B-Layer). IBL è il nuovo componente del Pixel Detector dell'esperimento ATLAS al Cern che è stato inserito nel detector durante lo shut down di LHC; fino al 2012 infatti il Pixel Detector era costituito da tre layer, chiamati (partendo dal più interno): Barrel Layer 0, Layer 1 e Layer 2. Tuttavia, l'aumento di luminosità di LHC, l'invecchiamento dei pixel e la richiesta di avere misure sempre più precise, portarono alla necessità di migliorare il rivelatore. Così, a partire dall'inizio del 2013, IBL (che fino a quel momento era stato un progetto sviluppato e finanziato separatamente dal Pixel Detector) è diventato parte del Pixel Detector di ATLAS ed è stato installato tra la beam-pipe e il layer B0. Questa tesi fornirà innanzitutto una panoramica generale dell'esperimento ATLAS al CERN, includendo aspetti sia fisici sia tecnici, poi tratterà in dettaglio le varie parti del rivelatore, con particolare attenzione su Insertable B-Layer. Su quest'ultimo punto la tesi si focalizzerà sui motivi che ne hanno portato alla costruzione, sugli aspetti di design, sulle tecnologie utilizzate (volte a rendere nel miglior modo possibile compatibili IBL e il resto del Pixel Detector) e sulle scelte di sviluppo e fabbricazione. La tesi tratterà poi la catena di read-out dei dati, descrivendo le tecniche di interfacciamento con i chip di front-end, ed in particolare si concentrerà sul lavoro svolto per l'upgrade e lo sviluppo delle schede ReadOut Drivers (ROD) introducendo le migliorie da me apportate, volte a eliminare eventuali difetti, migliorare le prestazioni ed a predisporre il sistema ad una analisi prestazionale del rivelatore. Allo stato attuale le schede sono state prodotte e montate e sono già parte del sistema di acquisizione dati del Pixel Detector di ATLAS, ma il firmware è in continuo aggiornamento. Il mio lavoro si è principalmente focalizzato sul debugging e il miglioramento delle schede ROD; in particolare ho aggiunto due features: - programmazione parallela delle FPGA} delle ROD via VME. IBL richiede l'utilizzo di 15 schede ROD e programmandole tutte insieme (invece che una alla volta) porta ad un sensibile guadagno nei tempi di programmazione. Questo è utile soprattutto in fase di test; - reset del Phase-Locked Loop (PLL)} tramite VME. Il PLL è un chip presente nelle ROD che distribuisce il clock a tutte le componenti della scheda. Avere la possibilità di resettare questo chip da remoto permette di risolvere problemi di sincronizzazione. Le ReadOut Driver saranno inoltre utilizzate da più layer del Pixel Detector. Infatti oltre ad IBL anche i dati provenienti dai layer 1 e 2 dei sensori a pixel dell’esperimento ATLAS verranno acquisiti sfruttando la catena hardware progettata, realizzata e testata a Bologna.

Chapel: analisi delle prestazioni su architetture a memoria distribuita

Nel presente elaborato si analizzeranno le prestazioni del linguaggio di programmazione parallela Chapel sul kernel Integer Sort di NAS Parallel Benchmarks. Questo algoritmo, a livello pratico, è utilizzato per studi o applicazioni sui metodi particellari. Saranno introdotti i concetti fondamentali di programmazione parallela e successivamente illustrate le principali caratteristiche di MPI e Chapel. Verranno poi approfonditi Integer Sort e i rispettivi dettagli implementativi, concludendo con un'analisi di prestazioni dei due linguaggi sul kernel preso in esame.

Moving object detection strategy for augmented-reality applications in a GPGPU by using CUDA

A spatial-color-based non-parametric background-foreground modeling strategy in a GPGPU by using CUDA is proposed. This strategy is suitable for augmented-reality applications, providing real-time high-quality results in a great variety of scenarios.

Geometry based visualization with OpenCL

Dissertação para obtenção do Grau de Mestre em Engenharia Informática

Estudi GPGPU dedicat al processament de neuroimatges

La tecnologia GPGPU permet paral∙lelitzar càlculs executant operacions aritmètiques en els múltiples processadors de que disposen els xips gràfics. S'ha fet servir l'entorn de desenvolupament CUDA de la companyia NVIDIA, que actualment és la solució GPGPU més avançada del mercat. L'algorisme de neuroimatge implementat pertany a un estudi VBM desenvolupat amb l'eina SPM. Es tracta concretament del procés de segmentació d'imatges de ressonància magnètica cerebrals, en els diferents teixits dels quals es composa el cervell: matèria blanca, matèria grisa i líquid cefaloraquidi. S'han implementat models en els llenguatges Matlab, C i CUDA, i s'ha fet un estudi comparatiu per plataformes hardware diferents.

ReacTIVision en CUDA : aprovechando las capacidades de la computación paralela en GPU

En aquest projecte final de carrera es decriurà el procés realitzat per tal d'aconseguir que l'aplicació reacTICision aprofiti les capacitats de la computació paral·lela en GPU mitjançant la tecnologia CUDA de NVIDIA. Amb aquest objectiu es realitzarà un estudi de la tecnologia CUDA i el funcionament de reacTIVision així com un anàlisi dels resultats obtinguts

Técnicas de paralelização em GPGPU aplicadas em algoritmo para remoção de ruído multiplicativo

Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES)

Paralelização de algoritmos de trimap utilizando a arquitetura Cuda

Techniques of image combination, with extraction of objects to set a final scene, are very used in applications from photos montages to cinematographic productions. These techniques are called digital matting. With them is possible to decrease the cost of productions, because it is not necessary for the actor to be filmed in the location where the final scene occurs. This feature also favors its use in programs made to digital television, which demands a high quality image. Many digital matting algorithms use markings done on the images, to demarcate what is the foreground, the background and the uncertainty areas. This marking is called trimap, which is a triple map containing these three informations. The trimap is done, typically, from manual markings. In this project, methods were created that can be used in digital matting algorithms, with restriction of time and without human interaction, that is, the creation of an algorithm that generates the trimap automatically. This last one can be generated from the difference between a color of an arbitrary background and the foreground, or by using a depth map. It was also created a matting method, based on the Geodesic Matting (BAI; SAPIRO, 2009), which has an inferior processing time then the original one. Aiming to improve the performance of the applications that generates the trimap and of the algorithms that generates the alphamap (map that associates a value to the transparency of each pixel of the image), allowing its use in applications with time restrictions, it was used the CUDA architecture. Taking advantage, this way, of the computational power and the features of the GPGPU, which is massively parallel