OpenCL nel Trading - pagina 3

[MetaQuotes]

AMD Developer Central: OpenCL Programming Webinar Series.2. Introduzione a OpenCL

2- Introduzione a OpenCL

Questo video fornisce un'introduzione dettagliata a OpenCL, una piattaforma per il calcolo parallelo che può utilizzare CPU e GPU per accelerare i calcoli. I programmi scritti in OpenCL possono essere eseguiti su diversi dispositivi e architetture, consentendo la portabilità del codice su piattaforme diverse. Il video discute i diversi modelli di esecuzione in OpenCL, incluso il parallelismo dei dati e il parallelismo delle attività, e copre anche i diversi oggetti e comandi utilizzati in OpenCL, come oggetti di memoria, code di comandi e oggetti del kernel. Il video approfondisce anche i vantaggi e le limitazioni dell'utilizzo di OpenCL, come la necessità di una gestione esplicita della memoria e il potenziale per significativi miglioramenti delle prestazioni nei programmi paralleli.

• 00:00:00 In questa sezione, il relatore introduce OpenCL e la sua capacità di utilizzare CPU e GPU per accelerare i calcoli paralleli con conseguenti significativi aumenti di velocità. Anche se a volte vengono citati numeri come 100X o 1000X, realisticamente, per i programmi ottimizzati sono previste accelerazioni di circa 10-20X. OpenCL può scrivere codice portatile su diversi dispositivi e architetture; pertanto, i programmi scritti per GPU AMD possono in genere essere eseguiti anche su GPU NVIDIA. Con l'implementazione AMD, vengono fornite sia l'implementazione CPU che GPU di OpenCL, a differenza di alcune delle implementazioni di altri concorrenti. La sezione si conclude con una panoramica dell'elaborazione eterogenea e di come OpenCL vi si inserisce.
  
  
• 00:05:00 In questa sezione, il relatore fornisce un'introduzione a OpenCL, che è una piattaforma di basso livello e prolissa che può essere gratificante in termini di prestazioni se l'applicazione ha le caratteristiche giuste. OpenCL è un modello basato su piattaforma costituito da un'API host, un modello di dispositivi connessi e un modello di memoria. I dispositivi sono visti come una raccolta di unità di calcolo e ogni unità di calcolo è suddivisa in elementi di elaborazione che vengono eseguiti in SIMD. Il modello di esecuzione si basa sulla nozione di kernel, che è l'unità di codice eseguibile che può essere eseguita in parallelo su più dati. Inoltre, OpenCL fornisce una serie di code che consentono l'esecuzione asincrona di operazioni di lettura e scrittura e l'esecuzione del kernel, che possono essere in ordine o fuori ordine.
  
  
• 00:10:00 In questa sezione, il relatore discute i due principali modelli di esecuzione in OpenCL: il parallelismo dei dati e il parallelismo delle attività. Il modello parallelo di dati è il più efficiente per l'esecuzione su GPU e coinvolge un dominio di calcolo N dimensionale in cui ogni singolo elemento è chiamato elemento di lavoro che può potenzialmente essere eseguito in parallelo. L'esecuzione degli elementi di lavoro può essere raggruppata in dimensioni locali denominate gruppi di lavoro che vengono eseguite su una delle unità di calcolo disponibili. Il relatore spiega anche come il ciclo sia implicito nel mondo parallelo dei dati di OpenCL e come venga utilizzata la routine get global identifier per indicizzare in a e b.
  
  
• 00:15:00 In questa sezione, il relatore discute la memoria locale, che è simile a una cache ed è gestita dall'utente, essendo a bassa latenza e più veloce della memoria globale. La funzione di sincronizzazione consente agli elementi di lavoro di scrivere in una posizione di memoria, attendere il completamento e quindi fare in modo che un altro elemento di lavoro legga tale posizione di memoria e ottenga il valore scritto dall'elemento di lavoro precedente. La sincronizzazione può essere eseguita solo all'interno del gruppo di lavoro. OpenCL supporta anche il parallelismo delle attività, eseguito da un singolo elemento di lavoro, e beneficia dell'utilizzo del modello di accodamento OpenCL e delle funzionalità di sincronizzazione dell'API host, consentendo il codice compilato in modo nativo. OpenCL differisce da C in quanto la gerarchia di memoria di particolari GPU è esplicitamente esposta e il programmatore può indurre un ordinamento e una coerenza dei dati attraverso l'uso di operazioni di barriera e sincronizzazione.
  
  
• 00:20:00 In questa sezione, il relatore discute i vantaggi di OpenCL, come le sue potenti capacità prestazionali. Tuttavia, sottolineano che la gestione della memoria in OpenCL richiede operazioni esplicite, che potrebbero essere complicate e richiedono un'attenta considerazione dell'algoritmo. Il modello di compilazione è basato su OpenGL e dispone di un modello di compilazione online che consente di passare flussi o stringhe di codice sorgente OpenCL per la compilazione online. OpenCL è costruito attorno al contesto, una raccolta di dispositivi e oggetti di memoria e le code vengono utilizzate per inviare il lavoro a un particolare dispositivo associato al contesto. Gli oggetti di memoria sono buffer, ovvero blocchi di memoria unidimensionali che possono essere considerati come matrici.
  
  
• 00:25:00 In questa sezione, il relatore spiega i diversi oggetti OpenCL, inclusi oggetti di memoria, immagini, programmi e kernel. Gli oggetti di memoria possono essere buffer o tipi di immagine, in cui le immagini hanno un'implementazione hardware per ottimizzare l'accesso. I programmi che definiscono i kernel per l'esecuzione possono essere compilati ed estratti e i valori degli argomenti del kernel possono essere impostati utilizzando gli oggetti del kernel. Le code di comando vengono utilizzate per accodare i kernel e altri comandi per l'esecuzione. Inoltre, gli eventi OpenCL sono utili per creare dipendenze tra i comandi e interrogare lo stato dei comandi. L'oratore fornisce anche esempi su come interrogare i dispositivi e i loro ID.
  
  
• 00:30:00 In questa sezione, il relatore spiega come OpenCL restituisce codici di errore e oggetti. Se una funzione restituisce un oggetto CL, restituirà quell'oggetto come risultato. Ma se non restituisce un oggetto CL, restituirà il codice di errore come risultato. Viene discusso il contesto e il modo in cui la memoria viene allocata a livello di contesto, il che significa che i buffer e le immagini vengono condivisi tra i dispositivi. L'oratore menziona anche la funzione CL get X info, in particolare CL get device info, che consente agli sviluppatori di interrogare le capacità del dispositivo per determinare quale dispositivo è più adatto per l'algoritmo. Infine, il relatore discute i buffer e le immagini e come i kernel possono accedervi, insieme alle restrizioni sull'accesso alle immagini.
  
  
• 00:35:00 In questa sezione, il relatore discute come allocare buffer e immagini in OpenCL, incluso come descrivere come sarà possibile accedere ai buffer e i vantaggi dell'utilizzo delle immagini. Il relatore spiega anche come accedere ai dati degli oggetti di memoria utilizzando comandi espliciti e come mettere in coda i comandi in una coda. Inoltre, il video spiega come mappare una regione e trasferire i dati tra i buffer, nonché i vantaggi e gli svantaggi dell'utilizzo delle unità DMA. La sezione si conclude discutendo gli oggetti del programma e del kernel e impostando i valori degli argomenti.
  
  
• 00:40:00 In questa sezione, l'oratore discute l'invio e le dipendenze in OpenCL. Spiegano come verrà eseguito l'invio in base al dominio o alla griglia di esecuzione e come possono essere impostate le dipendenze per garantire che le cose non si sovrappongano. Il relatore spiega anche gli argomenti per il comando NQ, che tengono conto del numero di eventi nella lista di attesa e dell'evento associato al comando. Infine, il relatore fornisce una panoramica del linguaggio OpenCL C, che è basato su C e presenta alcune restrizioni e aggiunte, come i tipi vettoriali e le primitive di sincronizzazione. Il linguaggio consente elementi di lavoro e gruppi di lavoro, nonché qualificatori dello spazio degli indirizzi e funzioni integrate.
  
  
• 00:45:00 In questa sezione, il relatore offre una breve panoramica di OpenCL e delle sue caratteristiche, come i diversi spazi di indirizzi, tipi vettoriali e tipi scalari che possono essere utilizzati nella programmazione dei kernel. Discutono anche su come creare oggetti di memoria e costruire ed eseguire programmi utilizzando l'API OpenCL. Il relatore affronta quindi una domanda su come il parallelismo dei dati in OpenCL differisca dallo srotolamento dei loop nei compilatori.
  
  
• 00:50:00 In questa sezione, il relatore spiega il concetto di esecuzione parallela dei dati e le difficoltà dei componenti nel farlo in modo efficiente. Sottolinea inoltre la necessità di parallelizzare esplicitamente i programmi per OpenCL o qualsiasi altro modello. L'inq_marker è un altro argomento trattato e come è utile nei segnali fuori servizio. L'oratore ribadisce che la memoria costante significa che i valori sono costanti e viene utilizzata su GPU speciali per caricarsi in una memoria costante molto veloce, che è di sola lettura. Suggerisce di dare un'occhiata a OpenCL Zone sul sito Web di MD per ulteriori informazioni su OpenCL e sulla programmazione parallela. Infine, parla di come get_global_ID(0) restituirebbe lo stesso valore per ogni chiamata del kernel.
  
  
• 00:55:00 In questa sezione, l'oratore spiega che quando due diverse applicazioni sono entrambe in esecuzione e tentano di utilizzare OpenCL sulla stessa macchina, tutte le implementazioni odierne condivideranno l'hardware e il sistema operativo eseguirà il multiplexing delle applicazioni. Raccomandano di utilizzare i profiler visivi per OpenCL, come il plug-in di Visual Studio o la versione della riga di comando di Linux, che consentono di interrogare informazioni sull'id Hardware. L'overhead del caricamento dei dati nell'oggetto immagine o nel buffer dipenderebbe dal dispositivo, dove il trasferimento attraverso il bus PCIe avrebbe una latenza maggiore. Infine, il relatore ha affermato che la nuova serie AMD 680 cento GPU e le migliori pratiche di programmazione per loro sono simili all'architettura Evergreen, su cui si basano.

