Computer Architectuur 2016 Handleiding bij de CUDA opdracht

Transcriptie

1 Computer Architectuur 2016 Handleiding bij de CUDA opdracht Voor opdracht vier kijken we naar een eenvoudige image filter pipeline en naar een mogelijke versnelling hiervan met behulp van de GPU. Bij een dergelijke filter pipeline (niet te verwarren met de pipeline in de processor) voeren we achtereenvolgend meerdere filters uit op één afbeelding, waarbij deze filters een cumulatief effect hebben. Het startpunt, te downloaden vanaf de website, bevat de complete pipeline geschreven voor de CPU. We zullen deze filters eerst goed bestuderen in hun huidige vorm. Vervolgens is het de bedoeling de bestaande code te porten naar de GPU met behulp van CUDA. CUDA is de GPGPU tookit van NVIDIA en werkt alleen met videokaarten met een NVIDIA GPU. Er is voor CUDA gekozen vanwege de laagdrempelige instap en de goede documentatie. Zie voor de documentatie van de CUDA API: Let op dat dit versie 8.0 is, wij gebruiken 5.0! Vooral de functies onder Modules Memory Management zullen van pas komen. 1 Startpunt Om het startpunt te kunnen compileren heb je, naast gcc, versie 5.0 van nvcc nodig. nvcc is NVIDIA s C(++) compiler voor CUDA. Verder gebruikt het startpunt SDL2 om de afbeelding op het scherm weer te geven en CMake als buildtool. Als je de opdracht thuis zou willen doen heb je uiteraard ook een NVIDIA videokaart met CUDA nodig (generatie Fermi of beter). Het startpunt is te compileren met de bijgeleverde makefiles. Pak het archief uit en typ achtereenvolgend./configure cd build make Vervolgens kun je het programma draaien met een Windows Bitmap (.BMP) afbeelding als argument. Bijvoorbeeld met het meegeleverde test2048.bmp ca_cuda../test2048.bmp Als het goed is, verschijnt na enige tijd de (bewerkte) afbeelding op het scherm. In de terminal verschijnt eveneens de gemiddelde performance: zo n 7 MB/s throughput op de machines in de practicum zaal. Dat kan natuurlijk beter. Met de meest eenvoudige implementatie zou je straks meer dan 1 GB/s op de GPU moeten halen. Je kunt ook met andere afbeeldingen experimenteren. Let er wel op dat de pipeline zgn. linear gamma (waarover later meer) verwacht en dat hele grote afbeeldingen op de CPU erg lang duren. 2 Aanpak We doorlopen nu het algemene idee achter het porten van CPU code naar CUDA. Zoals tijdens college is behandeld, bestaat de GPU uit honderden simpele cores ipv enkele complexe cores zoals bij de CPU. De grootste uitdaging is om deze cores zo goed mogelijk bezig te houden. Dit doen we door een eenvoudige operatie uit ons probleem te isoleren en deze parallel uit te zetten op de vele cores. Zo n operatie heet in CUDA een kernel. Een kernel is een simpele C-functie die vele keren parallel wordt uitgevoerd. Een enkele instantie van zo n kernel noemen we een thread. Threads worden vervolgens verdeeld over blocks 1 en die blocks staan weer in een grid. Bij de aanroep van 1 Binnen blocks worden threads ook nog in warps ingedeeld, dit is vooral voor optimalisatie relevant. Zie voor meer informatie de CUDA documentatie 1