[MetaQuotes]

AMD Developer Central: serie di webinar sulla programmazione OpenCL. 3. Architettura GPU

3 - Architettura GPU

Questo video offre una panoramica dell'architettura delle GPU, prendendo nota delle origini e dell'uso principale delle GPU come processori grafici. Le GPU sono progettate per l'elaborazione di pixel con un elevato grado di parallelismo, a differenza delle CPU progettate per l'elaborazione scalare con pipeline a bassa latenza. L'architettura delle GPU è ottimizzata per attività specifiche per la grafica, che potrebbero non essere adatte per il calcolo generico. Il relatore spiega come la GPU massimizza il throughput di un insieme di thread anziché ridurre al minimo la latenza di esecuzione di un singolo thread. Viene discussa anche l'architettura del blocco motore GPU, comprese le condivisioni di dati locali, i fronti d'onda e i gruppi di lavoro. Il video esplora varie funzionalità dell'architettura GPU che aiutano ad aumentare la quantità di pacchettizzazione che il compilatore può eseguire, tra cui l'emissione di operazioni dipendenti in un singolo pacchetto e il supporto di contatori dipendenti con condivisione beta globale. Sebbene i design dei core della GPU e della CPU possano essere simili, i loro carichi di lavoro dovranno convergere affinché abbiano design simili.

In questo video sull'architettura della GPU, il relatore approfondisce il concetto di barriere e la loro funzione. Quando un gruppo di lavoro contiene più fronti d'onda in una GPU, le barriere vengono utilizzate per sincronizzare questi fronti d'onda. Tuttavia, se esiste un solo fronte d'onda di lavoro in un gruppo, le barriere vengono rese prive di significato e saranno ridotte a non operazioni.

• 00:00:00 In questa sezione, i relatori introducono lo scopo del webinar, ovvero fornire una panoramica dell'architettura GPU da una prospettiva diversa rispetto all'approccio tradizionale di descrivere l'architettura o le ottimizzazioni di basso livello. I relatori mirano a contestualizzare l'architettura della GPU discutendone le origini e il caso d'uso principale come processori grafici. Spiegano come le GPU sono progettate per l'elaborazione di pixel con un alto grado di parallelismo, che è diverso dalle CPU progettate per l'elaborazione scalare con pipeline a bassa latenza. I relatori toccano anche come l'architettura delle GPU potrebbe non essere adatta per il calcolo generico a causa dei loro blocchi hardware ottimizzati progettati per accelerare le attività specifiche della grafica.
  
  
• 00:05:00 In questa sezione, apprendiamo l'esecuzione di programmi frammentati che sono indipendenti e si riferiscono a un singolo pixel, scritti in GLSL o HLSL, e come questo modello di programmazione consente un parallelismo efficiente senza analisi di dipendenza o comunicazione tra pixel. L'hardware è progettato per eseguire codice shader su più pixel contemporaneamente, noto come fronte d'onda, ma con il problema del codice a blocchi e dei rami. Il problema sorge quando tutti i rami vanno allo stesso modo, causando un problema, ma l'hardware genera una maschera per garantire che tutti i pixel eseguano la stessa istruzione.
  
  
• 00:10:00 In questa sezione, il relatore discute di come l'esecuzione di Cindy richieda semplicemente istruzioni e l'uso di istruzioni vettoriali. Sebbene le istruzioni vettoriali possano essere generate dall'hardware o da un compilatore, possono rendere lo sviluppo complicato e difficile a causa della necessità di impacchettare manualmente diverse operazioni, mascherare i rami e un'attenta codifica manuale. D'altra parte, programmare l'esecuzione di Cindy utilizzando istruzioni vettoriali rischia di far pensare allo sviluppatore che le corsie si diramano in modo indipendente, il che non è vero. Nonostante ciò, è ancora più facile per i programmatori pensare e per le attuali GPU AMD, il mascheramento è controllato dall'hardware. Questo è importante da considerare per il calcolo, che è lo scopo del discorso, in quanto può influire sulle prestazioni, in particolare con la divergenza dei rami nella più ampia Waveland.
  
  
• 00:15:00 In questa sezione, il relatore discute gli aspetti visibili delle architetture GPU basate sul throughput computing, il che significa che se un vettore di istruzioni si blocca in una GPU, cosa che può accadere se l'aggiunta in virgola mobile richiede alcuni cicli per completa, la stessa istruzione può essere utilizzata per coprire il tempo di stallo nel vettore successivo, rendendo più efficiente la decodifica delle istruzioni. L'oratore spiega che invece di aumentare la larghezza del vettore che può ridurre l'utilizzo delle ALU, più fronti d'onda possono intrufolarsi nelle istruzioni da altri thread in esecuzione, dando la probabilità di non bloccarsi semplicemente mentre aspettano che le unità di trama restituiscano i dati della memoria. Tuttavia, un singolo fronte d'onda richiede più tempo per essere eseguito in questo modo a causa del funzionamento dell'architettura.
  
  
• 00:20:00 In questa sezione, il video spiega come la GPU massimizza il throughput di un insieme di thread anziché ridurre al minimo la latenza di esecuzione di un singolo thread. Ciò significa che la GPU tenta di aumentare l'utilizzo dei thread attendendo che il primo thread completi l'esecuzione e quindi alimentando il fronte d'onda successivo, mentre i risultati del primo set di pixel vengono riutilizzati per mantenere la pipeline il più vicino possibile alla piena occupazione . La GPU mantiene un ampio pool di registri per coprire l'intera larghezza del vettore per ogni thread in volo, occupando spazio sul dispositivo, che scala con il numero di stati e la larghezza del vettore. La GPU è progettata per coprire la latenza, e quindi invece di minimizzare la latenza, la GPU massimizza la larghezza di banda della memoria disponibile in modo da poter soddisfare tutto il parallelismo, utilizzando le texture cache e la memoria locale per il riutilizzo dei dati tra gli elementi di lavoro.
  
  
• 00:25:00 In questa sezione, il relatore spiega come le cache e le regioni di memoria condivisa controllate dal programma possono ottenere una riduzione del trasferimento dei dati consentendo ai dati di essere copiati una sola volta dall'interfaccia di memoria principale e quindi riutilizzati da diversi elementi di lavoro in percorsi diversi. Spiegano come la cache delle texture sia progettata per imporre automaticamente la struttura 2D sui suoi dati in modo efficiente per catturare gli accessi 2D da parte dei quad. Le aree dati locali offrono un controllo notevolmente maggiore, ma è responsabilità dello sviluppatore strutturare i carichi in modo efficiente per usare questa memoria e condividere i dati per ridurre i requisiti di memoria globale. La sezione esplora anche il modo in cui la GPU può essere vista come una raccolta di core Cindy cablati con più stati di programma che intercalano 4, 8 o 16 thread per coprire la latenza della pipeline. Viene discusso il compromesso tra il numero di core e la densità ALU, con il vantaggio di aumentare l'utilizzo, a seconda del carico di lavoro.
  
  
• 00:30:00 In questa sezione, il relatore discute le somiglianze e le differenze tra i progetti core di CPU e GPU, utilizzando esempi come Andy Phenom 2 X6 6 e Intel i7. Mentre l'approccio adottato da Pentium 4 e ultraSPARC T2 prevedeva core di dimensioni maggiori con set di stati multipli per aumentare il parallelismo a livello di istruzione, le GPU si trovano all'estremità dello spettro con un alto grado di bilanciamento dei dati. Vengono discussi anche i dettagli tecnici di AMD Radeon HD 5870, sottolineando la sua elevata larghezza di banda e il numero di forme d'onda simultanee disponibili che dipendono dal numero di registri utilizzati da ciascun fronte d'onda. Il relatore conclude che mentre potrebbero esserci somiglianze nello spazio di progettazione tra CPU e GPU nove, i loro carichi di lavoro dovranno convergere affinché abbiano progetti simili.
  
  
• 00:35:00 In questa sezione, apprendiamo gli elementi di progettazione della GPU, comprese le condivisioni di dati locali, i fronti d'onda e i gruppi di lavoro in cui è suddivisa. Il design della GPU include un processore di comando di spedizione del colonnello che genera fronti d'onda, che vengono assegnati a un'unità SIMD disponibile che dispone di risorse sufficienti per adattarsi allo spazio. L'intero chip ha 20 motori Cindy con 8 banchi di memoria GDDR5 per crossbar e cache. Inoltre, presenta un modello di coerenza della memoria globale rilassato, che richiede istruzioni di recinzione per garantire i diritti di visibilità, consentendo ai motori Cindy e alle unità fisse di mantenere un elevato grado di esecuzione parallela dei dati il più possibile senza il sovraccarico delle prestazioni energetiche. La GPU utilizza un modello di esecuzione basato su clausole, che le consente di eseguire molti programmi di flusso di controllo contemporaneamente sul motore più semplice.
  
  
• 00:40:00 In questa sezione viene discussa l'architettura del blocco motore GPU. Il blocco del motore ha due componenti principali: la condivisione dei dati locali, che consente la condivisione dei dati tra gli elementi di lavoro in un gruppo di lavoro e gli elementi post-test, o gli stream core, che eseguono le istruzioni dalle clausole ALU nel kernel. La condivisione dati locale ha 32 banchi, ciascuno dei 16 elementi di elaborazione nel motore può richiedere di leggere o scrivere parole a 32 bit da LDS su ogni ciclo a indirizzi arbitrari e i conflitti vengono rilevati dall'unità. Le operazioni atomiche vengono eseguite utilizzando ALU solo interi e le atomiche in virgola mobile sarebbero più complicate da eseguire. L'elemento di elaborazione dell'architettura 5870 è un cluster di cinque ALU identiche che operano su un pacchetto di parole di istruzioni molto lungo di cinque operazioni impacchettate dal compilatore, con un insieme di dipendenze proprie e la maggior parte delle operazioni di base possono essere eseguite.
  
  
• 00:45:00 In questa sezione, il relatore descrive varie caratteristiche dell'architettura GPU che aiutano ad aumentare la quantità di compressione che il compilatore può eseguire, tra cui l'emissione di operazioni dipendenti in un singolo pacchetto e il supporto di contatori dipendenti con condivisione beta globale. La condivisione beta globale è una funzionalità meno nota che è collegata all'intero set di motori di calcolo sul dispositivo e ha una latenza molto inferiore rispetto all'accesso ad altre memorie. L'oratore avverte inoltre che l'accesso a pixel casuali nella cache delle texture può causare problemi di prestazioni, poiché sarà più veloce rispetto agli accessi alla memoria globale solo se i dati sono raggruppati insieme.
  
  
• 00:50:00 In questa sezione, il relatore risponde alle domande relative al raggiungimento della piena occupazione nell'architettura GPU. L'esempio fornito è che i gruppi di lavoro dovrebbero essere costituiti da multipli di 64 elementi di lavoro per ottenere la piena occupazione. Anche i fronti d'onda e il numero di fronti d'onda che possono adattarsi a ciascun core influiscono sulla piena occupazione. L'oratore menziona anche che non ci sono versioni a piena precisione delle funzioni trascendentali generate dalla 5th Lane che sono approssimazioni veloci che possono o meno essere abbastanza buone, a seconda delle esigenze del codice. Alla domanda se esiste un modo per interrogare la dimensione del fronte d'onda all'interno di tutti i dispositivi, la risposta è che non esiste tale modo.
  
  
• 00:55:00 In questa sezione, il relatore spiega cosa significa "coalescenza completa" in termini di accessi alla memoria globale in un'architettura GPU. In sostanza, significa che un fronte a quarto d'onda emetterà una richiesta di memoria in cui ciascuna corsia accederà a 128 bit consecutivamente da indirizzi allineati che attraversano l'unità di calcolo. Tuttavia, esistono livelli di efficienza a seconda del tipo di accesso, se è collegato o scollegato e se si tratta di una raccolta casuale. Il relatore chiarisce inoltre che un fronte d'onda è un'unità di lavoro composta da 64 elementi di lavoro eseguiti insieme a una singola istruzione, e non è la stessa cosa di un gruppo di lavoro, che è un insieme di elementi di lavoro.
  
  
• 01:00:00 In questa sezione, il relatore spiega il concetto di barriere nell'architettura delle GPU. Se un gruppo di lavoro ha più fronti d'onda, l'emissione di un'istruzione barriera sincronizzerà questi fronti d'onda. Tuttavia, se c'è un solo fronte d'onda di lavoro in un gruppo, le barriere saranno ridotte a non operazioni e non avranno alcun significato.

[MetaQuotes]

AMD Developer Central: serie di webinar sulla programmazione OpenCL. 4 Programmazione OpenCL in dettaglio

4 - Programmazione OpenCL in dettaglio

In questo video, il relatore fornisce una panoramica della programmazione OpenCL, discutendone il linguaggio, la piattaforma e le API di runtime. Elaborano il modello di programmazione che richiede parallelizzazione a grana fine, elementi di lavoro e gruppi o thread, sincronizzazione e gestione della memoria. L'oratore discute quindi l'algoritmo n-body e la sua natura di ordine computazionale n-quadrato. Spiegano come il codice del kernel OpenCL aggiorna la posizione e la velocità delle particelle nella meccanica newtoniana, introduce la cache per memorizzare la posizione di una particella e come il kernel aggiorna la posizione e la velocità delle particelle utilizzando tipi di dati vettoriali float. Il relatore approfondisce anche il modo in cui il codice host interagisce con i kernel OpenCL impostando i parametri e gli argomenti in modo esplicito, trasferendo i dati tra l'host e la GPU e accodando l'esecuzione del kernel per la sincronizzazione. Infine, il video esplora come modificare il codice OpenCL per supportare più dispositivi, sincronizzare i dati tra le GPU e impostare gli ID dei dispositivi per array di dimensioni ridotte che li rappresentano.

La seconda parte discute vari aspetti della programmazione OpenCL. Copre argomenti come lo schema a doppio buffer per sincronizzare la posizione aggiornata delle particelle tra due array, le limitazioni OpenCL e la differenza tra puntatori globali e locali nell'allocazione della memoria. Inoltre, evidenzia le tecniche di ottimizzazione per la programmazione OpenCL, comprese le operazioni vettoriali, l'accesso controllato alla memoria e lo srotolamento dei loop, insieme agli strumenti disponibili per l'analisi dell'implementazione OpenCL, come gli strumenti di profilazione. Il relatore consiglia lo standard OpenCL come risorsa per i programmatori OpenCL e fornisce gli URL per lo standard e l'ATI Stream SDK. Il video affronta anche domande su argomenti come la condivisione della memoria, l'ottimizzazione del codice, l'allocazione della memoria e l'utilizzo delle unità di calcolo.