2 de kernel mag de programmeur zelf bepalen hoe groot die blocks zijn en hoe de blocks en het grid worden gerangschikt: één-, twee, drie-dimensionaal. Dit is belangrijk omdat threads binnen één block geheugen delen en dus met elkaar kunnen communiceren en synchroniseren. 2.1 Kernels Stel we hebben we volgende CPU code: int A[100][100]; // Initialiseer op wat voor wijze dan ook int B[100][100]; for( int x =0; x < 100; x++ ) for( int y =0; y < 100; y++ ) B[x][y] =10 * A[x][y]; Dit is een typische geneste for-loop zoals die ook in de filters voorkomen. Het is in dit geval makkelijk te zien dat de loop-body, namelijk de array toekenning, een operatie is die we parallel kunnen uitvoeren (er bestaan geen loop-carried dependences). We beginnen door deze operatie te isoleren in een kernel: een C-functie van het type global void: global void mykernel( int* A, int* B, int N ) { // We nemen nu N voor het aantal kolommen, dus N=100 B[y+N*x] = 10 * A[y+N*x]; // Andere indexering: lineair geheugen ipv 2D-array } Nu hebben we eerst nog x en y nodig. We gaan er van uit dat we een grid maken dat 100 bij 100 groot is. Dus voor elk element in het array, is er één thread. Hoe dat precies is ingedeeld, bijvoorbeeld 10 bij 10 blocks met elk 10 bij 10 threads, is nu nog niet belangrijk. We gebruiken in dit geval de globale constanten threadidx, blockidx en blockdim die door CUDA worden gedefiniëerd. Bijvoorbeeld x verkrijgen we met: // in mykernel() const int x = threadidx.x + blockdim.x * blockidx.x; Analoog zijn ook y en een eventuele z af te leiden. Vervolgens moeten we onze kernel aanroepen en eerst bepalen we daartoe hoe het grid precies ingedeeld zal worden: const int N = 100; // Aantal rijen en kolommen in ons array const dim3 blocksize( 10, 10 ); // Aantal threads per block // Aantal blocks. let op: deze deling kan een rest hebben! const dim3 numblocks( N / blocksize.x, N / blocksize.y ); Het totaal aantal blocks is dus afhankelijk van de blocksize en het aantal elementen. Verschillende verhoudingen zijn mogelijk die elk hun voor- en nadelen hebben. Het fine-tunen van de blocksize kan een performancewinst geven. Let wel op dat er een maximum aantal threads per block is en dat dit verschilt per architectuur versie. Tot slot roepen we nu onze kernel aan, in zijn simpelste vorm: mykernel<<<numblocks,blocksize>>>(dev_a, dev_b, N); Tussen de driedubbele vishaken vinden we achtereenvolgend de blocksize en het aantal blocks terug. Een optionele derde parameter geeft mee hoeveel bytes shared memory moeten worden gereserveerd per block. In de API documentatie vind je meer hierover. Nu hebben we echter nog een A en B nodig... 2

3 2.2 Device memory management Om de arrays A en B voor onze kernel te maken, hebben we toegang nodig tot het geheugen van de GPU ( device memory, het geheugen van de CPU heet host memory ). De versie van CUDA die wij gebruiken ondersteunt alleen de meest simpele vorm van device memory management. Dit bestaat uit twee operaties: handmatig alloceren/vrijgeven en kopiëren van en naar device memory. Alloceren doen we met de functie cudamalloc(void** devptr, size t size) (vergelijkbaar met de C-functie malloc()). Zoals je ziet heeft deze functie twee parameters ipv. één. Het eerste argument is een pointer naar een zgn. device pointer. Een device pointer bevat een geheugenadres dat zich in het videogeheugen bevindt en is dus niet af te lopen vanuit de CPU. Toch kunnen we deze pointer opslaan en hem later meegegeven aan een kernel zodat deze het corresponderende videogeheugen kan benaderen. Eerst zullen we dus de arrays A en B alloceren op de GPU: int *dev_a, *dev_b; if( cudamalloc( &dev_a, N )!= cudasuccess ) // Handel fout af // Analoog voor B Merk op dat we in CPU code een device pointer vaak beginnen met dev of d om verwarring te voorkomen. Het aflopen van een device pointer op de CPU resulteert namelijk een onzinnige/illegale memory operatie! We kunnen echter wel lezen en schrijven naar het videogeheugen met behulp van de functie cudamemcpy(). Deze functie kent de volgende parameters: cudaerror_t cudememcpy( void* dst, const void* src, size_t count, enum cudamemcpykind ) De eerste drie argumenten lijken op de gewone memcpy(), terwijl het vierde argument aan CUDA vertelt in welke richting de bewerking plaatsvindt. Er zijn vier mogelijkheden, waarvan we in elk geval cudamemcpyhosttodevice en cudamemcpydevicetohost nodig hebben. In het eerste geval is dst dus een device pointer en src een gewone pointer, bij het tweede vice-versa. Het kopiëren van A naar de GPU zou er dus als volgt uit kunnen zien: int A[N][N]; // Initialiseer op de host int *dev_a; // Device pointer if( cudamemcpy( dev_a, &A[0][0], N*N, cudamemcpyhosttodevice )!= cudasuccess ) // Handel fout af Na het uitvoeren van de kernel moet er dus nog een soortgelijke operatie plaatsvinden waarbij het resultaat in array B weer wordt gekopiëerd naar het host geheugen. Dergelijke operaties kunnen veel tijd kosten als de dataset groot is en het is dan ook zaak om zorgvuldig te plannen wanneer er het beste gekopiëerd kan worden. In het geval van onze image pipeline kunnen we bijvoorbeeld volstaan met de bronafbeelding eenmaal te kopiëren en na afloop het resultaat op te halen. Verder is het ook mogelijk een cudamemcpy() opdracht asynchroon te draaien, zodat de CPU in de tussentijd iets anders kan doen. Zie hiervoor de gelinkte API documentatie. 2.3 Fout afhandeling Bijna alle cuda* functies geven een foutcode in de vorm van cudaerror t. Net als bij bijvoorbeeld Unix system calls is het altijd wenselijk om deze foutcodes te inspecteren en eventueel af te vangen. In het startpunt is in het bestand image cuda.cu reeds de macro CUDA ASSERT gedefiniëerd. Door CUDA calls in deze macro te verpakken wordt het programma automatisch afgebroken als er een fout optreedt: CUDA_ASSERT( cudamemcpy( dev_a, A, N, cudamemcpyhosttodevice ) ); 2.4 Afbeeldings-arrays en verpakte RGBA Hoewel we met tweedimensionale afbeeldingen werken worden deze gewoonlijk opgeslagen in een ééndimensionaal array. Om toch makkelijk een pixel te kunnen vinden voor een bepaalde (x, y), 3

4 kun je het bekende rekensommetje A[x + W y] (column-major) of A[y + H x] (row-major) gebruiken. In het bestand util.h is echter ook de macro GET PIXEL gedefinëerd: deze neemt vijf argumenten en geeft een pointer naar de pixel terug. Deze argumenten zijn achtereenvolgend een pointer naar het eerste element (of het array), de breedte, de hoogte, en de x en y. Het bijkomende voordeel is dat deze macro automatisch clamp to border simuleert: als je probeert voorbij de afbeelding te lezen wordt een pointer naar de dichtsbijzijnde rand geretourneerd (handig voor blur!). De GET PIXEL macro werkt op zowel host- als device pointers. Alle afbeeldings-arrays zijn van het type uint32 t en bevatten één element per pixel. Dit betekent dat er 32 bits per pixel worden gereserveerd en wel volgens het RGBA8888 schema. In RGBA8888 bestaat iedere pixel uit vier kanalen van elk 8 bits: rood, groen, blauw en alpha. Rood is hierbij de meeste significante byte, alpha de minst significante byte. Om bijvoorbeeld het rode kanaal te extraheren doet men: uint32_t pixel = *GET_PIXEL( A,w,h,x,y ); int rood = ( pixel >> 24 ) & 0xff; En zo analoog voor de andere kanalen. Het alpha kanaal geeft dekkendheid (opacity) weer en moet in ons geval altijd 0xFF blijven. De meeste operaties op een afbeelding worden echter in het floating-point domein uitgevoerd, terwijl onze arrays uit integers bestaan. Om dit op te lossen gaan we de pixels in- en uitpakken. Met inpakken bedoelen we het encoderen van een vector < r, g, b, a > als één integer, terwijl uitpakken de omgekeerde operatie is. Zolang men in het float-domein werkt hebben alle kanalen 32 bits precisie, na het inpakken is dit slechts 8 bits. Daarom, nog afgezien van de performance, moet in- en uitpakken tot een minimum worden beperkt. Het bestand util.h definiëert een aantal handige macro s waarmee deze operaties makkelijker worden gemaakt. Ter illustratie het onderstaande voorbeeld: /* We halen een pixel uit A, vermenigvuldigen deze met een constante factor en schrijven deze weer terug */ uint32_t pixel = *GET_PIXEL( A,width,height,x,y ); // Pak een pixel (x,y) uit A float4 pixel_rgba, factor, result; RGBA( factor,.5f,.5f,.5f, 1.f ); // factor = ( ) RGBA_unpack( pixel_rgba, pixel ); // pak pixel uit RGBA_mult( result, pixel_rgba, factor ); // result = pixel_rgba * factor RGBA_pack( pixel, pixel_rgba ); // pak pixel weer in *GET_PIXEL( A,width,height,x,y ) = pixel; In de host code wordt het type rgba t gebruikt om een vector met vier (float) componenten te representeren. Deze componenten kunnen ook individueel benaderd worden met de members x, y, z, w. Op die volgorde corresponderen zij met de kanalen r, g, b en a. Dus my rgba.z geeft het blauwe kanaal. In de CUDA code moet het ingebouwde type float4 worden gebruikt ipv. rgba t.. Deze twee typen werken verder op exact dezelfde manier. 3 Filters De huidige image pipeline bevat drie filters: gamma correctie, selective grayscale en Gaussian blur. Hoewel het voor het porten van de codes niet strikt noodzakelijk is om te weten hoe deze filters werken, lichten we deze drie filters we beknopt toe. 3.1 Gamma correctie Gamma correctie is ooit bedacht om te corrigeren voor de niet-lineaire respons van de CRT monitor. Hoewel het in het LCD-tijdperk niet meer nodig is, heeft men voor compatibiliteit toch besloten om het te handhaven. Een LCD scherm simuleert daarom het gedrag van de oude CRT 4