• 00:00:00 In questa sezione, il relatore introduce i concetti di OpenCL, discutendo l'emergere di architetture CPU-GPU ibride e le sfide che pongono per la programmazione. OpenCL fornisce un'API indipendente dalla piattaforma e dal dispositivo con supporto a livello di settore e il relatore delinea le tre parti dell'API OpenCL: la specifica del linguaggio, l'API della piattaforma e l'API di runtime. Il modello di esecuzione è suddiviso in due parti: il kernel, che rappresenta il codice eseguibile che verrà eseguito sul dispositivo OpenCL, e il programma host, che esegue la gestione della memoria e gestisce l'esecuzione del kernel su uno o più dispositivi utilizzando la coda dei comandi. L'estensione del linguaggio C utilizzata per la programmazione del kernel è basata su ISO C99 con alcune restrizioni e aggiunte per supportare il parallelismo.
  
  
• 00:05:00 In questa sezione, il relatore spiega il modello di programmazione di OpenCL, che richiede parallelizzazione a grana fine tra thread e sincronizzazione. Gli elementi di lavoro ei gruppi di lavoro vengono presentati come thread e raggruppati in gruppi di lavoro che hanno proprietà speciali in termini di sincronizzazione e accesso alla memoria condivisa. Il relatore copre anche il modello di esecuzione sul lato host, spiegando che tutto è raccolto in un contesto che include una raccolta di dispositivi, oggetti di programma, kernel, oggetti di memoria e la coda dei comandi per mettere in coda kernel e operazioni di memoria o trasferimento dati . OpenCL supporta anche una gerarchia di diversi tipi di memoria per riflettere la natura della memoria in un sistema ibrido con memoria distribuita.
  
  
• 00:10:00 In questa sezione, il relatore discute l'importanza della gestione della memoria e della sincronizzazione quando si utilizza la programmazione OpenCL. OpenCL ha un modello di coerenza della memoria rilassato, che rende responsabilità del programmatore gestire i trasferimenti di dati e controllare quando i dati vengono spostati da un dispositivo a un altro. La sincronizzazione diventa essenziale quando si utilizzano più dispositivi ed è responsabilità del programmatore assicurarsi che gli eventi, inclusa l'esecuzione del kernel e il trasferimento dei dati, siano sincronizzati correttamente. Il relatore introduce l'uso di Standard CL, che è un'interfaccia semplificata per OpenCL e fornisce un contesto predefinito che è pronto per l'uso, include tutti i dispositivi ed è ininterrotto dalla piena funzionalità OpenCL. Inoltre, Standard CL semplifica la gestione della memoria tramite CL Maylock, che alloca memoria condivisibile tra i dispositivi OpenCL.
  
  
• 00:15:00 In questa sezione, il relatore discute l'algoritmo di base n-body, che modella il moto di nparticelle soggette a qualche forma di interazione particella-particella. L'algoritmo prevede il calcolo della forza su ciascuna particella sommando i contributi dell'interazione con tutte le altre particelle nel sistema. Una volta che la forza su ogni particella è nota, la posizione e la velocità delle particelle vengono aggiornate in un piccolo intervallo di tempo. Questo processo viene ripetuto per ogni particella, risultando in una simulazione di queste particelle che si muovono soggette alle forze di interazione. L'algoritmo è di ordine computazionale n-quadrato, che consente una buona velocità utilizzando coprocessori con limitazioni nella larghezza di banda di trasferimento della memoria. L'intero algoritmo può essere scritto in poche decine di righe di codice in C.
  
  
• 00:20:00 In questa sezione, il relatore spiega l'implementazione dell'algoritmo n-body attraverso un ciclo che accumula l'interazione tra le particelle. Il codice del kernel è progettato per fornire un'implementazione ragionevolmente standard utilizzando buone pratiche da una prospettiva OpenCL, ma potrebbe non essere ottimale per una particolare architettura. Il kernel verrà eseguito per ogni elemento di lavoro all'interno di uno spazio indice, in cui ogni thread è responsabile dell'aggiornamento della posizione e della velocità di una singola particella. L'applicazione ha una semplice base di indice unidimensionale con il numero di elementi di lavoro uguale al numero di particelle nel sistema. Il codice host è essenziale anche per l'inizializzazione, la gestione della memoria e il coordinamento delle operazioni sui dispositivi OpenCL.
  
  
• 00:25:00 In questa sezione, il relatore introduce il codice kernel per aggiornare la posizione e la velocità delle particelle nella meccanica newtoniana. Il prototipo per il codice del kernel è simile a quello di una funzione C, ma con alcuni qualificatori che qualificano lo spazio degli indirizzi e l'uso di uno schema di blocco. Il codice del kernel viene archiviato in un file separato e utilizzato nella compilazione just-in-time quando il programma viene eseguito. L'oratore spiega quindi come il codice del kernel esegue la determinazione delle dimensioni e dell'indice prima di entrare nel calcolo effettivo della fisica. Anche gli ID dei thread globali e locali sono spiegati in dettaglio e l'oratore nota che un ciclo esterno è implicito nel codice del kernel poiché il kernel verrà eseguito automaticamente per ogni particella nel sistema.
  
  
• 00:30:00 In questa sezione, il relatore spiega l'implementazione del kernel OpenCL per il calcolo della forza a coppie utilizzando una cache. Il kernel memorizza nella cache una posizione di particella e fa affidamento anche sugli altri elementi di lavoro nel gruppo di lavoro per riempire la cache. Una volta memorizzate nella cache le 64 posizioni delle particelle, il kernel esegue un loop sulle posizioni delle particelle memorizzate nella cache e implementa lo stesso calcolo della forza mostrato nel codice C, con notevoli differenze specifiche di OpenCL. Questi includono l'utilizzo di un vettore float per la posizione delle particelle, una funzione integrata OpenCL per la radice quadrata e la memorizzazione della massa nel quarto componente inutilizzato del vettore float per comodità. Il kernel aggiorna la posizione e la velocità delle particelle su un singolo clock utilizzando il tipo di dati float vector. Infine, il relatore spiega la necessità di barriere per la sincronizzazione durante il riempimento della cache e le operazioni di loop.
  
  
• 00:35:00 In questa sezione impareremo come la nuova posizione e la nuova velocità vengono riscritte nella memoria globale in un nuovo array per evitare di sovrascrivere i dati che sono ancora richiesti da altri thread. Questo schema di doppio buffering viene utilizzato nelle fasi successive per aggiornare in modo sicuro la posizione della particella senza riscontrare problemi di concorrenza dei thread. Passando all'implementazione del codice host del kernel, apprendiamo come il programma imposta i parametri, alloca memoria, inizializza posizioni e velocità, costruisce e compila il kernel OpenCL, interroga per nome il kernel n-body corrente necessario, crea un uno dominio computazionale del kernel dimensionale e imposta esplicitamente gli argomenti del kernel. Nel complesso, il codice mostra come OpenCL differisce dai programmi C di base in quanto l'host esegue il kernel tramite proxy e come gli argomenti per il kernel devono essere impostati direttamente.
  
  
• 00:40:00 In questa sezione, il relatore spiega il processo di trasferimento dei dati dall'host alla GPU utilizzando una clm sink call e la sincronizzazione degli array sul dispositivo (GPU) utilizzando i flag per il blocco delle chiamate. Quindi discutono i passaggi del ciclo, introducendo il valore e il burst che verranno utilizzati per scopi diagnostici e ritardando l'impostazione degli argomenti del kernel due e tre per il doppio buffering. L'oratore osserva che l'esecuzione del kernel è accodata e la chiamata di sincronizzazione di attesa CL viene utilizzata per garantire che tutte le esecuzioni del kernel siano state completate prima di procedere. Infine, riportano i dati dalla GPU all'host utilizzando il buffer di lettura dell'accodamento CL.
  
  
• 00:45:00 In questa sezione, il video discute la modifica del codice per supportare più dispositivi, in particolare l'esecuzione del codice su due GPU. L'approccio prevede la suddivisione del lavoro per il calcolo della forza e l'aggiornamento della posizione delle particelle tra le due GPU, con una GPU responsabile della metà delle particelle. Il codice del kernel vede pochi scambi, con solo un argomento aggiuntivo aggiunto al prototipo chiamato "posizione remota", che punta alle posizioni delle particelle per le particelle che una data GPU non è responsabile dell'aggiornamento, ma necessita comunque per calcolare la forza totale . Ci sono cambiamenti notevoli sul lato host che coinvolgono la gestione della memoria e problemi di sincronizzazione che sorgono a causa dell'uso di due dispositivi.
  
  
• 00:50:00 In questa sezione, la lezione spiega le modifiche che devono essere apportate al codice del kernel per eseguire la simulazione delle particelle su due GPU. Il loop sulle posizioni delle particelle della cache rimane lo stesso di prima, ma prima della riga 21, il loop è ora sulle posizioni delle particelle locali che la GPU possiede. Il codice viene quindi ripetuto per le particelle remote che l'altra GPU è responsabile dell'aggiornamento. Il codice per l'aggiornamento della posizione e della velocità delle particelle rimane lo stesso. Per modificare il codice host per due GPU, l'inizializzazione rimane la stessa, ma vengono assegnati anche gli array per le posizioni e le velocità delle particelle che contengono metà delle particelle, con A e B che rappresentano le due GPU. Viene creato un dominio computazionale con uno spazio indice pari solo alla metà della dimensione originale e viene rimosso il codice per l'impostazione statica del puntatore dell'argomento sull'array di velocità.
  
  
• 00:55:00 In questa sezione impareremo come impostare l'ID del dispositivo per definire su quale GPU verranno scritti i dati durante la copia di array di dimensioni dimezzate nelle rispettive GPU. Vediamo anche che per scambiare dati tra più GPU, dobbiamo sincronizzare le posizioni aggiornate delle particelle con le GPU cambiando gli array di particelle di dimensioni ridotte che le rappresentano. Apprendiamo anche che per alcune implementazioni di OpenCL, potrebbe essere necessario introdurre una chiamata flush CL per una vera concorrenza, ma questo non fa parte dello standard.
  
  
• 01:00:00 In questa sezione, il relatore passa attraverso il codice, che implementa lo schema del doppio buffer per scambiare la vecchia e la nuova posizione delle particelle tra due array. Questo schema garantisce che le posizioni aggiornate delle particelle vengano reinserite nell'array A o B. Una volta che le particelle sono sincronizzate con l'host, devono essere copiate nuovamente nell'array più grande per riutilizzare alcune delle funzioni di supporto. Il relatore consiglia lo standard OpenCL come risorsa necessaria per i programmatori OpenCL e fornisce gli URL per lo standard e l'ATI Stream SDK. Il relatore risponde anche alle domande sulla possibilità di utilizzare OpenCL per algoritmi come la decomposizione del valore singolare o la fattorizzazione della matrice non negativa e conferma che i dati nella memoria globale sulla GPU rimangono gli stessi tra le esecuzioni del kernel, il che è cruciale per algoritmi più complessi.
  
  
• 01:05:00 In questa sezione, il video discute le attuali limitazioni dell'API OpenCL, che supporta solo i sistemi Unix/Linux e su cui si sta lavorando per una porta Windows. Il video affronta anche la questione della condivisione della memoria tra una GPU e l'host, spiegando che sebbene sia possibile, ci sono penalizzazioni prestazionali, rendendo tipico l'utilizzo della memoria globale allocata sulla scheda grafica. Quando si alloca la memoria tramite l'API OpenCL, ci sono modi per controllare come viene gestita, ma alcune di queste operazioni vengono eseguite automaticamente a livello di implementazione. Inoltre, il video spiega la differenza tra puntatori globali e locali nell'allocazione della memoria e come la scelta del numero ottimale di core dipende dall'algoritmo in esecuzione.
  
  
• 01:10:00 In questa sezione, il relatore discute varie questioni relative alla programmazione OpenCL, ad esempio se caricare ed eseguire il modulo FTL FGL RX, la compatibilità di Lib standard CL con collegamenti C++, l'ottimizzazione dei kernel OpenCL per il miglioramento delle prestazioni e l'uso di CL mem in sola lettura o la loro chiusura in lettura/scrittura durante l'allocazione dei buffer di memoria. L'oratore sottolinea inoltre che potrebbero esistere strumenti specifici per la modifica dei kernel OpenCL e l'ottimizzazione per le GPU AMD, notando anche che le tecniche di ottimizzazione possono essere molto sottili e richiedere molta messa a punto.
  
  
• 01:15:00 In questa sezione, il relatore discute le tecniche di ottimizzazione per la programmazione OpenCL, inclusa l'organizzazione dei dati per sfruttare le operazioni vettoriali, il controllo accurato dell'accesso alla memoria per prestazioni migliori e lo srotolamento manuale dei loop per l'ottimizzazione. Inoltre, l'uso di tipi di dati complessi e la possibilità di trasferire dati tra GPU senza tornare all'host sono specifici dell'implementazione e possono variare a seconda del compilatore. Il relatore menziona anche che esistono limiti di dimensione per i buffer di memoria che dipenderanno dalla memoria disponibile tra i dispositivi OpenCL nel sistema. Potrebbe essere possibile memorizzare parametri float più semplici nella memoria costante per prestazioni migliori.
  
  
• 01:20:00 In questa sezione, il relatore spiega che ci sono strumenti disponibili in vari SDK per analizzare l'implementazione di OpenCL, inclusi strumenti di profilazione per misurare l'utilizzo dell'unità di calcolo o l'utilizzo del trasferimento di memoria. Il relatore chiarisce inoltre che la gestione della frammentazione della memoria sul lato GPU è specifica dell'implementazione e che l'implementazione deve gestirla correttamente. Quando si utilizza la doppia precisione, non esiste una risposta ovvia sull'opportunità di ridurre la dimensione del gruppo di lavoro locale a 32 o 16, poiché dipende dall'architettura utilizzata. Il relatore menziona anche la disponibilità di chiamate di supporto per ottenere facilmente informazioni su tutti i dispositivi all'interno del contesto GPU standard.

[MetaQuotes]

AMD Developer Central: serie di webinar sulla programmazione OpenCL. 5. Applicazioni OpenCL del mondo reale

5 - Applicazioni OpenCL del mondo reale