5 monitor en verwacht daarom dat alle beelden als gamma-2.2 worden aangeleverd. Onze pipeline neemt een lineaire afbeelding als invoer en de eerste stap is dan ook om daar gamma 2.2 correctie op los te laten. Men berekent de gamma correctie L van een willekeurig kanaal L als volgt: L = L 1/2.2 Zo n exponentiële functie is nogal traag, vandaar deze in de host code is vervangen door een LUT (look-up table). Voor elke mogelijke invoerwaarde bevat de LUT een target waarde in gamma-2.2. Omdat er maar 8 bits per kanaal zijn, is de LUT relatief klein. Zie ook de file gamma.h. Met de LUT is het verder een kwestie van elke pixel vervangen door zijn nieuwe waarde. Deze filter is geïmplementeerd in image.c/image applygamma(). 3.2 Selective grayscale Selective grayscale converteert een deel van een afbeelding naar grijswaarden, maar behoudt een ander deel in kleur. In dit geval is gekozen om één kleur te behouden en de rest grijs te maken. Een kleur wordt opgegeven als een hue op de kleurcirkel: deze loopt van 0 tot 360 waarbij 0 = 360 = rood. De functie image.c/image computehue() wordt vervolgens gebruikt om de hue van een gegeven rgba vector te berekenen. Als deze hue binnen de gegeven hue (en +/- het argument spread) ligt, blijft de kleur behouden. In alle andere gevallen berekenen we de grijswaarde. Die grijswaarde Y berekenen we aan de hand van de volgende formule: Y = A(0.2126R G B) Deze filter is geimplementeerd in image.c/image selectivegrayscale(). 3.3 Gaussian blur De Gaussiaanse blur is een optisch niet-accurate vervaging waarbij de omliggende pixels volgens de Gaussiaanse functie worden gewogen. Het gewicht dat aan een bepaalde buurpixel wordt toegekend heet een coëfficiënt. De mate van vervaging en het aantal betrokken buurpixels wordt bepaalt door de parameter σ in de Gaussiaanse functie: f(x) = 1 µ)2 exp( (x 2σ2 π 2σ 2 ) De eerste term is constant, wordt vooraf berekend en wordt ook wel de normalisatie factor genoemd. In de tweede term wordt (x µ) vervangen door i. i is steeds een discrete afstand tussen de oorspronkelijke pixel en de buurpixel: hoe verder weg, hoe groter i, hoe kleiner de invloed van die pixel. Afhankelijk van de implementatie, worden er 3σ buurpixels aan elke kant (links, rechts, onder, boven) gebruikt. Meestal worden de verticale en horizontale richting apart uitgevoerd, waarbij de eerste als invoer voor de tweede dient. Hierdoor onstaat er eigenlijk een matrix aan coëfficiënten met de afmetingen N = M = 6σ + 1. Deze matrix noemt men ook wel de Gaussian kernel (niet te verwarren met een kernel in CUDA). Hoe deze kernel precies moet worden toegepast op iedere pixel is een bron van discussie: elke coëfficiënt kan steeds worden berekend of alle coëfficiënten kunnen vooraf in een 2D array worden geplaatst (er zijn nog meer opties!). Welke methode het beste werkt is afhankelijk van vele factoren, waaronder het type hardware. De CPU implementatie in image.c/image gaussianblur() gebruikt de naïeve methode waarbij de coëfficiënten steeds opnieuw worden berekend. 4 Optimalisatie De stream-processor architectuur van de GPU verschilt dermate van de reguliere processor dat de meeste code die 1:1 geport is vanaf de CPU, niet het maximale uit de hardware zal halen. Door 5

6 aanpassingen aan de CUDA code te maken kunnen we de performance verbeteren. Voordat we deze aanpassingen kunnen maken, moeten we weten waar de performanceproblemen zich voordoen. We kunnen verschillende parameters meten. We zullen hier kijken naar occupancy en de throughput. 4.1 Occupancy en throughput Bij occupancy kijken we naar de resources in GPU die daadwerkelijk door ons programma gebruikt worden. Een voorbeeld hiervan is het aantal threads: stel dat een bepaalde GPU maximaal 2048 threads per block kan draaien, maar blijkt dat een specifiek programma maar in 512 threads per block gedraaid wordt. De occupancy zou ons dan bijvoorbeeld kunnen leren dat het aantal registers dat per thread wordt gebruikt, een bottleneck vormt - er zijn immers maar een beperkt aantal registers per block beschikbaar. Een mogelijk actie zou dan kunnen zijn om het aantal gebruikte registers te beperken, indien mogelijk. We kunnen het gedrag van CUDA programma s tijdens het draaien meten mbv. een profiler. Hiervoor gebruiken we nvprof (dat sterk lijkt op Linux perf). Onderstaande aanroep geeft een lijst met mogelijke grootheden die we tijdens de executie van ons programma kunnen vastleggen. source /vol/share/groups/liacs/scratch/ca2016/ca2016.bashrc nvprof --query-events Verder kun je nvprof op het programma van deze opdracht met bijvoorbeeld: nvprof -s./ca_cuda../test2048.bmp De opgenomen informatie wordt naderhand naar mijnlog.txt weggeschreven. Het gebruik van nvprof is redelijk ingewikkeld en voor deze opdracht is het ook toereikend om naar de throughput te kijken. De throughput wordt in het startpunt al berekend voor zowel de CPU als de GPU. We gebruiken hiervoor de grootte van de invoerafbeelding en delen die door de tijd die het kost om deze te verwerken. De throughput geeft daarmee een makkelijke indicatie of en hoeveel de performance verbetert, maar het is niet zo precies als de occupancy. 4.2 Branching De stream processors werken optimaal als alle threads in een warp precies hetzelfde doen. Bij bijvoorbeeld if-condities is hier niet altijd sprake van: sommige threads moeten wel de if-clause uitvoeren en andere niet. Wat er in feite gebeurt is dat alle threads de if-clause uitvoeren, maar alleen die threads waarvoor de if-clause true was zullen de resultaten van de berekening wegschrijven (vergelijk predicated instructies en masking uit vectorarchitecturen). Dus bij het gebruik van veel if-condities bestaat het gevaar dat sommige threads regelmatig nutteloos werk verrichten wat de efficientie niet ten goede komt. Voor eenvoudige if-statements probeert de CUDA compiler predicated instructies te genereren, zoals hierboven omschreven. Voor inwikkeldere gevallen is dit niet mogelijk. Deze treden bijvoorbeeld op bij loops waar gebruik wordt gemaakt van een conditionele break. Sommige threads springen al uit de loop, andere niet. In zo n geval moeten de threads met een kort executie pad wachten op de threads met een langer executie pad om zo te synchroniseren. Dit noemt men divergence en dit is iets dat je wanneer mogelijk wilt vermijden. 4.3 Shared memory Naast global memory beschikt elk (thread)block ook over een stukje shared memory. Dit is een klein (meestal KB), maar supersnel geheugen dat door alle threads binnen hetzelfde block toegankelijk is. Dit shared memory is toegankelijk als één groot array vanuit de kernel en zowel statisch (grootte vooraf bekend) als dynamisch te alloceren. Aangezien de dynamische allocatie in de meeste gevallen het handigste is, volgt daarvan een klein voorbeeld: 6

7 // Kernel global void dynamicreverse(int *d, int n) { extern shared int s[]; int t = threadidx.x; int tr = n-t-1; s[t] = d[t]; syncthreads(); d[t] = s[tr]; } // Aanroep dynamicreverse<<<1,n,n*sizeof(int)>>>(d_d, n); Een aantal zaken zijn hier belangrijk: het dynamische shared memory wordt met de extern shared storage class gedeclareerd en kan slechts één type hebben. Verder wordt in de aanroep naar de kernel een derde parameter tussen de vishaken meegegeven: de grootte die voor het shared memory moet worden gereserveerd in bytes. Tot slot blijkt uit deze code nog een ander belangrijk concept, namelijk de synchronisatie barrière. Door de functie syncthreads() aan te roepen, wordt gewacht totdat alle threads in dat block de instructies tot aan de barrière hebben uitgevoerd. De voorbeeldcode gebruikt dit mechanisme om later een read-after-write te voorkomen. De bovenstaande code en nog meer uitleg over shared memory zijn op de onderstaande URL te vinden: Inspiratie voor optimalisaties Vanwege het ontwerp van de architectuur is een memory operatie in CUDA vrij kostbaar. Met name random-access patronen kunnen de performance zeer nadeling beïnvloeden. Daarom richten veel optimalisaties zich op het verbeteren van de memory-access patronen en het vermijden van geheugentoegang. Soms is het daarom beter om extra rekenwerk te verrichten, dan om die waarden tussentijds op te slaan. Een aantal suggesties zijn dan: De gamma functie gebruikt een LUT, die staat ook in het global memory. Vervang de LUT door de gamma functie, verbetert er iets? Of heeft het meer zin om per thread meerdere pixels te berekenen? En dan in een thread block als eerste de LUT uit globaal geheugen te laden en in shared memory op te slaan? Of is berekenen aan de hand van een functie en direct opslaan in shared memory juist sneller? De Gaussian blur bewaart de eerste pass in de invoer array en gebruikt deze als invoer voor de tweede pass. Door maar één pass te gebruiken, zou je het aantal memory operaties kunnen halveren. Hoe zou je dit aan moeten pakken? Kun je hier ook shared memory gebruiken? Er zijn ook nog diverse andere ingrepen te bedenken die de performance zouden kunnen verbeteren. Denk bijvoorbeeld aan: Vervang de tijdelijke buffers door arrays van het type float4 en sla zo het tussentijdse in- /uitpakken van de RGBA data over. Deze tijdelijke buffers zullen daardoor groter worden (16 Bpc ipv 4 Bpc), maar het levert wel een prestatiewinst op. Experimenteer met de blocksize. Meer of minder threads per block kan de occupancy beïnvloeden en daarmee de prestaties. Probeer meer werk per thread te doen (threads hebben ook een kleine overhead). Je zult dan een for-loop schrijven in de kernel en het aantal thread blocks verkleinen. 7

8 Gebruik zoveel mogelijk een vector (type float4) ipv losse componenten. Heeft het zin om gamma correctie en greyscale te combineren in een enkele kernel? Voor blur: geeft een single-pass implementatie betere performance vergeleken met een twopass implementatie? Kun je in een single-pass implementatie goed gebruik maken van shared memory om de performance te verbeteren? We dagen je natuurlijk ook graag uit om eigen optimalisaties te verzinnen en te testen. Zorg in alle gevallen dat je even kort in je verslag toelicht waarom een bepaalde optimalisatie zou moeten werken en wat je in de praktijk gevonden hebt. 4.5 Verdere mogelijkheden Er zijn nog veel meer mogelijkheden, zoals bijvoorbeeld het gebruik van de hardware texture-units. Deze kunnen worden benaderd via texture references en surfaces. We zullen deze in dit document niet verder bespreken. Als je hier meer over wilt leren, verwijzen we je naar de (zeer) uitgebreide CUDA documentatie: 8