In questo video, Joachim Deguara parla di un'applicazione di elaborazione video multi-stream su cui ha lavorato, con particolare attenzione all'ottimizzazione delle prestazioni. Il video copre vari argomenti come la decodifica dei formati video, l'utilizzo di DMA per trasferire la memoria tra CPU e GPU, il doppio buffering, l'esecuzione di kernel, l'utilizzo di oggetti evento per sincronizzare e profilare le operazioni, l'interoperabilità OpenCL-OpenGL, l'elaborazione degli swipe nei video e la scelta tra OpenCL e OpenGL durante l'elaborazione degli algoritmi. Joachim discute anche di vari campionamenti e SDK disponibili per le applicazioni OpenCL, ma osserva che al momento non è disponibile alcun codice di esempio per l'applicazione specifica discussa nel video.

• 00:00:00 In questa sezione, Joachim Deguara spiega un'applicazione di elaborazione video multi-stream su cui ha lavorato. L'applicazione prevede l'apertura di più flussi video, la loro decodifica, l'applicazione di effetti video, la loro combinazione e infine la presentazione di un flusso video che viene ripetutamente elaborato alla fine. Joachim Deguara afferma che le prestazioni sono un obiettivo chiave per questa applicazione e, per ottenere una presentazione in tempo reale, è essenziale adattare la decodifica, l'elaborazione e la visualizzazione in una struttura di looping che si verifica 30 volte al secondo o la frequenza dei fotogrammi del video in ingresso .
  
  
• 00:05:00 In questa sezione, l'attenzione è rivolta alla decodifica dei formati video e allo spostamento del fotogramma sulla GPU. Per decodificare il formato video, è necessario assicurarsi che ciò avvenga il più velocemente possibile in modo che non influisca sulle prestazioni. Un modo per farlo è fare in modo che la funzione di decodifica venga eseguita separatamente dal ciclo principale e, quando viene chiamata, affinché restituisca l'ultimo frame. Ciò garantisce che la decodifica venga eseguita in background mentre il ciclo principale continua senza interruzioni. Per spostare il frame sulla GPU, vengono utilizzate chiamate API che includono la specifica dell'immagine su cui scrivere e se la scrittura deve avvenire in modo sincrono o asincrono.
  
  
• 00:10:00 In questa sezione, il relatore discute DMA (accesso diretto alla memoria) e come può essere utilizzato per trasferire la memoria tra la memoria principale del sistema e la memoria della GPU senza che la CPU debba copiarla. Il motore DMA gestisce questa operazione in parallelo, liberando risorse per CPU e GPU. Il trasferimento di buffer e immagini può essere eseguito in modo asincrono e richiede flag speciali. Tuttavia, i dati non possono essere utilizzati immediatamente dopo una copia, quindi il programma deve essere ristrutturato di conseguenza per sfruttare DMA. L'oratore suggerisce il doppio buffering e la ristrutturazione dei processi del ciclo per evitare di corrompere i dati attualmente elaborati o visualizzati. Nel complesso, DMA può migliorare notevolmente le prestazioni delle applicazioni scaricando i cicli di CPU e GPU.
  
  
• 00:15:00 In questa sezione, il relatore discute l'approccio del doppio buffering utilizzato in OpenCL per elaborare e visualizzare i fotogrammi di un video. Questo approccio prevede il buffering costante di due frame, A e B, e l'elaborazione di uno mentre l'altro viene caricato. Ciò elimina la necessità di sommare il tempo di elaborazione e il tempo di caricamento e richiede invece solo il tempo massimo necessario per entrambi i processi. L'oratore discute anche l'impostazione degli argomenti per il kernel, che deve essere eseguita solo una volta e può essere utilizzata per tutte le successive esecuzioni di elaborazione se i parametri non devono essere modificati.
  
  
• 00:20:00 In questa sezione, l'oratore discute come eseguire il kernel e menziona due modi per chiamare l'elaborazione, inclusi i metodi bloccanti e non bloccanti. Sebbene il blocco consenta un debugging più semplice, non è ottimale per le prestazioni, quindi il relatore introduce l'opzione per utilizzare eventi e vettori di eventi per attendere operazioni o per impostare grafici di dipendenza per più operazioni. Utilizzando gli oggetti evento per segnalare il completamento di determinati elementi di lavoro, può garantire che l'operazione a valle venga avviata solo una volta completati, consentendo un'elaborazione più efficiente.
  
  
• 00:25:00 In questa sezione, il relatore spiega come utilizzare gli oggetti evento OpenCL per sincronizzare le operazioni e come utilizzare il profilo degli eventi per il test delle prestazioni. Quando si crea il grafico delle dipendenze per i filtri, viene passato un puntatore a un evento come ultimo argomento per l'operazione Enqueue, ma l'oggetto evento viene creato all'interno di InQ. Ciò può causare confusione, ma consente di impostare dipendenze tra i filtri e le operazioni di caricamento. Il relatore descrive come, con la profilazione dell'evento, sia possibile recuperare i timestamp dall'evento relativi a quando determinati eventi si sono verificati nel ciclo di vita dell'evento, ad esempio quando l'operazione dei riferimenti all'evento è stata messa in coda, è stata inviata, è iniziata l'esecuzione, e ha completato la corsa. Ciò consente la profilazione mantenendo tutte le operazioni asincrone.
  
  
• 00:30:00 In questa sezione del video, il relatore spiega i diversi stati attraversati da un evento quando si utilizza OpenCL, ad esempio in coda, inviato, in esecuzione e completato, e come utilizzare i dati del profilo dell'evento e i timestamp per misurare le prestazioni e identificare potenziali problemi come lunghi tempi di esecuzione per operazioni o caricamenti di dati. Il relatore spiega anche come attendere il completamento degli eventi per garantire la visualizzazione accurata dei flussi video con vari filtri ed effetti.
  
  
• 00:35:00 In questa sezione, il relatore discute l'interoperabilità OpenCL e OpenGL, che consente la condivisione di determinate informazioni tra i due. Questa funzionalità è facoltativa e quindi non tutte le implementazioni devono supportarla. L'oratore sottolinea l'importanza di controllare l'estensione e creare un contesto in OpenCL con determinati flag per attivare l'interoperabilità OpenCL-OpenGL. Il modo in cui funziona è creando un'immagine OpenCL da una trama OpenGL che è già stata creata, quindi i dati non vengono copiati inutilmente avanti e indietro.
  
  
• 00:40:00 In questa sezione, il relatore spiega come OpenCL e OpenGL possono condividere insieme i dati delle immagini tramite Interop. Coprono il target, il livello NIP e l'oggetto texture necessari per fare riferimento alla texture Open GL. Una volta creata, l'immagine OpenCl può essere utilizzata come una normale immagine OpenCl, ma i due programmi devono eseguire un po' di handshaking per assicurarsi che non interferiscano l'uno con l'altro. Il relatore risponde anche a una domanda su come creare transizioni nel rendering video. Dice che può essere fatto utilizzando la posizione di uno scorrimento come input nel filtro. Alla fine, il risultato finale viene trasferito a OpenGL per scopi di visualizzazione, che completa tutti i passaggi.
  
  
• 00:45:00 In questa sezione, l'oratore spiega come elaborano gli swipe in un video osservando l'indicatore temporale di ciascun fotogramma e utilizzando un fotogramma chiave per interpolare la posizione dello swipe. Rispondono anche a una domanda sulla profilazione in OpenCL, affermando che i timestamp dipendono da un timer esterno ad alta risoluzione ma non da una chiamata a CL finish. Inoltre, il relatore discute l'ordine di esecuzione nei dispositivi e nei runtime OpenCL e conferma che le operazioni vengono gestite in ordine per la maggior parte dei dispositivi.
  
  
• 00:50:00 In questa sezione, il relatore esplora le differenze tra OpenCL e OpenGL durante l'elaborazione degli algoritmi. La decisione su quale piattaforma utilizzare dipende dalle preferenze individuali, sebbene OpenCL possa essere più facile da programmare grazie alla sua struttura linguistica completa. In termini di prestazioni, OpenCL può consentire l'elaborazione di applicazioni che richiedono hardware più complesso; tuttavia, ci sono casi in cui l'uso dell'ombreggiatura OpenGL può portare a prestazioni migliori. Inoltre, sebbene l'oratore non sia stato in grado di fornire alcun codice di esempio disponibile per l'applicazione specifica, ci sono vari esempi di codice nell'SDK OpenCL di AMD da cui gli utenti possono imparare.
  
  
• 00:55:00 In questa sezione, il relatore discute vari esempi e SDK disponibili per gli sviluppatori per le applicazioni OpenCL. Gli esempi mostrano come interrogare i dispositivi e il tempo di esecuzione per ottenere le estensioni, oltre a fornire esempi di interoperabilità OpenCL OpenGL. Tuttavia, al momento non è disponibile alcun codice di esempio per l'applicazione specifica discussa nel video, ma ciò potrebbe cambiare in futuro. Il webinar si è concluso e una registrazione sarà messa a disposizione dei partecipanti.

[MetaQuotes]

AMD Developer Central: serie di webinar sulla programmazione OpenCL. 6. Estensioni Device Fission per OpenCL

6 - Estensioni Device Fission per OpenCL

In questo video, il relatore copre vari argomenti relativi alle estensioni di fissione del dispositivo per OpenCL. Spiegano i diversi tipi di estensioni e come la fissione dei dispositivi consente di suddividere i dispositivi di grandi dimensioni in dispositivi più piccoli, utile per riservare un nucleo per attività ad alta priorità o per garantire che gruppi di lavoro specifici siano assegnati a nuclei specifici. Discutono dell'importanza di mantenere la semantica sequenziale durante la parallelizzazione delle operazioni di pushback vettoriale, l'utilizzo di modelli paralleli per ottimizzare il processo e la creazione di kernel nativi in OpenCL. Il relatore mostra anche un'applicazione che utilizza la fissione del dispositivo per OpenCL e discute l'affinità della memoria e il futuro della fissione del dispositivo su altri dispositivi.

• 00:00:00 In questa sezione, l'oratore discute le estensioni in OpenCL, in particolare i tre diversi tipi di estensioni: estensioni KHR, estensioni EXT ed estensioni del fornitore. Le estensioni KHR sono approvate dal gruppo di lavoro OpenCL e vengono fornite con una serie di test di conformità. Le estensioni EXT sono sviluppate da almeno due membri del gruppo di lavoro e non richiedono test di conformità. Le estensioni del fornitore, come CL_AMD_printf, sono sviluppate da un singolo fornitore e possono essere supportate solo da quel fornitore. La documentazione per tutte le estensioni è disponibile sul sito Web del registro Chronos OpenCL, consentendo trasparenza e accessibilità tra i fornitori.
  
  
• 00:05:00 In questa sezione, l'oratore menziona l'estensione di fissione del dispositivo per OpenCL chiamata visione del dispositivo. Questa estensione consente all'utente di suddividere dispositivi di grandi dimensioni con molte unità di calcolo in dispositivi OpenCL più piccoli, per nome o per affinità di memoria. Questa divisione può aiutare a riservare un nucleo per un'attività prioritaria o garantire che gruppi di lavoro specifici siano assegnati a nuclei specifici, come in un sistema basato su SMP. Il relatore motiva l'uso della visione del dispositivo con un esempio di algoritmi paralleli e contenitori paralleli costruiti su OpenCL e afferma che questa estensione è attualmente supportata da AMD e IBM sulle loro CPU e dispositivi a banda larga cellulare.
  
  
• 00:10:00 In questa sezione, il relatore discute l'importanza di mantenere la semantica sequenziale durante la parallelizzazione delle operazioni di pushback vettoriale. Spiegano che quando si inseriscono elementi in un vettore durante un ciclo sequenziale, l'ordine previsto apparirebbe in funzione del ciclo. Tuttavia, quando parallelizzato, questo ordine viene perso e gli elementi possono essere inseriti fuori ordine, quindi l'oratore propone di mantenere la semantica sequenziale dell'operazione di pushback del vettore. Quindi forniscono un esempio di come questo potrebbe essere essenziale in un'applicazione come una versione semplificata di un flusso MPEG-2. Concludono introducendo una funzione C e discutendo su come implementare queste operazioni parallele sulle CPU.
  
  
• 00:15:00 In questa sezione, il relatore spiega come utilizzare modelli paralleli per ottimizzare il processo Device Fission Extensions per OpenCL. Usano il modello pipeline per eseguire funzioni in parallelo e introducono un blocco di dati da leggere dai dati di input per elaborare un elemento di lavoro in una memoria locale. L'approccio scrive quindi l'offset della cassetta postale nel gruppo di lavoro corrispondente per calcolare gli offset preservando l'ordine dell'output. L'ordinamento si ottiene attraverso la comunicazione tra gruppi di lavoro invece di fare affidamento sull'ID globale che può essere eseguito in un ordine arbitrario. Il modello di pipeline assicura che le funzioni vengano eseguite in parallelo per ottimizzare il processo.
  
  
• 00:20:00 In questa sezione, l'oratore discute la loro pipeline e come ora usano il termine "contatore" come casella di posta, poiché sono andati oltre il semplice conteggio delle cose. Spiegano che stanno passando gli ID di gruppo per l'indicizzazione nelle cassette postali e utilizzando la memoria locale e globale per semplici calcoli. Tuttavia, notano che non ci sono garanzie per l'esecuzione del gruppo di lavoro e spiegano come ciò potrebbe causare una situazione di deadlock. Per risolvere questo problema, il relatore suggerisce di dividere il dispositivo in due core separati utilizzando la visione del dispositivo, avviando un gruppo di lavoro su ciascun core e garantendo il progresso. Introducono anche un importante meccanismo fornito da OpenCL per l'esecuzione su un dispositivo host.
  
  
• 00:25:00 In questa sezione, il relatore discute i vantaggi dell'utilizzo di kernel nativi in OpenCL, che consente l'esecuzione di funzioni C o C++ arbitrarie. Può offrire maggiore flessibilità nel provare diverse implementazioni, nonché la possibilità di chiamare routine I/O standard o altre funzioni di libreria che potrebbero non essere disponibili in OpenCL. Il processo di creazione di un kernel nativo in OpenCL implica il passaggio di una coda di comandi e di una funzione insieme ai suoi argomenti e agli oggetti di memoria. Tuttavia, è necessario prestare attenzione con l'archiviazione locale del thread poiché la funzione potrebbe non essere eseguita nello stesso thread in cui è stata inclusa. Il relatore introduce anche l'API di binding OpenCL C++ che offre alcune astrazioni oltre all'API C. Il programma inizia interrogando le piattaforme disponibili e creando un contesto e un tipo di dispositivo.
  
  
• 00:30:00 In questa sezione, il relatore discute l'uso delle estensioni di fissione del dispositivo per OpenCL. Una volta interrogato un dispositivo valido, viene restituito un elenco di dispositivi e viene selezionato il primo dispositivo per supportare la fissione del dispositivo. La fissione del dispositivo è una novità per l'API OpenCL e richiede meccanismi di estensione, che consentono di descrivere una partizione. Usano la partizione allo stesso modo per suddividerla in dispositivi di unità di uno. Vengono quindi impostate le proprietà del sottodispositivo e viene chiamata la funzione di creazione dei sottodispositivi. Supponendo che venga creato almeno un sottodispositivo, vengono create le cassette postali e viene creata una coda di comando per ciascun dispositivo. I dispositivi risultanti sono esattamente come qualsiasi altro dispositivo e possono essere utilizzati in modo intercambiabile con le librerie esistenti. L'oratore passa quindi alla configurazione dei kernel OpenCL nativi.
  
  
• 00:35:00 In questa sezione, il relatore discute gli input e gli argomenti richiesti per l'implementazione delle estensioni Device Fission per OpenCL. Il relatore spiega che il buffer di memoria per gli ingressi sarà diviso in quattro parti, dove i puntatori saranno messi dal runtime FN c. Il buffer di memoria sarà costituito da cassette postali, blocchi e transazioni cache e verranno generati ID univoci per ciascun kernel. L'oratore spiega inoltre che ogni istanza del kernel verrà eseguita su singoli dispositivi e, una volta completati tutti gli eventi, i dati verranno scritti con il riempimento inserito. Il kernel stesso includerà ottimizzazioni relative al blocco e alla memorizzazione nella cache per garantire un'esecuzione efficiente.
  
  
• 00:40:00 In questa sezione, il relatore discute l'implementazione di un'applicazione che utilizza la fissione del dispositivo per OpenCL. Spiegano come funziona l'applicazione utilizzando vari tipi, come input/output, cassette postali, array di blocchi locali, dimensioni del blocco e ID di gruppo, per indicizzare i set di dati in parallelo. L'applicazione implementa anche semplici ottimizzazioni di attesa e blocco per garantire che tutto venga eseguito il più possibile in parallelo. Utilizzando la fissione del dispositivo, l'implementazione di questa applicazione mostra il potenziale per ottenere accelerazioni sulla CPU con operazioni ALU minime o nulle, che potrebbero aumentare ulteriormente con l'implementazione di vettori più ampi in futuro. Il relatore discute anche le altre applicazioni e casi d'uso per la fissione del dispositivo, come la divisione rispetto all'infinito e ai sistemi spaziali Numa.
  
  
• 00:45:00 In questa sezione, il relatore discute i vantaggi dell'affinità di memoria in OpenCL, che consente l'associazione precisa dei buffer con un particolare dispositivo. Ciò può portare a una migliore località della cache e prestazioni migliori evitando contese e condivisioni negative. Lo schema della cassetta postale utilizzato in OpenCL può essere esteso per supportare più iterazioni, consentendo un ciclo che avvia ripetutamente la pipeline a cascata. Il relatore menziona anche la disponibilità di risorse nella zona OpenCL su developer.amd.com, dove le parti interessate possono trovare maggiori informazioni su OpenCL, inclusi webinar, presentazioni passate e un prossimo summit sull'informatica eterogenea. Il relatore accenna anche alla possibilità di supportare in futuro la fissione dei dispositivi sulla GPU, che riserverebbe una parte del core per compiti ad alta priorità e garantirebbe prestazioni migliori.
  
  
• 00:50:00 In questa sezione del video, il relatore discute il futuro della fissione dei dispositivi spostandosi verso altri dispositivi. Attualmente, solo AMD e IBM supportano estensioni di fissione del dispositivo per OpenCL, ma altri fornitori hanno mostrato interesse per la proposta. Viene sollevata la questione se le librerie matematiche come BLAS e FFT saranno supportate e il relatore conferma che stanno lavorando su implementazioni OpenCL sia di BLAS che di diverse varianti e implementazioni per l'algebra lineare che saranno presentate in una libreria in stile FFT.

[MetaQuotes]

AMD Developer Central: serie di webinar sulla programmazione OpenCL. 7. Idrodinamica delle particelle levigate

7 - Idrodinamica delle particelle levigate

Questo video discute Smoothed Particle Hydrodynamics (SPH), una tecnica per risolvere equazioni fluidodinamiche, in particolare le equazioni di Navier-Stokes. Il video spiega i diversi termini nelle equazioni, inclusi i termini di densità, pressione e viscosità, e come vengono approssimati utilizzando un kernel di levigatura. Viene discusso anche l'algoritmo numerico utilizzato per SPH, nonché l'uso dell'indicizzazione spaziale e dell'interoperabilità. L'oratore spiega il processo di costruzione di un indice spaziale e di una mappa dei vicini e come viene calcolata la fisica. Il video invita gli spettatori a scaricare e utilizzare il programma e discute i limiti della simulazione. L'oratore risponde quindi alle domande del pubblico sulle prestazioni della GPU, sul comportamento incomprimibile e sull'utilizzo di immagini memorizzate nella cache.

• 00:00:00 In questa sezione, Alan Hierich, membro senior dello staff tecnico di AMD, fornisce una panoramica della fluidodinamica computazionale, in particolare dell'idrodinamica delle particelle lisce (SPH). SPH è stato originariamente utilizzato per i calcoli astrofisici, ma è diventato piuttosto popolare nei videogiochi e nelle simulazioni. La tecnica viene utilizzata per risolvere le equazioni di Navier-Stokes, che sono equazioni alle derivate parziali formulate nel 1900 e che sono alla base della maggior parte del lavoro di dinamica dei fluidi oggi. Allen spiega la definizione di fluidi e fornisce una spiegazione intuitiva di come funzionano, concentrandosi su liquidi e gas. Sottolinea inoltre che i fluidi sono generalmente descritti dalle equazioni di Navier-Stokes e che le incomprimibili equazioni di Navier-Stokes governano fluidi come l'acqua a velocità e temperature normali.
  
  
• 00:05:00 In questa sezione, il relatore spiega le equazioni che governano i fluidi, note come equazioni di Navier-Stokes. L'equazione del moto rappresenta la variazione di velocità in funzione della gravità, della pressione e della viscosità, mentre l'equazione di continuità della massa afferma che la massa non viene né creata né distrutta. I fenomeni che governano un fluido sono gravità, pressione e velocità, e la viscosità è la viscosità del fluido, che determina la probabilità che le particelle di fluido viaggino nella stessa direzione. Viene discusso anche il termine di accelerazione convettiva, che descrive l'accelerazione di un fluido mentre si muove attraverso un'apertura più piccola, come un ugello su un tubo da giardino. Il relatore invita il pubblico a scaricare e giocare con il programma che simula i fluidi in una scatola che è stata dimostrata.
  
  
• 00:10:00 In questa sezione, il relatore spiega i diversi termini nell'equazione del moto per la dinamica dei fluidi, tra cui l'accelerazione convettiva, il gradiente di pressione e la viscosità. La pressione è definita come la differenza tra la densità effettiva del fluido in un punto e la densità a riposo. Il termine di viscosità, che è l'ultimo termine sul lato destro dell'equazione del moto, diffonde la quantità di moto del sistema, risultando infine in uno stato in cui la velocità è equivalente in tutte le posizioni. Esiste anche un'equazione di continuità di massa, del punto V uguale a 0, che implica che la massa non viene né creata né distrutta nelle equazioni incomprimibili. Infine, per rappresentare la dinamica del sistema, l'oratore prende la derivata materiale dell'equazione per ottenere l'equazione del moto per una particella.
  
  
• 00:15:00 In questa sezione, il video discute la tecnica idrodinamica delle particelle levigate (SPH) per risolvere le equazioni di Navier-Stokes incomprimibili semplificate introdotte nella sezione precedente. La tecnica SPH è stata introdotta per la prima volta nel 1992 per lo studio dell'astrofisica e delle galassie, ma può essere utilizzata anche per le equazioni dei fluidi. Implica l'introduzione di rappresentazioni kernel di livellamento delle quantità, che sono come funzioni di base che ci consentono di approssimare qualsiasi quantità mediante una somma della quantità in punti vicini moltiplicata per una funzione di ponderazione. La tecnica SPH viene utilizzata per approssimare i termini del gradiente di densità e pressione nelle equazioni di Navier-Stokes. Il video menziona anche che le equazioni di Navier-Stokes sono numericamente sensibili alla scala e che i calcoli vengono eseguiti su una scala più piccola prima di essere espansi alla normale scala spaziale per spostare le particelle nello spazio.
  
  
• 00:20:00 In questa sezione, il relatore spiega i tre termini principali che sono approssimati in Smoothed Particle Hydrodynamics (SPH), che sono i termini di densità, pressione e viscosità. Per calcolare la densità, il programma calcola la massa delle particelle in vari punti e la moltiplica per il gradiente di un kernel levigante. Il termine di pressione viene quindi calcolato utilizzando una quantità scalare di pressione divisa per la densità, che viene moltiplicata per il gradiente del kernel levigante. D'altra parte, il termine di viscosità viene approssimato utilizzando un coefficiente scalare che determina il livello di viscosità del fluido e la differenza di velocità tra due punti divisa per la densità del punto J. Il relatore spiega anche le proprietà del nucleo levigante, che è utilizzato nella simulazione SPH e come si somma a uno su una sfera di raggio H.
  
  
• 00:25:00 In questa sezione, il relatore discute l'algoritmo numerico utilizzato per Smoothed Particle Hydrodynamics (SPH). L'algoritmo prevede il calcolo della densità, della pressione, del gradiente di pressione, del termine viscoso e dell'accelerazione, che vengono quindi utilizzati per calcolare le velocità e le posizioni delle particelle. L'oratore spiega che l'algoritmo iniziale prevede il test delle interazioni di tutte le particelle contro tutte le particelle, il che è corretto ma non abbastanza veloce. Quindi, viene introdotto un algoritmo migliore, che divide lo spazio in voxel, consentendo interazioni solo con particelle all'interno del raggio di interazione. Inoltre, un sottoinsieme di particelle viene scelto casualmente per calcolare le interazioni invece di considerare tutte le particelle, il che produce un programma efficiente.
  
  
• 00:30:00 In questa sezione, il relatore discute l'uso dell'indicizzazione spaziale per calcolare solo le interazioni con un numero limitato di particelle nelle simulazioni OpenCL, nonché l'importanza dell'utilizzo di Interop per condividere buffer di dati con un sistema grafico. Sebbene Interop consenta il rendering direttamente dal buffer della GPU e risparmi spazio nella memoria grafica, senza di esso il programma dovrebbe copiare i dati nella memoria host e viceversa, rallentando notevolmente la simulazione. Il relatore spiega le modifiche necessarie per utilizzare Interop, inclusa la creazione di un contesto diverso, e introduce l'insieme di buffer necessari per la simulazione, incluso l'indice delle particelle per l'ordinamento. Nonostante si discuta l'importanza di Interop, il programma mostrato non lo utilizza, il che rallenta la simulazione.
  
  
• 00:35:00 In questa sezione, il relatore discute i vari kernel utilizzati nell'algoritmo Smoothed Particle Hydrodynamics. Il primo kernel è "particelle di hash", che associa le particelle a un voxel. Quindi, i kernel "sort" e "sort post pass" ordinano le particelle in voxel e le organizzano per la costruzione dell'indice spaziale. Successivamente, i kernel "index" e "index post pass" costruiscono un indice spaziale dai voxel alle particelle. Successivamente, il kernel "fine neighbors" decide quali vicini interagiranno tra loro. Infine, i kernel "calcola la pressione della densità", "calcola l'accelerazione" e "integra" calcolano le interazioni e la fisica tra le particelle. L'oratore spiega che radix sort viene utilizzato nella versione GPU del codice, mentre Q sort viene utilizzato nella versione CPU del codice.
  
  
• 00:40:00 In questa sezione, il video spiega il processo di costruzione di un indice spaziale dai voxel alle particelle in Smoothed Particle Hydrodynamics (SPH). Il kernel utilizza una ricerca binaria per identificare la particella con il numero più basso in ciascun voxel e lascia un valore negativo uno nei voxel che non contengono particelle. L'indice dopo il passaggio riempie quindi un valore di indice per i voxel vuoti copiando il valore del successivo voxel non vuoto nell'indice della cella della griglia. Una volta eseguita l'indicizzazione, il programma costruisce una mappa dei vicini effettuando una ricerca nella regione locale di due voxel per due per due che circondano ciascuna particella. Per eliminare i bias, il programma genera un offset casuale in ciascun voxel e alterna la direzione della ricerca. Il kernel quindi seleziona le prime 32 particelle all'interno del raggio di interazione e le aggiunge alla mappa dei vicini.
  
  
• 00:45:00 In questa sezione, il relatore spiega come hanno calcolato la fisica costruendo una mappa dei vicini, che consente loro di interagire con 32 particelle. Esaminano le equazioni utilizzate per approssimare la densità e la pressione, calcolano i termini di accelerazione e poi combinano tutto per determinare l'accelerazione totale. La velocità e la posizione vengono quindi avanzate attraverso l'integrazione numerica, con condizioni al contorno in atto per impedire alle particelle di fuoriuscire dalla scatola. L'oratore incoraggia gli spettatori a scaricare e giocare con il codice sorgente e sottolinea che mentre ci sono molti metodi lenti per risolvere le equazioni di Navier-Stokes, lento non significa necessariamente buono.
  
  
• 00:50:00 In questa sezione del video, il relatore spiega la fase di aggiornamento della simulazione, in cui la velocità viene integrata nella sua nuova posizione prima di aggiornare la posizione. L'aggiornamento della velocità è esplicito, mentre l'aggiornamento della posizione è semi-implicito, utilizzando il valore della velocità al passo temporale successivo. La simulazione è in virgola mobile ai fini delle prestazioni, ma se sono necessarie alta fedeltà e precisione, si consiglia di utilizzare double. L'algoritmo è completamente parallelizzabile, ma è necessario tenere conto dei compromessi del partizionamento spaziale. Infine, il relatore risponde alle domande sull'utilizzo di Interop con più GPU, sulla simulazione della turbolenza e sul numero massimo pratico di particelle nella simulazione.
  
  
• 00:55:00 In questa sezione, il relatore risponde ad alcune domande del pubblico. Spiegano che il limite pratico della loro simulazione è il tasso di prestazioni, che dipende dalla classe di GPU e CPU utilizzate. Dicono anche che sebbene la loro simulazione sia basata su equazioni incomprimibili, non stanno risolvendo esplicitamente la condizione di incomprimibilità, che potrebbe limitare il suo comportamento comprimibile. L'oratore risponde anche a una domanda sul motivo per cui hanno utilizzato i buffer invece della memoria delle immagini memorizzate nella cache, affermando che al momento in cui hanno sviluppato il programma, non hanno visto alcun vantaggio in termini di prestazioni nell'utilizzo delle immagini memorizzate nella cache. Tuttavia, affermano che OpenCL fornirà il supporto per i buffer memorizzati nella cache in futuro e che potrebbero modificare il programma per supportarli. Nel complesso, il relatore invita il pubblico a scaricare e utilizzare il programma nel modo che preferisce, poiché non ci sono limitazioni.

[MetaQuotes]

AMD Developer Central: serie di webinar sulla programmazione OpenCL. 8. Tecniche di ottimizzazione: convoluzione dell'immagine

8 - Optimization Techniques: Image Convolution

In questo video Udeepta D. Bordoloi discute le tecniche di ottimizzazione nella convoluzione dell'immagine.

[MetaQuotes]

AMD Developer Inside Track: come ottimizzare la convoluzione dell'immagine

Come ottimizzare la convoluzione dell'immagine

Questo video illustra vari metodi per ottimizzare la convoluzione dell'immagine, incluso l'utilizzo della condivisione dei dati locali, l'ottimizzazione delle costanti e l'utilizzo di aree locali più ampie per migliorare l'efficienza. Il relatore sottolinea l'importanza di ridurre al minimo il tempo di elaborazione nella convoluzione dell'immagine per migliorare le prestazioni complessive e mette in evidenza un nuovo metodo di riutilizzo dei dati utilizzando la memoria locale. Il video offre suggerimenti per passaggi di ottimizzazione come l'uso di ovvie o trame, l'uso della forza del pensiero e l'uso delle opzioni di passaggio al bancone. Un articolo dettagliato sull'ottimizzazione delle tecniche di convoluzione dell'immagine è disponibile sul sito Web dello sviluppatore AMD.

• 00:00:00 In questa sezione, Udeepta Bordolo del team grafico di AMD spiega il concetto di convoluzione dell'immagine, che comporta l'esecuzione di una somma ponderata su un'area dell'immagine di input per generare un pixel dell'immagine di output. Usa OpenCL e una GPU 5870 per eseguire l'ottimizzazione, partendo gradualmente dal codice di correlazione di base. Il mirroring e l'utilizzo di LDS (Local Data Share) sono alcuni dei metodi di ottimizzazione utilizzati, che si traducono in una significativa riduzione dei tempi di esecuzione.
  
  
• 00:05:00 In questa sezione, il relatore discute l'ottimizzazione della convoluzione dell'immagine in un programma che funziona per tutte le dimensioni del filtro e tutte le dimensioni dell'input. Si concentra sull'utilizzo delle aree locali per migliorare la condivisione dei dati e ridurre i tempi di attesa. Interpretando le costanti e gli input come valori a 128 bit, il compilatore e il genio possono interpretare più facilmente il codice e ridurre i tempi di elaborazione. Mostra come l'ottimizzazione delle costanti e l'utilizzo di aree locali più ampie possono migliorare notevolmente l'efficienza nella convoluzione dell'immagine. Nel complesso, il relatore sottolinea l'importanza di trovare modi per ridurre al minimo il tempo di elaborazione nella convoluzione dell'immagine per migliorare le prestazioni complessive.
  
  
• 00:10:00 In questa sezione, il relatore spiega come ottimizzare la convoluzione dell'immagine determinando la dimensione del filtro e come modificarla per diverse maschere. Il relatore osserva che l'applicazione dell'ottimizzazione in momenti diversi può influire sulle prestazioni, ma può aiutare a trovare eventuali problemi imprevisti. Il relatore discute anche l'esecuzione dello stesso numero di elementi per un'immagine di input 2k per 2k con dati full force, che ha portato a un formato dati più efficiente. Inoltre, il relatore evidenzia un nuovo metodo di riutilizzo dei dati invece di utilizzare il motore utilizzando la memoria locale, nota come LDS nell'hardware.
  
  
• 00:15:00 In questa sezione, il relatore parla dell'ottimizzazione delle tecniche di convoluzione dell'immagine. Caricano tutti gli input, li ritardano di un particolare gruppo e poi risolvono l'ovvio. Usano i soldi così come li conoscono e smettono di usare LDS per provare a usare le trame. Conducono un esperimento con una risoluzione 2K per 2K e diverse dimensioni del filtro e ottengono il numero più veloce quando utilizzano le trame. Suggeriscono i passaggi di ottimizzazione dell'uso di ovvie o trame, usando la forza del pensiero e usando le opzioni di passaggio al bancone. Suggeriscono anche di usare il cash monster quando possibile. Hanno pubblicato un articolo dettagliato sull'ottimizzazione delle tecniche di convoluzione dell'immagine sul sito Web dello sviluppatore AMD, a cui si collegano accanto al video.

[MetaQuotes]

AMD Developer Central: panoramica tecnica di OpenCL. Introduzione a OpenCL

AMD Developer Central: panoramica tecnica di OpenCL. Introduzione a OpenCL

In questo video, Michael Houston fornisce una panoramica di OpenCL, uno standard di settore per il calcolo parallelo dei dati destinato a CPU multi-core, dispositivi mobili e altre forme di silicio. OpenCL mira a unificare implementazioni proprietarie precedentemente concorrenti come CUDA e Brook+ che semplificheranno lo sviluppo per i fornitori di software indipendenti. Offre una ripartizione tra il codice che viene eseguito sul dispositivo e il codice che gestisce il dispositivo utilizzando un sistema di accodamento progettato per il feedback con gli sviluppatori di giochi. OpenCL è progettato per funzionare bene con le API grafiche, creando un linguaggio informatico onnipresente che può essere utilizzato per varie applicazioni come l'editing di foto e video, nonché per sistemi di intelligenza artificiale, modellazione e fisica. Il relatore discute anche dell'uso di OpenCL per il rendering di Hollywood e spera di vedere più lavoro in quest'area.

• 00:00:00 In questa sezione, Mike Houston spiega lo scopo di OpenCL come standard industriale per il calcolo parallelo dei dati, mirato a CPU multi-core, dispositivi mobili e altre forme di silicio. OpenCL mira a unificare implementazioni proprietarie precedentemente concorrenti come CUDA e Brook+, che semplificheranno lo sviluppo per i fornitori di software indipendenti. Sebbene ci sia un dialetto diverso e differenze minori in OpenCL, la transizione da altri linguaggi paralleli di dati come CUDA è diretta e veloce. OpenCL offre anche una ripartizione tra il codice che viene eseguito sul dispositivo e il codice che gestisce il dispositivo utilizzando un sistema di accodamento progettato per il feedback con gli sviluppatori di giochi. È progettato per funzionare bene con le API grafiche, creando un linguaggio informatico onnipresente per lo spazio consumer in applicazioni come l'editing di foto e video.
  
  
• 00:05:00 In questa sezione, l'oratore spiega alcuni degli usi iniziali di OpenCL, che include l'elaborazione di immagini o video ad alta risoluzione e l'esecuzione di scanner antivirus. Inoltre, la tecnologia è utile per i sistemi di intelligenza artificiale, i sistemi di modellazione, la fisica, la post-elaborazione e l'accelerazione dell'illuminazione e del rendering per i film. L'oratore spera di vedere più lavoro sull'utilizzo di OpenCL per il rendering di Hollywood, tra le altre cose.

[MetaQuotes]

AMD Developer Central: Episodio 1: Che cos'è OpenCL™?

AMD Developer Central: Episodio 1: Che cos'è OpenCL™?

Questo video fornisce un'introduzione a OpenCL e ai suoi obiettivi di progettazione, che si concentrano sull'utilizzo di vari processori per accelerare i calcoli paralleli invece di quelli sequenziali. OpenCL consente la scrittura di codice portabile per diversi processori utilizzando kernel, dimensioni globali e locali e gruppi di lavoro. Gli elementi di lavoro ei gruppi di lavoro possono collaborare condividendo le risorse, ma la sincronizzazione tra elementi di lavoro in gruppi di lavoro diversi non è possibile. Le dimensioni ottimali del problema variano a seconda dei diversi tipi di elaborazione ed è importante scegliere le dimensioni migliori per ottenere le migliori prestazioni. OpenCL è in grado di utilizzare appieno le capacità di un sistema esprimendo parallelismo di attività e dati utilizzando il modello di eventi OpenCL.

• 00:00:00 In questa sezione, Justin Hensley discute le basi di OpenCL e i suoi obiettivi di progettazione, che si concentrano principalmente sull'utilizzo di CPU, GPU o qualsiasi altro processore, come il motore a banda larga cellulare o i DSP, per accelerare i calcoli paralleli piuttosto che quelli sequenziali, con conseguenti accelerazioni drammatiche. OpenCL consente di scrivere codice portatile da eseguire su qualsiasi tipo di processore, come CPU e GPU AMD, utilizzando kernel, che sono simili alle funzioni C utilizzate per sfruttare il parallelismo, e programmi che sono raccolte di kernel e altre funzioni, con applicazioni che eseguono istanze del kernel utilizzando code accodate ed eseguite in ordine o fuori ordine. Le dimensioni globale e locale in OpenCL definiscono l'intervallo di calcolo, mentre l'intero punto di OpenCL è utilizzare dispositivi altamente paralleli per accelerare il calcolo simultaneamente, consentendo ai gruppi di lavoro locali di collaborare condividendo le risorse perché gli elementi di lavoro globali devono essere indipendenti con la sincronizzazione solo possibile all'interno di un gruppo di lavoro.
  
  
• 00:05:00 In questa sezione, apprendiamo gli elementi di lavoro e i gruppi di lavoro e come OpenCL ci consente di sincronizzare gli elementi di lavoro all'interno di un gruppo di lavoro utilizzando barriere o recinti di memoria. Tuttavia, gli elementi di lavoro in gruppi di lavoro diversi non possono essere sincronizzati tra loro. Le dimensioni ottimali del problema variano anche per i diversi tipi di elaborazione ed è importante scegliere le dimensioni migliori per il problema dato per ottenere le migliori prestazioni. In OpenCL, è anche possibile esprimere il parallelismo delle attività eseguendo un singolo elemento di lavoro come attività utilizzando il modello di eventi OpenCL. Consentendo al parallelismo di attività e dati di lavorare insieme, OpenCL può sfruttare appieno le capacità del sistema.