Institutionen för systemteknik

Transkript

1 Institutionen för systemteknik Department of Electrical Engineering Examensarbete Signal- och bildbehandling på moderna grafikprocessorer Examensarbete utfört i Bildkodning vid Tekniska högskolan i Linköping av Erik Pettersson LITH-ISY-EX--05/3761--SE Linköping 2005 Department of Electrical Engineering Linköpings universitet SE Linköping, Sweden Linköpings tekniska högskola Linköpings universitet Linköping

2

3 Signal- och bildbehandling på moderna grafikprocessorer Examensarbete utfört i Bildkodning vid Tekniska högskolan i Linköping av Erik Pettersson LITH-ISY-EX--05/3761--SE Handledare: Examinator: Ulf Gustafsson Saab Bofors Dynamics Folke Isaksson Saab Bofors Dynamics Ingemar Ragnemalm isy, Linköpigs universitet Linköping, 15 december, 2005

4

5 Avdelning, Institution Division, Department Image Coding Group Department of Electrical Engineering Linköpings universitet S Linköping, Sweden Datum Date Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport ISBN ISRN LITH-ISY-EX--05/3761--SE Serietitel och serienummer Title of series, numbering ISSN URL för elektronisk version Titel Title Signal- och bildbehandling på moderna grafikprocessorer Signal and image processing on modern GPUs Författare Author Erik Pettersson Sammanfattning Abstract The modern graphical processing unit, GPU, is an extremely powerful unit, potentially many times more powerful than a modern microprocessor. Due to its increasing programmability it has recently become possible to use it in computation intensive applications outside its normal usage. This work investigates the possibilities and limitations of general purpose programming on GPUs. The work mainly concentrates on signal and image processing although much of the principles are applicable to other areas as well. A framework for image processing on GPUs is implemented and a few computer vision algorithms are implemented and evaluated, among them stereo vision and optical flow. The results show that some applications can gain a substantial speedup when implemented correctly in the GPU but others can be inefficent or extremly hard to implement. Nyckelord Keywords GPU, GPGPU, image processing, computer vision, stereo vision, optical flow

6

7 Abstract The modern graphical processing unit, GPU, is an extremely powerful unit, potentially many times more powerful than a modern microprocessor. Due to its increasing programmability it has recently become possible to use it in computation intensive applications outside its normal usage. This work investigates the possibilities and limitations of general purpose programming on GPUs. The work mainly concentrates on signal and image processing although much of the principles are applicable to other areas as well. A framework for image processing on GPUs is implemented and a few computer vision algorithms are implemented and evaluated, among them stereo vision and optical flow. The results show that some applications can gain a substantial speedup when implemented correctly in the GPU but others can be inefficent or extremly hard to implement. Sammanfattning En modern grafikprocessor är oerhört kraftfull och har en prestanda som potentiellt sett är många gånger högre än för en modern mikroprocessor. I takt med att grafikprocessorn blivit alltmer programmerbar har det blivit möjligt att använda den för beräkningstunga tillämpningar utanför dess normala användningsområde. Inom det här arbetet utreds vilka möjligheter och begränsningar som uppstår vid användandet av grafikprocessorer för generell programmering. Arbetet inriktas främst mot signal- och bildbehandlingstillämpningar men mycket av principerna är tillämpliga även inom andra områden. Ett ramverk för bildbehandling implementeras och några algoritmer inom bildanalys realiseras och utvärderas, bland annat stereoseende och beräkning av optiskt flöde. Resultaten visar på att vissa tillämpningar kan uppvisa en avsevärd prestandaökning i en grafikprocessor jämfört med i en mikroprocessor men att andra tillämpningar kan vara ineffektiva eller mycket svåra att implementera. v

8

9 Tack Den här rapporten dokumenterar ett examensarbete som utfördes under hösten 2005 på Saab Bofors Dynamics i Linköping. Jag skulle särskilt vilja tacka följande personer: Ingemar Ragnemalm vid ISY, Linköpings Universitet, för intressanta diskussioner, synpunkter och kommentarer. Ulf Gustafsson vid Saab Bofors Dynamics, handledare för examensarbetet, för intressanta synpunkter och hjälp under arbetets gång. Folke Isaksson vid Saab Bofors Dynamics, handledare för examensarbetet, för stor hjälp under arbetet. Henrik Ejnarsson min opponent, för värdefulla synpunkter. vii

10

11 Innehåll 1 Inledning Bakgrund Mål Ordlista Rapportens struktur Grafikprocessorn Grafikprocessorns beräkningsflöde Vertex-processorn Rasteriseringsenheten Fragment-processorn Framebufferten Grafikprocessorns utveckling I tidernas begynnelse, fram till Första generationen, c:a Andra generationen, c:a Tredje generationen, c:a Fjärde generationen, c:a Femte generationen, c:a 2004 nu Framtiden Programspråk för shader-programmering Renderman ARB vertex program / ARB fragment program Cg / HLSL GLSL Prestandamätningar Moores lag Generella beräkningar på GPUer Programmeringsmodell för GPGPU Grafikprocessorns minnesmodell Grafikprocessorn som flödesmaskin Datastrukturer Flyttal ix

12 x Innehåll 3.4 Representation av gråskalebilder Packa närliggande bildpunkter Packa kvadrantvis Packa flera bilder Indirekt läsning och skrivning Sortera adresser Vertex-processorn Reducering Villkorliga satser Databeroende programhopp Early Z-Cull Domänuppdelning Hjälpbibliotek Brook for GPUs Sh Relaterat arbete Bildbehandling FFT Strålföljning Global illumination Rörelseestimering Signalbehandling Linjär algebra Sortering och sökning Implementation Grafikbibliotek Shader-språk Rendering till textur Pbuffers Framebuffer object Nerladdning och tillbakaläsning Uppbyggnad Beräkningsflöde Beräkningskedjor Exempel Tillämpningar Faltning Faltning med icke-packade bilder Faltning med horisontellt packade bilder Geometrisk omsampling Linjära transformationer Ickelinjära transformationer Packade format

13 6.3 Optiskt flöde Teori En fasbaserad metod Skalpyramid Lågpassfilter Analys Stereofilter Analys Resultat Stereofiltret Optiskt flöde Kvalikativ jämförelse Prestanda Nerladdning och tillbakaläsning Diskussion Framtida arbete Slutsats Litteraturförteckning 61

14 xii Innehåll

15 Innehåll 1 Figurer 2.1 Flödesschema över en modern grafikprocessor Rasteriserad triangel Utveckling i grafikrprocessorers prestanda Utökad modell över en modern grafikprocessor Packad gråskalebild Packad gråskalebild Kvadtrantvis packad gråskalebild Kvadtrantvis packad gråskalebild utökad med ram Stegvis reducering för att hitta max-elementet Villkorliga satser med databeroende programhopp Villkorliga satser med Early Z-Cull Parallel bitonic merge sort Ett beräkningssteg Filterkärna för sobel-x Faltningskärna i fyra versioner Faltning utförd på bild i packat format Transformation med repeterad inbild och repeterad yttre ram Transformation Ickelinjär transformation i fragmentprocessor resp. vertexprocessorn Fel vid transformation av packade bildformat Beräkning av optiskt flöde med skalpyramid Icke-rekursivt lågpassfilter Inbilder till stereofiltret Resultat från stereofiltret Resultat stereofilter, 5 skalor Resultat stereofilter, 1 skala Testbilder till optiskt flöde Resultatbilder från referenslösningen för optiskt flöde Resultatbilder från optiskt flöde Resultat optiskt flöde, 5 skalor Resultat optiskt flöde, 1 skala Överföringshastigheter

16 2 Innehåll Tabeller 2.1 Shader-modeller Uppbyggnad av flyttal i GPUer Största och minsta värde för flyttal i GPUer Avrundnigsfel för flyttal i GPUer Resultat från stereofiltret Resultat från optiskt flöde

17 Kapitel 1 Inledning 1.1 Bakgrund Saab Bofors Dynamics AB 1 påbörjade under hösten 2004 ett projekt som går ut på att i realtid, med hjälp av videokameror, spåra och följa fotbollsspelare under pågående fotbollsmatcher. Informationen kan sedan användas för att skapa olika former av statistik, till exempel hur långt varje spelare har sprungit och var de har befunnit sig. Man kan även tänka sig att använda det som hjälpmedel för domare, ett exempel är införandet av en virtuell offsidelinje där det automatiskt upptäcks om den överträds. Systemet bygger på ett antal kamerapar som sätts upp runt om planen. Från varje kamerapar kommer en strömmande sekvens bildpar ur vilka en djup-bild beräknas med en algoritm för stereoseende. Utifrån de bilderna byggs en höjdkarta över hela fotbollsplanen upp. Med den höjdkartan beräknas spelarnas position och förflyttning för att på så sätt hålla koll på exakt var varje spelare befinner sig. Själva algoritmen fungerar bra, men problemet är att beräkningarna är väldigt tunga. För att det ska gå att köra i realtid så krävs det för närvarande ett kluster av flera snabba PC-maskiner. Utrustningen måste flyttas runt väldigt ofta, och det är både dyrt och opraktiskt med så många datorer. En idé man kom på för att minska mängden utrustning var att på något sätt utnyttja dagens snabba grafikkort för att avlasta processorerna. Grafikkorten blir allt mer kraftfulla; de snabbaste korten idag har en beräkningskapacitet på upp till 200 Gflop och en minnesbandbredd på 40 GB/s och blir mer och mer programmerbara för varje ny generation. 1.2 Mål Målet med arbetet är att utforska om det är möjligt att använda den potentiella kraften i dagens snabba grafikkort till bild- och signalbehandlingstillämpningar, främst med inriktning mot de algoritmer som används av fotbollsprojektet. 1 Se 1

18 2 Inledning En testimplementation inriktad mot bildbehandling ska implementeras och utvärderas. Ett antal algoritmer ska realiseras, främst de som används av fotbollsprojektet, exempelvis stereofiltret. För att enkelt kunna integrera beräkningar på grafikprocessorer i andra redan projekt så ska programmet integreras med ett redan existerande och för Saab internt bildbehandlingsramverk som för närvarande enbart använder CPUn för beräkningar. 1.3 Ordlista Cg C-liknande högnivåspråk för programmering av fragment- och vertexprocessorn. fragment Blivande bildpunkt i resultatbilden vid utritning. fragment-processor Beräkningsenhet i en grafikprocessor som utför beräkningar på enskilda bildpunkter, pixlar. framebuffert Minnesbuffert på grafikkort till vilket den utritade bilden skrivs. Gflop Prestandamått mätt i miljarder flyttalsoperationer per sekund. GPU Graphical Processing Unit, grafikprocessor, processorn som sitter på ett grafikkort. GPGPU General Purpose computation on GPUs, Att använda en grafikprocessor för att utföra generella beräkningar. MIMD Multiple Instruction, Multiple Data, vektorprocessorakitektur som kan exekvera olika instruktioner på flera dataströmmar samtidigt. rasterisera Att omvandla ett grafiskt primitivt objekt till noll eller flera fragment, där varje fragment motsvarar en bildpunkt i resultatbilden. shader-språk Språk som används inom datorgrafiken för att beskriva ljusoch färgsättning av objekt. SIMD Single Instruction, Multiple Data, vektorprocessorakitektur som exekverar en gemensam instruktion på flera dataströmmar samtidigt. texel Texturelement, bildpunkt i en bild när den används som textur. textur Bitmappad bild använd för färgläggning av utritade objekt. ULP Units in Last Place, mått på avrundningsfel för flyttal. vertex En vektor i 2D- eller 3D-rummet med ett eller flera associerade värden. vertex-processor Beräkningsenhet i en grafikprocessor som utför beräkningar på vektorer och grafiska primitiva objekt som trianglar och polygoner.

19 1.4 Rapportens struktur Rapportens struktur För att få en uppfattning om rapportens struktur ges här en kort sammanfattning om varje kapitel. Kapitel 1: Inledning Första kapitlet beskriver bakgrunden till exjobbet och specificerar uppgiften. Kapitel 2: Grafikprocessorn Det här kapitlet beskriver hur grafikprocessorn är uppbyggd och vilka beräkningsmodeller den följer. En genomgång av grafikprocessorns utveckling under de 10 senaste åren återfinns också. Kapitel 3: GPGPU Här beskrivs grafikprocessorn ur ett GPGPU-perspektiv och vad som gör den annorlunda att programmera jämfört med en mikroprocessor. Det finns en genomgång om vilka klasser av algoritmer som är implementerbara och vad grafikprocessorns beräkningsflöde sätter för begränsningar. Kapitel 4: Relaterat arbete I det här kapitlet ges exempel på vad som hittills gjorts inom området, dels inom bildbehandling, men även från andra områden. Kapitel 5: Implementation Här beskrivs implementationen av ramverket för bildbehandling på GPUer. Kapitel 6: Tillämpning Bildbehandlingsramverket användes till att implementera flera filter. Här beskrivs framför allt stereofiltret, optiskt flöde och några olika omsamplingsfilter. Kapitel 7: Resultat Här återfinns resultat och prestandamätninger från diverse testkörningar. Kapitel 8: Diskussion Diskussion och slutsats.

20 4 Inledning

21 Kapitel 2 Grafikprocessorn En grafikprocessor, GPU, är den krets på ett grafikkort som utför alla beräkningar och styr kortet. Ett grafikkort är en färdig produkt med en eller flera grafikprocessorer, minne, buss, samt kontakt för anslutning till bildskärm. Det finns ett fåtal stora tillverkare av grafikprocessorer, exempelvis ATI 1 och Nvidia 2, men flera företag som tillverkar grafikkort som använder deras grafikprocessorer. Det här kapitlet kommer att redogöra dels för hur grafikprocessorn är uppbyggd och vilka principer den bygger på, men även i stora drag redogöra för dess utveckling de senaste 10 åren. 2.1 Grafikprocessorns beräkningsflöde En av huvuduppgifterna för moderna grafikprocessorer är att visualisera 3D-grafik på en bildskärm. En grafikprocessor består av ett antal sammankopplade beräkningssteg där varje steg tar emot en dataström från det tidigare steget, bearbetar 1 Se 2 Se Texturminne Lista med grafiska primitiva objekt Vertex-processor Rasteriseringsenhet Fragment-processor Framebuffer Figur 2.1. Flödesschema över hur en modern grafikprocessor är uppbyggd. 5

22 6 Grafikprocessorn Figur 2.2. Rasteriseringsprocessen. En triangel uppbyggd av färgsatta vertex rasteriseras och till varje fragment interpoleras ett färgvärde fram. den, och skickar vidare den bearbetade dataströmmen till nästa steg. Alla steg kan arbeta parallellt. Figur 2.1 visar i stora drag hur de flesta grafikprocessorer idag är uppbyggda, med tyngdpunkt på dess möjligheter att visualisera 3D-grafik. När 3D-grafik ska ritas ut lagras först de texturer som behövs för utritningen i texturminnet. En textur är en bitmappad bild som används för att färgsätta ytorna på de objekt som ritas ut. Utritningen initialiseras sen genom att programmet skickar en ström med ett eller flera geometriska objekt till grafikprocessorn. Dessa objekt är uppbyggda av vektorer och kan beskriva exempelvis punkter, linjer, trianglar eller polygoner i 3D-rymden. Varje vektor kan vara associerad med flera olika värden. Vanliga värden är färg, normalvektorer och texturkoordinater. Tillsammans med dessa värden kallas vektorn för en vertex Vertex-processorn Strömmen med geometriska objekt skickas till vertex-processorn. Vertex-processorn arbetar på enskilda vertexar, och dess viktigaste uppgift är att transformera dem från modell-rymden till vy-rymden samt projicera dem på bildplanet. I moderna GPUer är dock vertex-processorn fullt programmerbar och kan göra komplicerade beräkningar på varje vertex, till exempel uppdatera dess position enligt en godtycklig algoritm eller förändra dess färg beroende på ljuskällors positioner. Direkt efter vertex-processorn genomgår vektorerna ett steg som kallas primitive assembly, där de byggs upp till primitiva grafiska objekt. Primitiva objekt är begränsade till punkter, linjer och trianglar; ett grafiskt objekt som från början beskrev en polygon kommer i det här steget att generera flera trianglar. Objekt som ligger delvis utanför området där de ska ritas ut kommer dessutom att klipps av och på så sätt generera flera mindre objekt innanför utritningsområdet Rasteriseringsenheten Från vertex-processorn kommer en ström med primitiva objekt vilka är behandlade och projicerade till bildplanet. Strömmen skickas vidare till rasteriseringsenheten. Rasteriseringsenheten har som huvuduppgift att dela upp de primitiva objekten i fragment. Varje fragment motsvarar en bildpunkt i den tänkta resulterande bilden. Till varje fragment interpolerar rasteriseringsenheten fram nya värden på varje komponent till vilka vektorerna var associerade. Figur 2.2 visar ett exempel på hur en triangel med färgsatta vertex delas upp i fragment och hur varje fragment får ett framinterpolerat färgvärde.

23 2.2 Grafikprocessorns utveckling 7 Rasteriseringsenheten är i dagsläget inte programmerbar. Det går inte att påverka vilka fragment den genererar annat än genom att ändra positionerna på vektorerna som skickas in och interpoleringen den utför av texturkoordinater och andra värden är begränsad till antingen linjär interpolering eller perspektivkorrekt interpolering med hänsyn till z-koordinaten. I framtiden är det möjligt att även det här steget kommer att bli mer programmerbart Fragment-processorn Från rasteriseringsenheten kommer en ström med fragment som går in i fragmentprocessorn. Fragment-processorn har till uppgift att tilldela varje fragment ett färgvärde utifrån de värden den är associerad med. Fragment-processorn kan fritt läsa data från texturminnet och gör vanligtvis avläsningar med de texturkoordinater fragmentet är associerat med. Fragment-processorn är dock även den fullt programmerbar i moderna grafikprocessorer och kan utföra avancerade beräkningar. För varje fragment skickar fragment-processorn vidare noll eller en bildpunkt. Den kan alltså välja att förkasta ett fragment av olika anledningar, till exempel om den upptäcker att bildpunkten blir skymd av ett annat objekt. Den kan dock inte producera mer än en bildpunkt Framebufferten Strömmen med bildpunkter från fragment-processorn skrivs direkt in i en framebuffert. En framebuffert är en logisk del av grafikminnet och kan bestå av flera buffertar. Framebufferten består framför allt av en färgbuffert där färgen från fragmenten lagras, men även andra buffertar som djupbufferten där fragmentens motsvarande z-koordinat lagras. Vanligtvis visas framebuffertens färgkomponent direkt på en bildskärm, medan djupbufferten och övriga buffertar används i senare beräkningssteg, till exempel för att undvika att skriva över ett redan utritat objekt med ett objekt som logiskt sett ska ligga bakom. 2.2 Grafikprocessorns utveckling Grafikprocessorn har utvecklats oerhört snabbt de senaste åren. Sedan utvecklingen tog fart i mitten av 90-talet har det hänt mycket både vad gäller prestanda och funktionalitet. Ofta brukar man dela in grafikprocessorerna i olika generationer. Det finns ingen självklar indelning att göra, men här är uppdelningen baserad på funktionalitet snarare än prestanda, eftersom grafikprocessorernas funktionalitet är av mycket stor vikt för dess användbarhet inom GPGPU. Framför allt är det ett antal nyckelteknologier som måste finnas för att en grafikprocessor över huvud taget ska gå att använda till generella beräkningar på ett praktiskt sätt.

24 8 Grafikprocessorn I tidernas begynnelse, fram till 1996 Fram till 1996 var de flesta grafikkort avsedda för konsumentmarknaden egentligen inte mycket mer än ett minne och en videosignalsgenerator. Någon egentlig grafikprocessor fanns inte. Det fanns några enstaka försök till att göra accelererade grafikchip för konsumentmarkanden innan dess, men inget av dem fick något stort genomslag. Ett exempel är dock Nvidias NV1-chip som annonserades i maj NV1 var främst avsett för accelererad 3D-grafik, men till skillnad från dagens GPUer som är baserade på vektorer och polygoner använde NV1 generella kvadratiska ytor. Det kunde visserligen producera mycket jämna ytor, men det var mycket svårt att använda det i praktiken. Även så grundläggande och för spel oerhört viktiga saker som kollisionsdetektering visade sig mycket svårt att göra effektivt med kvadratiska ytor. Det var heller inte ovanligt att dessa tidiga specialiserade kort inte var speciellt mycket snabbare, eller till och med långsammare, än att låta beräkningarna utföras i mjukvara av processorn. Värt att notera är dock att det redan vid den tiden fanns kort som var kapabla till mer avancerad 3D-accelerering. Dessa kort var dock mycket dyra och främst avsedda för proffesionella arbetsstationer och därmed i praktiken oåtkomliga för vanliga konsumenter. Ett företag som var ledande inom visuella arbetsstationer på den tiden var Silicon Graphics, Inc 3. Vad gäller generella beräkningstillämpningar var dessa kort relativt ointressanta då deras höga pris gjorde att man tappade den stora fördelen med att få stor beräkningskraft för relativt lite pengar Första generationen, c:a I slutet av 1996 inleddes vad som kom att bli en revolution för grafikprocessorer. Det hela startades av ett företag vid namn 3Dfx som hade grundats bara två år tidigare. I augusti 1996 annonserade de sin första produkt: grafikchipet Voodoo 1. Voodoo 1 var uteslutande avsett för 3D-grafik. Faktum är att det över huvud taget inte kunde hantera 2D-grafik vilket gjorde att man vid sidan om det Voodoo 1- baserade grafikkortet var tvungen att ha ett vanligt grafikkort i datorn. Voodoo 1 fick omedelbart genomslag, främst beroende på dess enorma prestanda och visuella kvalitet. I ett steg gick man från 8-bitars grafik med närmsta granne-interpolering av texturer till 16-bitars grafik med linjär interpolering samt ett rejält kliv uppåt i fråga om hastighet. Grafikkort baserade på Voodoo 1-chipet dominerade marknaden i över ett år innan de övriga tillverkarna hann ikapp. Andra grafikprocessorer som räknas in i första generationen är ATI Rage, Nvidia TNT och TNT2 samt 3Dfx Voodoo 2 och Voodoo 3. Gemensamt för alla grafikprocessorer från första generationen är att de alla hade en rasteriseringsenhet i hårdvara, men helt saknade fragment- och vertexprocessor. Alla 3D-transformationer och projiceringar utfördes i mjukvara av CPUn; till grafikprocessorn skickades de redan projicerade grafiska primitiva objekten. Istället för fragment-processor fanns en enhet som läste textursampel och färglade fragmenten, men som inte var kapabel till att göra några beräkningar. I 3 Se

25 2.2 Grafikprocessorns utveckling 9 princip var det enda grafikprocessorn gjorde att rita ut texturerade eller färgade trianglar till grafikminnet, möjligheterna att styra grafikprocessorn i övrigt var mycket begränsade Andra generationen, c:a I augusti 1999 annonserade Nvidia en ny grafikprocessor: GeForce 256. Vad som var revolutionerande med den var inte bara att den var mycket snabbare än allt annat som tidigare fanns på marknaden, utan den kunde dessutom utföra transformationer av 3D-vektorer direkt i hårdvaran. Det var något som dittills hade varit förbehållet den dyraste specialhårdvaran i proffesionella arbetsstationer. Att kalla den tekniken för vertex-processor är dock inte riktigt korrekt, den var mycket begränsad och kunde enbart utföra ett visst antal transformationer och inga generella beräkningar. Den nya tekniken fick dock genast genomslag eftersom det vid den tiden ofta var datorns processor som var flaskhalsen, då den gjorde alla transformationer. Den nya tekniken kunde avlasta en hel del av processorns arbete. Flera andra grafikprocessorer med liknande funktionalitet följde snart, bland dessa finns Nvidia GeForce 2, ATI Radeon 7500 samt S3 Savage 3D. Dessa räknas också till den andra generationen. En annan nyhet som infördes med andra generationen var Nvidias Register Combiners. Med dessa fick man mycket större möjligheter att kombinera olika färgkomponenter på olika sätt på bildpunktsnivå. Färgkomponenter består av olika sampels från texturer, olika ljuskomponenter beroende på ljusmodell, men även andra saker som till exempel dimma. Register Combiners definieras i standarden av Kilgard [31] och förklaras mer av Spitzer [41]. Register Combiners kan sägas vara förstadiet till dagens fragmentprocessorer. De införde en stor del konfigurerbarhet, men inte tillräckligt mycket för att de ska anses vara användbara inom GPGPU och inte tillräckligt programmerbara för att kunna kallas processor Tredje generationen, c:a 2001 Tredje generationen inleddes av Nvidia GeForce 3 som introducerades i februari GeForce 3 var den första GPU som hade en programmerbar vertex-processor (se kapitel 2.1.1) istället för att vara begränsad till några få fasta transformationer. Andra grafikprocessorer som hör till tredje generationen är Nvidia GeForce4 och ATI Radeon De olika tillverkarna enades om en standard, shader-modell, SM, för programmeringsmodellen i grafikprocessorerna. För att en grafikprocessor ska implementera en viss shader-modell så finns det vissa krav den måste uppfylla, bland annat hur långa program grafikprocessorn minst måste ha stöd för. Några exempel på de olika kraven för olika versioner finns i tabell 2.1. Grafikprocessorer från den tredje generationen uppfyller minst SM 1.1. Språket som först introducerades för att skriva programmen som exekveras i vertex-processorn var ett assemblerliknande språk vilket senare kom att bli en del

26 10 Grafikprocessorn SM 1.1 SM 2.0 SM 3.0 Max programlängd fragment-processor Max programlängd vertex-processor Max antal exekverade instruktioner ,535 i fragment-processorn Max antal exekverade instruktioner ,535 i vertex-processorn Nästlade loopar Nej Ja Ja Databeroende programhopp Nej Nej Ja Textursampling i vertex-shader Nej Nej Ja Tabell 2.1. Shader-modeller. av OpenGL-standarden. Språket kallas ARB vertex program, och finns definierat av Akeley m.fl. i [1]. Även om vertex-processorn var programmerbar så var fragment-processorn fortfarande begränsad till Register Combiners. Det kan vara möjligt att implementera vissa GPGPU-algoritmer enbart med vertex-processorn, men det är inte speciellt praktiskt eller enkelt. Av den anledningen kan man inte heller anse tredje generationens grafikprocessor speciellt lämpad för GPGPU Fjärde generationen, c:a Fjärde generationen inleddes även den av Nvidia. I november 2002 släppte de sin nya grafikprocessor GeForce FX. Det var den första generationen som utöver programmerbar vertex-processor även hade programmerbar fragment-processor (se kapitel 2.1.3) vilket medförde möjligheten att skriva godtyckliga program på bildpunkts-nivå. Vertex-processorn uppgraderades till shader-model 2.0, vilket bland annat innebär möjlighet till statiska loopar samt dubbelt så långa program (se tabell 2.1). ATI följde snart efter med Radeon 9700 vilken funktionellt sett var likvärdig med GeForce FX. Även ATIs efterföljande grafikprocessor, Radeon X800, placeras här i fjärde generationen. Många skulle placera den i femte generationen med tanke på att den släpptes nästan samtidigt med Nvidias första generation-femgrafikprocessor samt att den var likvärdig i hastighet med den. Men faktum är att Radeon X800 saknar stöd för shader-modell 3.0, vilket är ett krav för verkligt flexibla GPGPU-implementationer. Fjärde generationen är den första generation som är praktiskt användbar till GPGPU, främst tack vare dess programmerbara fragment-processor. Det är fortfarande inte möjligt att göra databeroende programhopp eller loopar, så algoritmer med mycket villkorliga satser är ineffektiva. Däremot går det mycket bra att implementera linjära filter eller andra algoritmer med fast beräkningsflöde.

27 2.3 Programspråk för shader-programmering Femte generationen, c:a 2004 nu Till den femte generationen räknas de kort som har stöd för shader-modell 3.0. Den första grafikprocessorn som hade det var Nvidias GeForce 6800, vilken släpptes i april Även Nvidias efterföljande grafikprocessor som kom ut i augusti 2005, GeForce 7800, tillhör femte generationen. ATI introducerade under oktober 2005 sin första grafikprocessor i generation fem, Radeon X1800. Det är ATIs första grafikprocessor som har stöd för shader-modell 3.0. Shader-modell 3.0 innebär stora skillnader för GPGPU-programmering. En av de största är stödet för databeroende hopp, vilket gör många algoritmer mycket effektivare att implementera. En annan stor förbättring är maxlängden på program i vertex- och fragment-processorn. För fragment-processorn ökas den från 256 instruktioner till 65,535, vilket är en enorm förbättring för tyngre beräkningar Framtiden Hur utvecklingen kommer att fortsätta i framtiden är svårt att förutspå. Grafikprocessorn kommer helt säkert att bli snabbare och få fler funktioner. En nyhet som troligen kommer att introduceras i nästa generation är unifierad fragment- och vertex-processor, det vill säga en gemensam processor som bearbetar både vektorer och fragment. Detta innebär i praktiken att program inte behöver lastbalanseras mellan vertex- och fragment-processorn då detta kommer att göras dynamiskt och automatiskt. En annan trolig nyhet är införandet av en geometri-processor. En geomtri-processor är placerad före vertex-processorn och arbetar på hela geometriska objekt samtidigt till skillnad från vertex-processorn som bara arbetar på enskilda vertexar. Geometri-processorn kommer att ha möjlighet att både skapa nya och förändra de vertexar den arbetar med. Utöver det har det även ryktats om att tillverkarna ska underlätta för generell programmering bland annat genom förändringar i drivrutinerna. 2.3 Programspråk för shader-programmering Den generella term för de språk man inom datorgrafiken använder för att beskriva färg- och ljussättning är shader-språk. Olika shader-språk har använts en längre tid inom datorgrafiken för att beskriva objekt och ytor, främst för 3D-tillämpningar. De språk som fanns innan den programmerbara grafikprocessorns introduktion var dock inte lämpade för dess uppbyggnad eller ens realtidsapplikationer över huvud taget. De nya språk som tagits fram som är anpassade till programmerbara grafikprocessorer är dock starkt inspirerade av de tidigare shader-språken. Av den anledningen kallas även de språk avsedda för exekvering på grafikprocessorer för shader-språk, och vertex- och fragment-processorn kallas ofta för vertex-shader respektive fragment-shader.

28 12 Grafikprocessorn Renderman Renderman Shading Language är ett av de första generaliserade shader-språken. Det introducerades av företaget Pixar i slutet av 80-talet, se Hanrahan och Lawson [23]. Renderman inspirerades till stora delar av en teknik kallad shade trees som introduceras av Cook [12]. Shade trees generaliserar den klassiska trekomponentsmodellen för ljus- och färgsättning av ytor till att använda godtyckliga trädstrukturer som kombinerar olika komponenter som texturer, yt- och ljuskoefficienter och materialegenskaper. Renderman tog generaliseringen ett steg ytterligare och är ett fullfjädrat programmeringsspråk för ljus- och färgsättning som används inom datorgrafiken. Renderman har fått stort genomslag och är ett av de mest använda språket inom icke-realtids-3d ARB vertex program / ARB fragment program Det första språket för programmering av grafikprocessorer introducerades samtidigt med Nvidias första programmerbara grafikprocessor GeForce 3 (se kapitel 2.2.4). Det var ett assemblerliknande språk vars instruktionsuppsättning låg mycket nära grafikprocessorns egna instruktionsuppsättning. Språket antogs av OpenGL Architecture Review Board och fick namnet ARB vertex program [1]. När sen den första grafikprocessorn med programmerbar fragment-processor släpptes introdudcerades ett motsvarande språk för den: ARB fragment program [4]. De båda språken är trots sin assemblerliknande struktur två för grafikprocessorer generella språk och fungerar på de flesta moderna grafikprocessorer. Det finns inte nödvändigtvis en ett-till-ett-mappning mellan språkets instruktioner och grafikprocessorernas egentliga instruktionsuppsättning. Faktum är att instruktionsuppsättningen på de flesta grafikprocessorer är hemlig. När ett program laddas ner till grafikprocessorn sker det genom de av tillverkarna tillhandahållna drivrutinerna. I drivrutinerna sker själva kompileringen till maskinkod samt ett ytterligare optimeringssteg som programmeraren inte har kontroll över. Här är ett exempel på hur ett ARB fragment program kan se ut. Det är ett enkelt program som gör avläsningar från två texturer och returnerar medelvärdet av dem. 1!!ARBfp1.0 2 # Program som bildar medelvärdet av två texturer 3 PARAM c[1] = { { 0.5 } }; 4 TEMP R0; 5 TEMP R1; 6 TEX R1, fragment.texcoord[0], texture[1], RECT; 7 TEX R0, fragment.texcoord[0], texture[0], RECT; 8 ADD R0, R0, R1; 9 MUL result.color, R0, c[0].x; 10 END

29 2.4 Prestandamätningar Cg / HLSL I takt med att grafikprocessorns kapacitet växte och det blev möjligt att skriva allt längre program så växte också behovet av språk på högre nivå än ARB vertex program respektive ARB fragment program. Det finns idag två större högnivåspråk för shader-programmering. Ett av dem är Cg, designat främst av Bill Mark på Nvidia. Cg står för C for graphics, och är ett C-liknande språk anpassat för grafikprocessorer. Språket beskrivs mycket bra av Fernando och Kilgard [14]. Språket utvecklades i ett samarbete mellan Nvidia och Microsoft, och kallas ofta HLSL när det används i DirectX. Cg används för att programmera både fragment-processorn och vertex-processorn. Det finns implementerat för flera plattformar, bland annat Windows, Linux och MacOS. Så här ser motsvarande Cg-program ut som bildar medelvärdet av två texturer: 1 float4 medel(float2 texcoord : TEXCOORD0, 2 uniform samplerrect tex0, 3 uniform samplerrect tex1) : COLOR0 4 { 5 float4 sample0 = texrect(tex0, texcoord); 6 float4 sample1 = texrect(tex1, texcoord); 7 8 return 0.5f * (sample0 + sample1); 9 } GLSL Det andra språket är GLSL. Det står för OpenGL Shading Language och är utvecklat för OpenGL. Det är till sin uppbyggnad mycket likt Cg, men inte fullt kompatibelt. GLSL är en öppen standard och är en del av den nya OpenGLstandarden 2.0 [38]. Då GLSL är byggt uteslutande för OpenGL är det mycket bra integrerat i OpenGLs API, men med den uppenbara nackdelen är att det inte går att använda från DirectX. GLSL är definierat av Kesselnich m.fl. [30]. 2.4 Prestandamätningar När man mäter prestanda på ett program som använder grafikkort är grafikprocessorn som sitter på kortet i nästan samtliga fall den komponent som har störst inverkan på totalprestandan, men det kan ändå skilja en hel del mellan olika grafikkort som använder samma grafikprocessor. Olika grafikkort med samma grafikprocessor kan ha olika mängd minne, olika snabba och breda minnesbussar eller till och med använda helt olika bussar för kommunikation med datorn. Dessa faktorer påverkar resultaten, och det är viktigt att tänka på att man mäter hela systemets prestanda och inte bara grafikprocessorns prestanda när man utför testkörningar.

30 14 Grafikprocessorn 1000 Miljoner trianglar per sekund Jan 99 Jul 99 Jan 00 Jul 00 Jan 01 Jul 01 Jan 02 Jul 02 Jan 03 Jul 03 Jan 04 Datum Figur 2.3. Grafikprocessorers prestandautveckling mätt i trianglar per sekund. 2.5 Moores lag När man pratar om prestandatillväxt inom datorbranschen relaterar man ofta till Moores lag [34]. Moores lag var en förutspåelse som gjordes av Gordon Moore redan Han sade sade att antalet transistorer som kan placeras på en enda integrerad krets till en fast kostnad skulle fördubblas varje 18-månadersperiod, vilket ger en årlig tillväxtfaktor på knappt 1,6. Förutspåelsen har med några små justeringar stämt förvånansvärt bra ända fram till våra dagar. På senare år har dock Moores lag blivit såpass ofta felciterad och missbrukad att begreppet snarare har kommit att stå för all exponentiell tillväxt inom datorbranschen, vare sig det rör sig om antal transistorer, klockfrekvens eller rena prestandamått. Att mäta grafikprocessorers prestandatillväxt över åren är relativt svårt. Många mått är bara lämpliga på några få generationer, det är till exempel först med de senaste generationerna som det har varit rimligt att göra beräkningar av gigaflop, miljarder flyttalsberäkningar per sekund. Det existerar ett mått som i varje fall kan ge en indikation på grafikprocessorns prestandatillväxt över flera generationer, och det är den högsta möjliga genomströmningshastighet av det mest grundläggande primitiva objektet: triangeln. I figur 2.3 visas hur den högsta möjliga genomströmningshastighet har utvecklats de senaste åren. Man kan se att utvecklingen är ungefärligt exponentiell och att den årliga tillväxtfaktorn ligger på ungefär 2,9. En årlig tillväxtfaktor på 2,9 är nästan dubbelt så snabb tillväxt som Moores lag förutspår, och det visar på den oerhört snabba utveckling av grafikprocessorer som skett de senaste åren.

31 Kapitel 3 Generella beräkningar på GPUer GPGPU, General Purpose GPU programming, är ett samlingsnamn på metoder för att använda grafikprocessorer för generella beräkningar. Nästan uteslutande är det grafikprocessorns beräkningsväg för visualisering av 3D-grafik som används. I det här kapitlet betraktas grafikprocessorn i mer detalj och främst med GPGPUberäkningar i åtanke men utan att gå in för mycket på specifika implementationer eller grafikbibliotek. Först behandlas grafikprocessorns beräknings- och minnesmodell mer ingående och sen utreds hur några viktiga klasser av algoritmer kan utföras på en grafikprocessor. Texturminne Lista med grafiska primitiva objekt Vertex-processor Rasteriseringsenhet Fragment-processor Framebuffer Figur 3.1. Utökad modell över en modern grafikprocessors uppbyggnad. 15

32 16 Generella beräkningar på GPUer 3.1 Programmeringsmodell för GPGPU Grafikprocessorns beräkningsmodell som introducerades i kapitel 2.1 har i och med flera förändringar i de senaste generationerna av grafikprocessorer utökats och generaliserats något. Flera av dessa utökningar är mycket viktiga inom GPGPUprogrammering. I figur 3.1 återges den utökade beräkningsmodellen vilken kan jämföras med den klassiska modellen i figur 2.1. En stor förändring är möjligheten att rendera direkt till texturminnet. På så sätt undviks en onödig dyr kopiering ifall resultatet från ett beräkningspass behöver användas som textur i en följande beräkning. Olika metoder för att göra detta beskrivs mer i kapitel 5.3. En annan viktig förändring är att data från framebufferten kan användas som indata till vertex-processorn. I OpenGL kan det utföras genom utökningen Vertex Buffer Object (VBO) som finns definierad av Hammerstone m.fl. [22]. I och med VBO kan feedback ges ända till början av grafikprocessorns beräkningspipeline och många algoritmer kan realiseras helt utan att data behöver gå via systemminne. Ytterligare en förändring är möjligheten att låta vertex-processorn läsa ur texturminne, vilket introducerades i och med shader-modell Grafikprocessorns minnesmodell Grafikprocessorns minnesmodell skiljer sig ganska stort från minnesmodellen för de flesta mikroprocessorer. Den saknar till exempel helt inbyggt stöd för de för en mikroprocessor mycket viktiga funktionerna stack, heap och minnespekare Grafikprocessorn som flödesmaskin Grafikprocessorn kan enligt Venkatasubramanian [44] med fördel kan betraktas som en flödesmaskin, (stream processor). Processorer som arbetar enligt flödesprogrammeringsmodellen kan på ett mycket effektivt sätt utnyttja parallelliserbarhet för beräkningar och kommunikation. De flesta teorier framtagna för flödesmaskiner är direkt applicerbara på GPUer, och detta är särskilt sant när det gäller GPGPU-tillämpningar. En flödesmaskin arbetar med strömmar. En ström är en ordnad datamängd där alla element är av samma typ. En flödesmaskin använder beräkningskärnor för att bearbeta strömmarna. En beräkningskärna läser en eller flera strömmar och producerar en eller flera strömmar som resultat. Beräkningskärnan utför samma beräkning på varje element och det finns restriktioner på vilka minnesoperationer den kan utföra. Den kan läsa fritt från ett globalt minne men inte göra skrivningar till det. Den kan inte göra läsningar från dataströmmen annat än från det specifika elementet den arbetar på och den kan heller inte spara värden mellan beräkningar av olika element. Det enda värdet som skrivs är elementet eller elementen som skickas ut i resultatströmmen eller -strömmarna. Dessa begränsningar medför att beräkningen av elementen i dataströmmen kan ske i en godtycklig ordning utan att resultatet påverkas.

33 3.3 Datastrukturer 17 En GPU kan ses som en flödesmaskin med tre fast sammankopplade beräkningskärnor enligt figur 3.1. Två av kärnorna är programmerbara: vertex- och fragment-processorn. Rasteriseringsenheten är inte programmerbar men betraktas ändå som en beräkningskärna. Det globala minnet representeras av texturminnet. Faktumet att elementen i en ström kan bearbetas i en godtycklig ordning är en av nyckelanledningarna till att en processor enligt flödesmodellen kan vara så snabb, vilket också utnyttjas i stor grad av grafikprocessorer. Minnet till en grafikprocessor har mycket stor genomsnittlig bandbredd, men det kan ändå vara relativt stor åtkomsttid för en enskild minnesläsning. För att fragment- eller vertex-processorn ska utnyttjas maximalt har de konstruerats så att de snabbt kan växla mellan vilket element de arbetar på. Om en minnesläsning innebär en väntetid så börjar den direkt arbeta på ett annat element och växlar tillbaks till det första elementet när data från minnet är tillgängligt. Fragment-processorer i dagens GPUer har upp till 24 parallella beräkningsvägar, men kan ha flera hundra fragment aktiva under bearbetning. På så sätt kan väntetiderna vid minnesläsningar effektivt döljas och en större genomströmmningshastighet uppnås. 3.3 Datastrukturer Alla större mängder data som ska behandlas på en GPU måste lagras som texturer i grafikprocessorns texturminne. Texturer kan vara en-, två-, eller tredimensionella och kan betraktas som arrayer av motsvarande dimension. Varje texturelement, texel, består av en eller flera skalärer beroende på vilket texturformat som valts. Vanligt är att varje texel består av fyra skalärer tänkta att representera de tre grundläggande färgerna samt en alfa-kanal som representerar transparensen. Det finns även format med färre än fyra komponenter per texel. Skalärerna i sin tur kan vara antingen fixtal eller flyttal. En viktig sak att tänka på är att även om OpenGL rapporterar ett format som giltigt så är det inte säkert att det verkligen är det formatet som används internt. Enligt standarden är OpenGL tillåtet att vid behov välja ett annat liknande format utan att ge felmeddelande, se Segal och Akeley [38] Flyttal Alla moderna grafikprocessorer arbetar på något sätt med flyttal. Det finns flera olika format att välja på beroende på tillverkare. De flesta av Nvidias grafikprocessorer kan hantera ett 16-bitars och ett 32-bitars format. ATIs grafikprocessorer hanterar ett 16-bitars format och ett 24-bitars format. Deras uppbyggnad och egenskaper är något olika mellan de olika formaten. Harris [24] har sammanställt format och uppbyggnad över de vanligaste formaten vilka redovisas i tabell 3.1 och 3.2. Kolumnen Heltal visar inom vilket intervall samtliga heltal kan representeras exakt. För närvarande går det att använda texturer med storlekar på upp till texturelement, men med de båda 16-bitars flyttalsformaten går det bara att exakt adressera enskilda element upp till Detta bör man ha i åtanke ifall stora texturer används.

34 18 Generella beräkningar på GPUer Teckenbit Mantissa Exponent NaN, Inf, etc. Nvidia 16-bit 1 bit 10 bitar 5 bitar Ja Nvidia 32-bit 1 bit 23 bitar 8 bitar Ja ATI 16-bit 1 bit 10 bitar 5 bitar Nej ATI 24-bit 1 bit 16 bitar 7 bitar Nej Tabell 3.1. Uppbyggnad av flyttal i några vanliga grafikprocessorer. Största värde Minsta värde Heltal Nvidia 16-bit ± 2 16 ± 2 14 ±2, 048 Nvidia 32-bit ± ± ±16, 777, 216 ATI 16-bit ± 2 17 ± 2 15 ±2, 048 ATI 24-bit ± 2 64 ± 2 62 ±131, 072 Tabell 3.2. Största och minsta värde för de olika flyttalsformaten samt det omfång för vilka de kan representera alla heltal exakt. Uppförandet vid aritmetiska operationer där resultatet inte kan representeras exakt är inte standardiserat mellan de olika formaten grafikprocessorerna använder. Inget av flyttalsformaten följer den av IEEE uppställda standarden för flyttal, IEEE-754 [28], som säger att avrundningen alltid ska ske till närmsta representerbara tal. Ligger det exakta talet mitt mellan två representerbara tal ska avrundning ske till det udda talet. Avrundningsfel mäts ofta i ULP, units in last place. En ULP är skillnaden mellan två tal där den minst signifikanta siffran i mantissan ändras. För IEEE-754 ligger avrundningsfelet mätt i ULP alltid inom intervallet [ 0.5, 0.5]. Hillesland och Lastra [26] har utvecklat ett verktyg för att empiriskt mäta avrundningsfelet för flyttal i grafikprocessorer. I tabell 3.3 har avrundningsfelet mätts för några aritmetiska operationer för två olika grafikprocessorer: ATI X850 XT och Nvidia GeForce 6800 GT. X850 XT använder 16 bitars mantissa och GeForce 6800 GT använder 23 bitars mantissa. Detta medför att avrundningsfelet på ett GeForce 6800 GT är en 128-del så litet jämfört med X850 XT vid samma avrundningsfel mätt i ULP. I samtliga fall kan man se att felet är större jämfört med IEEE-754. Att felet vid division är märkbart större än för de andra aritmetiska operationerna förklaras av Hillesland och Lastra [26] med att grafikprocessorer ofta inte utför division direkt, utan istället beräknar inversen av nämaren följt av multiplikation med täljaren. Då kommer felet från multiplikationen att ackumuleras med felet från inversen. Att flyttalen inte följer en väldefinierad standard är ofta inget stort problem för grafiska applikationer, men för GPGPU kan det vara värre och det är viktigt att vara medveten om problemen som kan uppstå.

35 3.4 Representation av gråskalebilder 19 ATI Nvidia IEEE-754 X850 XT PE GeForce 6800GT Addition [ 0.5, 0.5] [ 1.000, 0.000] [ 1.000, 0.000] Subtraktion [ 0.5, 0.5] [ 1.000, 1.000] [ 0.750, 0.750] Multiplikation [ 0.5, 0.5] [ 0.988, 0.125] [ 0.781, 0.625] Division [ 0.5, 0.5] [ 2.868, 0.093] [ 1.199, 1.374] Tabell 3.3. Felet i avrundningen för olika operationer och grafikprocessorer mätt i ULP, units in last place. 3.4 Representation av gråskalebilder Inom signal- och bildbehandling vill man ofta arbeta med gråskalebilder. Samtliga moderna GPUer arbetar dock effektivast med bilder där varje bildpunkt innehåller fyra färgkomponenter: röd, grön, blå och en alfa-kanal. Att representera gråskalebilderna som färgbilder där alla komponenter har samma värde är en möjlig lösning, men den är inte bara onödigt minneskrävande, utan också väldigt ineffektiv beräkningsmässigt sett. De flesta operationer i GPUn sker vektorvis på alla fyra skalärer samtidigt, och med den representationen av gråskalebilder skulle alla operationer beräknas fyra gånger Packa närliggande bildpunkter En metod är att ta fyra horisontellt närliggande bildpunkter i gråskalebilden och lagra varje punkt i en av färgkomponenterna i en bildpunkt i en bild med fyra färgkomponenter (se figur 3.2). En gråskalebild med dimensionerna n m kan på så sätt representeras av en färgbild med dimensionerna n/4 m. På det viset kommer man runt problemet med den extra minnesåtgången, och till viss del den extra beräkningsbördan, då många beräkningar kommer att utföras på fyra logiska bildpunkter samtidigt. En nackdel är dock att vissa beräkningar blir svårare att implementera, främst eftersom en logisk bildpunkts horisontella granne blir svårare att adressera. Förskjutningar i horisontalledd bestäms inte enbart av en offset i texturkoordinaterna, utan det blir fyra olika fall beroende vilken av färgkomponenterna den logiska bildpunkten är lagrad i. Vertikalt sett adresseras de logiska bildpunkternas grannar enbart med en offset i texturkoordinaterna. Ett annat sätt är att packa bilden enligt figur 3.3. En gråskalebild med dimensionerna n m kan på så representeras av en färgbild med dimensionerna n/2 m/2. Här uppstår dock problemet med adresseringen av de logiska bildpunkternas grannar både i horisontal- och vertikalled. Den här metoden har mycket små fördelar jämfört med att packa 4 horisontellt intilliggande bildpunkter, men i vissa fall kan det vara av fördel om färgbilden har samma proportioner som originalbilden.

36 20 Generella beräkningar på GPUer Figur 3.2. n m punkters gråskalebild packad till n/4 m punkters färgbild Figur 3.3. n m punkters gråskalebild packad till n/2 m/2 punkters färgbild

37 3.4 Representation av gråskalebilder 21 Figur 3.4. n m punkters gråskalebild packad kvadrantvis till n/2 m/2 punkters färgbild Packa kvadrantvis Ett annat sätt patt packa bilderna föreslogs av Bolz m.fl. [6]. Det går ut på att lagra gråskalebildens kvadranter i de fyra färgkomponenterna (se figur 3.4). En n m pildpunkter stor gråskalebild kan på så sätt representeras av en färgbild på n/2 m/2 bildpunkter. Med den här metoden undviks problemen med adressering av bildpunkters logiska grannar, men bara lokalt. Vid övergången mellan kvadranterna kommer oönskade kanteffekter att uppstå. Det finns en metod att undkomma de effekterna till viss del om man på förhand vet med hur stora förskjutningar bildelements grannar kommer att adresseras. Detta gör man genom att lägga till en ram runt bilden som duplicerar vissa områden. Ramen måste vara minst lika bred som det största avståndet för hur avlägsna grannar som adresseras. I figur 3.5 visas hur en kvadrantvis packad bild utökas med en ram av bredd 1. Låter man ramens bredd vara lika stor som själva bilden finns det ingen begränsning på största värde för hur avlägsna grannar som kan adresseras utan kanteffekter, resultatet blir identiska som med ej packade bilder. Minnesåtgången blir dock 9 gånger så stor som utan ram, och tiden det tar att bygga upp ramen blir såpass stor att det ytterst sällan är lönsamt. Om värdet för hur avlägsna grannar som adresseras är tillräckligt litet eller om man kan acceptera vissa kanteffekter är metoden att packa kvadrantvis potentiellt snabbare än att packa närliggande bildpunkter. Nackdelen är att ramen tar extra minne och tid att skapa Packa flera bilder Ett tredje sätt är att lagra en hel bild i varje färgkomponent och utföra beräkningarna på fyra bilder samtidigt. Fyra gråskalebilder med en storlek av n m bildpunkter representeras av en färgbild på n m bildpunkter. Med den metoden undkommer man helt och hållet problemen med adressering av logiska bildelement, utan extra minnesåtgång. Den här metoden är att föredra om det är möjligt, dock är det inte alltid det är möjligt att bearbeta fyra bilder i taget. I en realtidstillämpning kan en fördröjning på fyra bilder vara oacceptabelt.

38 22 Generella beräkningar på GPUer Figur 3.5. En kvadrantvis packad gråskalebild utökad med ram för enklare adressering av logiska bildelement. 3.5 Indirekt läsning och skrivning Indirekt läsning innebär att under exekvering beräkna ett index som används för att göra en minnesläsning: i = f() res = a[i] Detta implementeras enklast på en grafikprocessor genom att under körning beräkna en eller flera texturkoordinater som sen används för att göra texturläsningar. Detta är mycket enkelt att implementera och det kan utföras med god prestanda. Att göra det motsatta, indirekt skrivning, innebär att ett index som adresserar var ett värde ska skrivas beräknas under körning: i = f() res[i] = b Detta är mycket svårare att utföra på en grafikprocessor eftersom det inifrån fragment-processorn är omöjligt att påverka till vilken bildpunkt resultatet kommer att skrivas till. Det finns ingen bra universell metod för att lösa det problemen med indirekt skrivning, men det har presenterats några metoder för att komma runt dem. Ingen av metoderna är överlägsen någon annan; vilken som passar bäst beror på tillämpningen. Det första som bör undersökas är dock om algoritmen kan skrivas om till att använda indirekt läsning istället för indirekt skrivning. Ibland är det möjligt ifall adresserna inte är dynamiska Sortera adresser Buck [8] föreslog en metod för indirekt skrivning i tre beräkningspass som alla utförs i fragment-processorn. I ett första pass skrivs resultatet av en beräkning tillsammans med adressen det ska skrivas till. I ett andra beräkningspass sorteras bufferten baserat på adressen, exempelvis kan någon av metoderna för sortering på en grafikprocessor som presenteras i kapitel 4.4 användas. Slutligen implementeras binär sökning för ett tredje och sista beräkningspass där punkterna ritas ut på sin

39 3.6 Reducering Figur 3.6. Stegvis reducering för att hitta max-elementet rätta position. Den här metoden är relativt omständlig och kan vara mycket långsam då sorteringen av adresser kan ta mycket tid Vertex-processorn Vertex-processorn kan inte utföra egentliga indirekta minnesskrivningar, men den kan däremot påverka positionen för de vektorer den bearbetar. Vektorernas position påverkar i slutändan vilka bildpunkter i framebufferten som kommer att uppdateras, och det beteenden är det möjligt att utnyttja för att utföra indirekta skrivningar, se Buck [8]. Detta utförs genom att varje element i den ingående datamängden representeras av ett punktformat grafiskt primitivt objekt som skickas till vertex-processorn. Vertex-processorn kan sen godtyckligt uppdatera positionen på punkten och på så sätt bestämma vilken punkt i framebufferten som ska uppdateras. Den här metoden fungerar ganska bra, men då vertex-processorn ofta är signifikant mycket långsammare än fragment-processorn utnyttjar man inte hela grafikprocessorns beräkningskraft. 3.6 Reducering Många algoritmer har ett eller flera steg där en delmängd av en större datamängd måste filtreras ut. Vanliga exempel är att beräkna summan av alla element eller söka fram elementet med det största värdet. Reducering kan på en grafikprocessor utföras genom stegvis förminskning av datamängden. En utbild som är en fjärdedel så stor som texturen vilken innehåller den genomsökta datamängden ritas till framebuffern. Ett fragment-program läser fyra sampel från in-texturen och applicerar reduceringsoperatorn på dem. I nästa steg används utbilden som inbild, och en ännu mindre bild ritas. Detta upprepas tills utbilden består av ett enda element, varvid reduceringen är klar. I figur 3.6 visas ett exempel på hur det största elementet i en tvådimensionell array söks fram. Reducering kräver O(log n) reduceringspass och sammanlagt O(n) reduceringsoperationer där alla i varje steg kan utföras parallellt.

40 24 Generella beräkningar på GPUer 3.7 Villkorliga satser Många algoritmer är svåra att göra effektiva utan någon form av villkorliga satser eller loopar. Både fragment-processorn och vertex-processorn har stöd för databeroende villkorliga programhopp i och med shader-modell 3.0, men det är dyra operationer, särskilt i fragment-processorn. Det är inte säkert att den bästa lösningen för villkorliga satser är databeroende programhopp även om möjligheten finns i hårdvaran man programmerar Databeroende programhopp Fragment-processorn är en SIMD-arkitektur som arbetar på grupper om flera bildpunkter samtidigt. Antag att en predikatfunktion p(x) evalueras för varje bildpunkt; vid positivt svar beräknas en dyr funktion f(x), i annat fall inte: if( p(x) ) resultat = f(x) else resultat = 0 I och med SIMD-arkitekturen innebär det att om en eller flera av bildpunkterna i gruppen ger positivt svar för p(x) måste f(x) beräknas för samtliga bildpunkter i gruppen. Faktum är att för en godtycklig konstruktion av villkorliga satser måste alla grenar som har någon inverkan på resultatet för minst en bildpunkt exekveras för samtliga bildpunkter i gruppen med bildpunkter fragment-processorn arbetar på. I och med detta kan man dra slutsatsen att den spatiella distributionen av sanningsvärdet från predikatfunktionen p(x) har inverkan på effektiviteten, vilket också kan visas med ett experiment. I figur 3.7 har tiden för ett renderingspass plottats mot andelen indata för vilka p(x) är sann och därmed den dyra funktionen f(x) beräknas. Simuleringen har körts för tre olika konfigurationer av indata; först med indata fördelat så att den spatiella distributionen av värden vilka ger sant för p(x) är slumpmässig, sen där den är indelad i små block, och till sist där indelningen är gjord i stora block. Idealt sett borde funktionen bli linjär, men så kan man se att fallet inte är. För slumpmässig uppdelning eller uppdelning i små block kan man se att det räcker med att f(x) beräknas för 5 10% av bildpunkterna för att det ska ta nästan lika lång tid som om den beräknats för samtliga bildpunkter. Är uppdelningen av sanningsvärden gjord i stora block är beteendet mycket bättre, men fortfarande inte linjärt. Av detta kan man dra slutsatsen att villkorliga satser implementerade med databeroende programhopp i fragment-processorn är möjliga, men ineffektvia såtillvida inte uppdelningen av sanningsvärden från predikatsfunktionen är homogen Early Z-Cull En annan möjlighet är att använda Early Z-Cull, EZC [25] för att bestämma vilka bildelement som ska ritas. EZC fungerar så att direkt efter rasteriseringsenheten

41 3.7 Villkorliga satser Uppdelning i stora block Uppdelning i små block Slumpmässig fördelning 40 Tid [ms] Andel bildelement ritade [%] Figur 3.7. Villkorliga satser implementerade med databeroende programhopp. För olika spatiella fördelningar av indata har tiden för utritning plottats mot andelen indata för vilka en dyr gren f(x) behöver beräknats. Testet är utfört på Nvidia GeForce 7800 GTX. genomgår varje fragment ett djup-test där det jämförs med motsvarande värde i framebuffertens djup-buffert. Om fragmentet klarar djuptestet går det vidare till fragment-processorn, annars förkastas det. För att använda EZC för villkorliga satser så renderas först en djupbuffert baserat på samma villkorliga sats som i programmet man önska exekvera. Men istället för att utföra den tunga beräkningen vid positivt svar från den villkorliga satsen så skrivs ett annat värde till djupbufferten, exempelvis 1.0 för positivt svar och 1.0 för negativt svar. I ett andra renderingspass ritas bilden ut vid z-koordinat 0.0 med ett fragment-program som alltid utför den tunga beräkningen f(x). Med EZC påslaget kommer de fragment vars position på framebufferten motsvaras av ett djup-värde på 1.0 att förkastas innan de sänds till fragment-processorn, och på så sätt kommer de inte att ritas ut över huvud taget. I figur 3.8 är det testet utfört för samma fördelningar av indata som för testet med villkorliga programhopp. Här kan man se att EZC är mycket mer förlåtande för om grupperna med indata är mindre, närapå linjärt för både små och stora grupper. Dock är det fortfarande långt ifrån linjärt för helt slumpmässig fördelning. Ibland räcker det inte med att undvika att rita ut bildelement för negativt svar på den villkorliga satsen, utan istället ska en annan beräkning g(x) utföras. För att kunna göra det med EZC inverteras djupbufferten och ett tredje renderingspass där fragmentprocessorn implementerar g(x) får exekveras. På samma sätt kan man

42 26 Generella beräkningar på GPUer Uppdelning i stora block Uppdelning i små block Slumpmässig fördelning Tid [ms] Andel bildelement ritade [%] Figur 3.8. Effekterna av Early Z-Cull för olika fördelningar av de bortsorterade bildelementen. Testet är utfört på en Nvidia GeForce 7800 GTX. göra om det är ännu fler grenar i en struktur av villkorliga satser, men metoden är bara effektiv om det är något fåtal grenar. Särskild hänsyn måste tas till den här metoden om något av de packade formaten i kap 3.4 används, eftersom enbart hela fragment kan förkastas, vilka kan motsvara upp till fyra logiska bildpunkter Domänuppdelning Inte sällan är det randvärdesproblem som medför behov av villkorliga satser, exempelvis kan man behöva göra extra beräkningar för bildpunkter som ligger i ytterkanten av bildområdet då dess grannar inte är definierade. Goodnight m.fl. [18] föreslår en metod där flera versioner av fragment-programmet skrivs, och olika domäner av bilden ritas ut i olika pass. Exempelvis en stor kvadrat i mitten med de vanliga beräkningarna följt av en separat ram med särskilda beräkningar för gränsen. Det går även att dela upp på ytterligare områden om så krävs. Den här metoden kan vara snabbare än att använda EZC eftersom det separata steget att rendera djupbufferten undviks, samt att rasteriseraren inte behöver interpolera fram alla fragment i bilden för varje gren. Den fungerar dock bara bra om de olika områdena är på förhand bestämbara samt homogena nog att enkelt kunna beskrivas av grafiska primitiver. Är områdena inte på förhand bestämbara eller såpass utspridda att de är svåra att beskriva med grafiska primitiver är det möjligt att det fungerar bättre med EZC.

43 3.8 Hjälpbibliotek Hjälpbibliotek GPGPU-programmering kan vara ganska mödosamt och omständligt. Framför allt kan det vara svårt eftersom alla anrop måste gå genom ett grafikbibliotek som från början inte alls var tänkt att användas till GPGPU-programmering. Det har dock utvecklats några metoder att komma runt problemet genom att abstrahera bort användningen av grafikbiblioteket Brook for GPUs Brook stream programming language (Brook) är ett språk utvecklat på Stanford University. Brook bygger på ANSI C, men har utökats med stöd för att kunna beskriva algoritmers parallelliserbarhet ur ett flödesberäkningsperspektiv. Språket definieras av Buck [7]. Brook for GPUs är en kompilator och programbibliotek som kompilerar och exekverar Brook-program på grafikprocessorer. Brook for GPUs använder sig av antingen OpenGL eller DirectX för kommunikation med grafikprocessorn, men grafikbiblioteket är helt bortabstraherat för användaren. Detta är dess stora styrka, men också till viss del dess svaghet. Det innebär till exempel att en del finesser och specialtrick som kan utnyttjas vid direkt användning av ett grafikbibliotek kan vara svåra att utnyttja. Att använda ett fristående språk som från början inte är avsett för shader-programmering innebär också att en del implementationer inte blir lika effektiva som om de skrivits direkt i ett språk närmare grafikprocessorn. Brook for GPUs har ändå fått stort användande framför allt inom den akademiska världen och finns beskrivet mer ingående av Buck m.fl. [9] Sh Sh [33] är ett programbibliotek för programmering av grafikprocessorer utvecklat vid Waterloo University. Den stora skillnaden med Sh jämfört med andra hjälpmedel för GPU-programmering är att Sh helt eliminerar behovet av ett specifikt shader-språk. Sh är byggt på C++ och shader-program konstrueras implicit genom anrop till Sh-biblioteket. Sh bygger under körning upp ett shader-program vilket det kompilerar och laddar ner till grafikprocessorn. Sh används inte uteslutande till GPGPU-programmering, utan kan även användas vid konventionell användning av grafikprocessorer för utritning av tredimensionella objekt.

44 28 Generella beräkningar på GPUer

45 Kapitel 4 Relaterat arbete Att använda grafikprocessorer för generella beräkningar är ett relativt nytt område. Det var först i och med introduktionen av tredje generationens GPU, runt år 2002, som de blev tillräckligt programmerbara för att vara praktiskt användbara för ett bredare område generella beräkningar. Då det är så nytt och relativt outforskat område finns det inte så många tillämningar inom industrin ännu. Däremot har det de senaste åren publicerats ett stort antal akademiska artiklar på området och tillämpningar inom vitt skilda användningsområden har föreslagits och implementerats. Här presenteras ett urval av vad som är implementerat inom några olika områden, för en mer komplett sammanställning refereras till exempel till Owens m.fl. [36]. 4.1 Bildbehandling Bildbehandling är ett område till vilket GPGPU är mycket väl anpassat. Det är ofta relativt enkelt att hitta en mappning mellan bildbehandlingsalgoritmer och grafikprocessorns beräkningsmodell FFT Flera försök till effektiva implementationer av FFT (fast fourier transform) för grafikprocessorer har gjorts. En av de tidigaste implementationerna gjordes av Moreland och Angel [35] Med tekniken som var tillgänglig då lyckades de inte få den snabbare än en optimerad FFT för CPU, men den var i alla fall såpass snabb att det i många fall skulle vara effektivare att låta beräkningen ske på grafikprocessorn om det data som skulle behandlas redan låg i grafikminnet och resultatet inte behövde läsas tillbaks till systemminne. Liu och Sumanaweera [43] presenterar i sitt arbete om bildrekonstruktion av medicinska bilder med magnetresonans-kameror en mer detaljerad beskrivning över FFT på grafikprocessorer. De använder sig av modernare hårdvara och flera tekniker för optimering, bland annat lastbalansering mellan vertex-processorn och 29

46 30 Relaterat arbete fragment-processorn. Med Nvidias grafikprocessor Quadro FX får de en hastighetsförbättring med en faktor mellan 1.3 och 2.0 jämfört med en väl optimerad FFT på en Intel Pentium GHz Strålföljning Strålföljning är en metod för att konstruera artificiella fotorealistiska bilder. Det är en mycket beräkningstung metod och kan sällan används i realtidstillämpningar. Principerna för bildkonstruktion med strålföljning är de motsatta som vanligtvis används för att konstruera bilder med en grafikprocessor. Istället för att rita ut de grafiska primitiva objekten ett i taget tills hela bilden är utritad så konstrueras en stråle för varje bildpunkt i resultatbilden. Strålarna kollisionstestas med alla objekt och nya strålar skickas ut ifall de till exempel träffar ett objekt med en reflekterande yta. Med strålföljning får man helt andra möjligheter till avancerad ljussättning än vad som är möjligt med klassiska metoder i en GPU. Till exempel är det mycket enkelt att beräkna exakta skuggor och reflektioner med strålföljning. En av de första implementationerna av klassisk strålföljning för grafikprocessorer gjordes av Carr m.fl. [10] Global illumination Med klassisk strålföljning kan enbart direkt ljus från punktformade ljuskällor beräknas, inte indirekt ljus från närliggande belysta ytor. Tekniker för att beräkna det ljuset kallas global illumination, GI, och används ofta i samband med strålföljning. En metod är fotonmappning. Fotonmappning bygger på att en mängd strålar, fotoner, i ett förberäkningssteg skickas ut från alla ljuskällor. Tabellen över var fotonerna träffar används sen vid strålföljningen för att bestämma hur mycet ljus ytorna träffas av. För mer information om fotonmappning, se Jensen [29]. Purcell m.fl. [37] implementerade 2003 strålföljning med fotonmappning för grafikprocessorer. En annan metod för GI är radiosity. Med radiosity beräknas hur stor vinkelarea varje objekt exponerar mot varje annat objekt. Den faktorn kalla formfaktorn, och används för att beräkna hur objekten ljussätts. För mer om radiosity, se Goral m.fl. [19]. Carr m.fl. [11] implementerade 2003 radiosity för strålföljning i grafikprocessorer. Ett problem var dock att metoden de valde att använda i praktiken begränsade antalet objekt till några få tusen. En bättre metod utvecklades senare av Coombe och Harris [13]; de kunde rendera scener med miljontals objekt Rörelseestimering Strozodka och Garbe [42] har utvecklat ett system för rörelseestimering och visualisering i realtid på grafikprocessorer. Principerna de använder för rörelseestimering är samma som används för beräkning av optiskt flöde i algoritmen som implementeras inom det här arbetet (se kapitel 6.3). De visar att deras implementation kan vara flera gånger snabbare än en väl optimerad CPU-version.

47 4.2 Signalbehandling Figur 4.1. Parallel bitonic merge sort. 4.2 Signalbehandling Whalen [45] har utvärderat ljudbehandling på grafikprocessorn. Han visar att flera vanliga algoritmer för ljudbehandling kan implementeras effektiv och kan vara flera gånger snabbare än på en snabb CPU. Däremot visar han att grafikprocessorn inte är användbar i realtidstillämpningar för ljudbehandling då relativt stora data mängder måste behandlas parallellt. Smirnov och Chiueh [40] har implementerat ett effektivt FIR-filter för grafikprocessorer, främst avsett för ett projekt för mjukvarubaserad radio 1. Även de kommer fram till att GPU-implementationen kan vara snabbare än CPUimplementationen, men bara för tillräckligt stora datamängder. 4.3 Linjär algebra Stora linjära ekvationssystem har ofta använts för att utvärdera beräkningskapaciteten för datorer. Galoppo m.fl. [17] har utvecklat en metod för att lösa stora täta linjära ekvationssystem på en grafikprocessor. Deras implementation står sig väl i förhållande till CPU-versioner och är flera gånger snabbare för stora datamängder. 4.4 Sortering och sökning Sortering är ett klassiskt problem inom datavetenskapen. I en CPU finns det flera metoder att sortera på, flera med en tidskomplexitet på O(n log n). Dock är ingen av de algoritmerna särskilt effektiva att implementera på en GPU, främst eftersom algoritmerna är starkt databeroende och behöver kunna skriva till olika platser i minnet beroende på data, se Owens m.fl. [36]. De flesta implementationer för sortering på grafikprocessorer använder sig av någon form av fast sorteringsnätverk, se Batcher [3]. I ett sorteringsnätverk utförs 1 Se

48 32 Relaterat arbete sorteringen i ett antal fasta steg där data- och kommunikationsflödet är oberoende av indata. I och med detta kan de implementeras utan att positionerna för var skrivningar sker behöver vara databeroende. I figur 4.1 visas hur parallel-bitonicmerge-sort av åtta element kan utföras i sex pass. Med sorteringsnätverk kan en tidskomplexitet på O(n log 2 (n)) uppnås, vilket är sämre än vad som kan uppnås med andra algoritmer. Purcell m.fl. [37] demonstrerade 2003 en implementation av bitonic-merge-sort för grafikprocessorer. Kipfer och Westermann [32] visade senare hur den algoritmen kan utföras effektivare med en rad optimeringar och effektivare utnyttjande av grafikprocessorns resurser. Govindaraju m.fl. [20] implementerade senare ytterligare en version av bitonicmerge-sort som enbart använder grafikprocessorns fasta datavägar för att utföra sorteringen. Detta gör den mycket snabb och det är idag den effektivaste implementationen för sortering på grafikprocessorer. De visar att en Nvidia Ge- Force 7800 GTX sorterar 16 miljoner 32-bitars flyttal på knappt två sekunder, vilket är ungefär lika snabbt som en handoptimerad sorteringsalgoritm på en Intel Pentium4 3.2 GHz med dubbla kärnor

49 Kapitel 5 Implementation Inom examensarbetet har ett ramverk för signal- och bildbehandling på grafikprocessorer implementerats. Ramverket är främst inriktat mot bildbehandling och har integrerats i ett redan existerande bildbehandlingsramverk som från början var helt CPU-baserat. I det här kapitlet beskrivs uppbyggnaden och användningen av ramverket utan att gå in för mycket på specifika tillämpningar. 5.1 Grafikbibliotek I dagsläget är det enbart möjligt att styra grafikprocessorer via de av tillverkarna tillhandahållna drivrutinerna samt ett grafikbibliotek. Då tillverkarna har släppt ytterst få tekniska specifikationer på grafikprocessorerna är det mycket svårt att komma runt beroendet av drivrutinerna. Utöver drivrutinerna behövs ett grafikbibliotek. Det finns idag två stora grafikbibliotek som är möjliga att använda: OpenGL 1 och Microsoft DirectX 2. Båda har sina för- och nackdelar, men OpenGL har en avgörande fördel: portabilitet. OpenGL finns implementerat på en mängd olika system, bland annat olika versioner av Microsoft Windows, Linux och MacOS. Microsoft DirectX är begränsat till Windows enbart. Tidigt togs beslut om att använda OpenGL för implementation av GPGPUramverket, främst på grund av portabiliteten. 5.2 Shader-språk Det blev tidigt klart att relativt komplicerade program skulle behöva implementeras i fragment-processorn, vilket medförde ett behov av att använda något av högnivåspråken för att få en enklare utvecklingsprocess. Då det var klart att OpenGL skulle användas som grafikbibliotek stod valet mellan Cg och GLSL. 1 Se 2 Se 33

50 34 Implementation GLSL är en öppen standard och mycket väl integrerat i OpenGL, men Cg har fördelen att även vara kompatibelt med DirectX. Cg valdes till slut som shader-språk främst för att underlätta en framtida eventuell portning till DirectX. 5.3 Rendering till textur En viktig del av programmet är att kunna använda resultatet från en beräkning som indata till en annan beräkning utan dyra kopieringar samt att kunna ha en större mängd buffertar för tillfällig lagring av delresultat. För att en bild ska kunna användas som indata till en beräkning måste den vara representerad av en textur i grafikprocessorns texturminne. Resultatet från en beräkning skrivs dock vanligtvis inte till en textur utan till en framebuffert (se kapitel 2.1.4). Tidigare har den enda möjligheten varit att utföra en explicit kopiering från framebuffern till texturminnet, men det är mycket ineffektivt då dubbelt så mycket minne används samt att kopieringen tar tid. Det finns två olika metoder för att kunna rendera direkt till en textur: pbuffers och Framebuffer object. Båda metoder ger dessutom möjlighet att skapa en godtycklig mängd buffertar Pbuffers Pbuffers, pixel buffers, var den första metoden som introducerades för att kunna rendera direkt till texturer och finns definierad i The Pbuffer extension [5]. Pbuffers gör det möjligt att skapa flera renderingsbuffertar som inte visas på bildskärmen. Varje pbuffer kan ses som ett virtuellt fönster och har en egen OpenGL-kontext. Antalet pbuffers begränsas enbart av mängden minne på grafikkortet. Pbuffers har flera nackdelar. En av de största nackdelarna är just att varje pbuffer har sin egen OpenGL-kontext, vilket innebär att det är svårt att dela eller utbyta data mellan olika pbuffers. Även själva skapandet och hanterandet av olika pbuffrar kan vara mycket omständligt. Till sist är pbuffers systemberoende, skapandet och hanterandet av dem är olika i olika operativsystem. Till fördelarna hör att de flesta tillverkare av grafikprocessorer har bra stöd för pbuffers. Pbuffers har funnits relativt länge och implementationerna är stabila Framebuffer object För att undkomma problemen med pbuffers har en ny metod för offline-rendering tagits fram: Framebuffer object, FBO. En stor fördel är att FBO kan dela OpenGLkontext. Detta gör att de enklare kan dela och utbyta data samt att ett byte av aktiv FBO blir snabbare. Användandet är dessutom helt systemoberoende och fungerar på samma sätt i alla operativsystem. Stödet för Framebuffer object kom relativt nyligen. Nvidia införde stöd för FBO i sina drivrutiner under våren 2005, men när det här examensarbetet inleddes under sommaren 2005 hade ATI ännu inte infört stöd för FBO. Detta var ett problem då det var önskvärt att utvärdera grafikprocessorer även från ATI. Trots det dåliga stödet hos ATI togs ändå ett beslut att använda FBO då tekniken är

51 5.4 Nerladdning och tillbakaläsning 35 såpass överlägsen jämfört med pbuffers. Dessutom bedömdes sannolikheten att ATI skulle införda stöd för FBO inom kort som hög. Detta infriades också; under hösten släppte ATI drivrutiner med fungerande stöd för FBO. 5.4 Nerladdning och tillbakaläsning För att en bild ska kunna bearbetas i grafikprocessorn måste den först laddas ner från systemminne till grafikprocessorns texturminne. Beroende på vilket datalagringsformat som valts kan bilden först behöva fördelas om i systemminne innan den laddas ner. Ramverket i sig är inte anpassat till något speciellt lagringsformat, det är upp till användaren att arrangera om bilderna och anpassa fragment- och vertex-program till den tänkta logiska bildrepresentationen. OpenGL bygger till stora delar på asynkrona beräkningar. Anrop som görs till OpenGL utförs inte nödvändigtvis omedelbart, eller ens i samma ordning som de anropas, utan istället läggs de i en kö som hanteras av grafikprocessorns drivrutiner. Drivrutinerna ser till att GPUn utför beräkningarna så effektivt som möjligt och att resultatet blir logiskt sett det detsamma som om de utförts i den specificerade ordningen. På så sätt kan grafikprocessorn och CPUn utföra många beräkningar parallellt utan att de behöver invänta varandra. Dock finns det några tillfällen då hela kön måste tömmas. Framför allt kan det ske via ett explicit anrop till glfinish. glfinish returnerar inte förrän alla kommandon i kön har bearbetats klart. Det kan även ske ett implicit anrop till glfinish vid olika tillfällen. Ett sådant tillfälle är när data laddas ner till texturminne eller data från en framebuffert läses tillbaks till systemminne. Anledningen till detta är att OpenGL-standarden [38] garanterar att när ett anrop för nerladdning till GPUn returnerar så kan systemminnet bilden låg i direkt frigöras och användas till andra operationer. Det innebär att anropet inte kan returnera förrän hela bilden är överförd, vilket effektivt stoppar asynkrona överföringar. Samma sak gäller för tillbakaläsning; vid ett anrop för tillbakaläsning garanterar standarden att hela den tillbakalästa bilden är giltig direkt när kommandot returnerar. Ett ytterligare problem är att flera drivrutiner implementerar de här vänteperioderna med en busy-wait-loop. Det medför stora problem och prestandaförluster för GPGPU-implementationer då man ofta behöver ladda ner och läsa tillbaks data men samtidigt vill använda processorn till andra beräkningar. 5.5 Uppbyggnad Ramverket är relativt flexibelt och lämnar saker som format för bildrepresentation och dataformat öppet för tillämpningarna. Programmet är centrerat kring tre huvudobjekt: bildytor, fragment-program och vertex-program. Varje bildyta representeras av färgbufferten i en framebuffert men är samtidigt bunden som textur för att kunna användas som indata. Bildytorna lagras i Framebuffer object, FBO. Då varje FBO kan innehålla flera färgbuffertar kan den även representera flera bildytor. Maxantalet är implementationsberoende för OpenGL och är i dagsläget begränsat till fyra stycken. Inom

52 36 Implementation FBO 1 Bildyta 1 Bildyta 2 FBO 2 Bildyta 3 Bildyta 4 Bildyta 1 Bildyta 2 Beräkningskärna FBO 3 Bildyta 1 Bildyta 2 Bildyta 3 Figur 5.1. Under ett beräkningssteg kan bildytor från olika FBO användas, men alla bildytor som skrivs till måste finnas en och samma FBO. varje FBO måste alla bildytor ha samma dimension och format Beräkningsflöde Vid varje beräkningssteg kan en eller flera godtyckliga bildytor användas som indata. I OpenGL finns det dock en implementationsberoende begränsning på maxantalet texturer som samtidigt kan vara aktiverade under en utritning, vilket också begränsar antalet bildytor som samtidigt kan användas som indata. För närvarande ligger den begränsningen på 16 texturer. Utdata skrivas till en eller flera bildytor där samtliga bildytor måste existera i samma FBO. Då en FBO för närvarande kan innehålla maximalt fyra bildytor är också det största antalet utbilder från ett beräkningssteg begränsat till fyra. Vid utritning används vanligtvis en enkel kvadrat som grafiskt primitivt objekt, men det går att ställa in så ett godtyckligt högupplöst nät av kvadrater används istället ifall ett ickelinjärt filter realiserats i vertex-processon. Under utritningen aktiveras en beräkningskärna som kan bestå av antingen ett fragment-program, ett vertex-program eller både och, se figur 5.1. Bilderna som används som indata behöver inte vara hela bildytor, eller ens lika stora. Det är möjligt att använda godtyckliga rektangulära delytor av bildytorna som indata och det går bra att till exempel använda olika delytor av samma bildyta för olika indata. Utbilderna behöver inte heller de vara hela bildytor, men alla utbilder i en beräkning måste vara av samma dimension och vara placerade

53 5.6 Exempel Figur 5.2. Filterkärna för sobel-x. på exakt samma ställe i alla bildytor Beräkningskedjor För större beräkningar där ett beräkningspass inte räcker kan långa kedjor med beräkningskärnor sättas samman. Kedjorna kan ha godtycklig längd och sammansättning, den enda begränsningen är att att varje beräkningskärna kan använda masimalt 16 inbilder och producera maximalt 4 utbilder. 5.6 Exempel För att ge en bättre bild av hur programmet används visas här samtliga steg i hur ett enkelt sobel-x-filter i fragment-processon kan realiseras i det implementerade ramverket. Ett sobel-filter är ett mycket enkel deriverande filter, filterkärnan återfinns i figur 5.2. Cg-programmet som implementerar filtreringen lagras först i en separat fil: 1 /* 2 * Cg-program för sobel-x-filtrering. 3 */ 4 float4 sobel_x(float2 texcoord : TEXCOORD0, 5 uniform samplerrect image) : COLOR0 6 { 7 float4 sampel0 = texrect(image, texcoord + float2(-1.0f, -1.0f); 8 float4 sampel1 = texrect(image, texcoord + float2(-1.0f, 0.0f); 9 float4 sampel2 = texrect(image, texcoord + float2(-1.0f, 1.0f); 10 float4 sampel3 = texrect(image, texcoord + float2( 1.0f, -1.0f); 11 float4 sampel4 = texrect(image, texcoord + float2( 1.0f, 0.0f); 12 float4 sampel5 = texrect(image, texcoord + float2( 1.0f, 1.0f); return -sampel0-2.0f * sampel1 - sampel sampel f * sampel4 + sampel5; 16 }

54 38 Implementation I ett initialiseringssteg skapas en FBO med två bildytor; en där inbilden lagras och en för resultatet. Dessutom skapas ett CgFragment-objekt som kapslar in Cg-programmet och sköter kompilering och nerladdning till grafikprocessorn: 1 /* 2 * Skapa en FBO innehållandes två bildytor av dimensionerna x*y. 3 */ 4 FBO fb = new FBO(x, y, GL_RGBA8, 2); 5 6 /* 7 * Skapa ett fragment-program från cg-filen "sobel.cg". 8 * Specificera att det tar en inbild och producerar 9 * en utbild. 10 */ 11 FragmentProgram sobelxfilt = new CgFragment("sobel.cg", "sobel_x", 1, 1); Efter initialiseringen består själva filtreringen förutom nerladdning och tillbakaläsning av ett enda anrop: 1 /* 2 * Ladda ner bilden från systemminne till FBO fb, 3 * bildyta nummer 0. 4 */ 5 download(imptr, FboDest(fb, 0)); 6 7 /* 8 * Kör sobel-x-filtret på den nerladdade bilden och lagra 9 * resultatet i samma FBO men bildyta nummer */ 11 sobelxfilt->run(fbosource(fb->gettex(0)), 12 FboDest(fb, 1)); /* 15 * Läs tillbaks resultatet till systemminne och skriv över 16 * originalbilden. 17 */ 18 readback(imptr, FboDest(fb, 1);

55 Kapitel 6 Tillämpningar Här beskrivs några av algoritmerna som implementerades i GPGPU-ramverket. Dels några enkla men viktiga filter som faltning och geometrisk omsampling, men framför allt två mer komplicerade beräkningskedjor för stereoseende samt beräkning av optiskt flöde. 6.1 Faltning En mycket viktig och grundläggande operation inom bildbehandling är diskret faltning. Tvådimensionell linjär diskret faltning av en inbild f(x, y) med en filterkärna g(x, y) definieras enligt h(x, y) = (f g)(x, y) = α= β= f(x α, y β) g(α, β) (6.1) det vill säga för varje bildelement i utbilden multipliceras varje element i filterkärnan med motsvarande element i inbilden och produkterna adderas. Filterkärnan är ofta bara definierad inom ett begränsat intervall och antas vara noll utanför definitionsintervallet. Hur faltningen kan genomföras beror på vilket format bilden är lagrad i. Är den lagrade i ett icke-packat format är operationen relativt rättfram. Svårigheterna uppstår när något av de packade formaten i kapitel 3.4 används. Här kommer främst bildformatet utan packning samt formatet där fyra horisontellt närliggande logiska bildpunkter packas att behandlas Faltning med icke-packade bilder Då ett bildformat med enkelt adresserbara logiska bildpunkter används är faltningen mycket rättfram. Dessa format inkluderar dels icke-packade bilder och format där fyra oberoende gråskalebilder packats till en färgbild, men även kvadrantvis packade bilder utökade med tillräckligt stor ram (se kapitel 3.4.2). Principen 39

56 40 Tillämpningar går ut på att för varje bildpunkt i utbilden iterera över hela filterkärnan, multiplicera filterkoefficienten med motsvarande bildpunkt i inbilden och ackumulera produkten till resultatet. På det här sättet kommer det att utföras lika många texturläsningar, multiplikationer och additioner som det finns element i filterkärnan. En modern GPU kan ofta göra en texturläsning, en multiplikation och addition på en klockcykel, vilket innebär att en 4-elements resultatvektor vid faltning med en filterkärna med n m element kan beräknas på lite drygt n m klockcykler. En modern grafikprocessor använder flyttal vid adresseringen av texturelement. Utförs en texturläsning med koordinater som inte ligger exakt på ett texturelement kan man välja att låta grafikprocessorn interpolera fram ett värde med linjär interpolering. Dessa beräkningsvägar för är ofta implementerade i hårdvara och är mycket snabba. I många fall går det att utnyttja detta till faltning eller andra GPGPU-algoritmer. Antag att två vertikalt närliggande bildpunkter i inbilden med texturkoordinaterna (c x, c y ) respektive (c x, c y + 1) ska multipliceras med koefficienterna α respektive β och ackumuleras till resultatet r. Antag vidare att t(x, y) returnerar texturelementet vid koordinat (x, y). Då gäller att r = r + α t(c x, c y ) + β t(c x, c y + 1) (6.2) Med linjär interpolation vid texturläsning kan uttrycket skrivas om så det räcker med en texturläsning enligt r = r + (α + β) t(c x, c y + β β α + β ) (6.3) under kravet att kvoten α+β är inom intervallet [0..1], det vill säga koefficienterna α och β är teckenekvivalenta, samt kravet att α + β 0. Denna metod kan användas för varje närliggande par av filterkoefficienter som uppfyller dessa krav. På det här sättet behövs bara en texturläsning för varje par av punkter i kärnan. En modern GPU kan utföra hela (6.3) på en klockcykel om koefficienterna α + β samt kvoten β α+β förberäknas för varje par av element i faltningskärnan. En 4- elements resultatvektor vid faltning med en kärna av storlek n m kan på så sätt beräknas på lite drygt n m/2 klockcykler. I vissa specialfall går det att kombinera fyra bildpunkter på en gång. Givet att fyra närliggande bildpunkter från inbilden ska kombineras enligt α 1 t(c x, c y ) + α 2 t(c x + 1, c y ) + α 3 t(c x, c y + 1) + α 4 t(c x + 1, c y + 1) (6.4) så gäller att om samtliga koefficienter α 1..4 är teckenekvivalenta samt att α 1 /α 2 = α 3 /α 4 och α 1 /α 3 = α 2 /α 4 så kan linjärkombinationen skrivas enligt (α 1 + α 2 + α 3 + α 4 ) t(c x + α 2 α 1 + α 2, c y + α 3 α 1 + α 3 ) (6.5) och utföras med en enda texturläsning. Dock är det mycket sällan det är möjligt för godtyckliga faltningskärnor.

57 6.2 Geometrisk omsampling 41 faltningskärna kärna 1 kärna 2 kärna 3 kärna 4 Figur 6.1. Faltningskärna i fyra olika versioner Både metoden med linjär interpolation och den utan har implementerats och utvärderats. Fördelen med metoden utan linjär interpolation är att filterkoefficienterna kan ändras dynamiskt via uppdatering av parametrar till fragmentprogrammet. Vid metoden med linjär interpolation krävs omkompilering av fragmentprogrammet om koefficienterna behöver ändras Faltning med horisontellt packade bilder Faltning med bilder lagrade i formatet med fyra horisontellt närliggande bildpunkter packade är svårare. Framför allt är det svårt att utnyttja grafikprocessorns inbyggda linjära interpolation vid textursampling, med undantag för vertikal faltning med en endimensionell faltningskärna. Vid horisontell faltning eller faltning med tvådimensionell faltningskärna uppstår problemet med att adressera de logiska bildpunkternas grannar vilket diskuterades i kapitel 3.4. De flesta moderna grafikprocessorer kan utföra skalärmultiplikation av två 4- elements vektorer på en klockcykel. För att utnyttja denna operation vid horisontell faltning av horisontellt packade bildpunkter kan fyra olika versioner av filterkärnan skapas enligt figur 6.1. För varje 4-elements resultatvektor skalärmultipliceras inbilden med de olika versionerna av filterkärnan. Resultaten läggs i var och en av elementen i resultatvektorn enligt figur 6.2. På det här sättet kan en 4-elements resultatvektor vid vertikal faltning med en n 1 stor filterkärna beräknas med n/4 texturläsningar, n skalärmultiplikationer samt n additioner. Faltning med en tvådimensionell faltningskärna utförs genom summation resultatet av horisontell faltning med varje rad i faltningskärnan. 6.2 Geometrisk omsampling Geometrisk omsampling är också mycket viktigt inom bildbehandling. Ofta måste inbilderna samplas om på olika sätt innan vidare beräkningssteg kan utföras på dem, exempelvis perspektivkorrigering eller kompensation för okalibrerade kameror. Ibland räcker det med linjära transformationer som rotation, translation eller projektion, men det är heller inte ovanligt att det krävs olinjära transformationer exempelvis för att kompensera för linsdistorsionen i en kamera.

58 42 Tillämpningar inbild Faltning av inbild med kärna 1 Faltning av inbild med kärna 2 Faltning av inbild med kärna 3 Faltning av inbild med kärna 4 Figur 6.2. Faltning av en bild lagrad i det packade formatet (beskrivet i kap 3.4) med en 1 8 punker stor faltningskärna. Varje version av faltningskärnan används för att utföra faltning med inbilden, och resultaten från de olika kärnorna lagras i respektive färgkomponent i utbilden. Grafikprocessorn är väl anpassad till att utföra omsampling av bilder; de inbyggda funktionerna för linjär interpolering vid omsampling av texturer är mycket väl optimerade. Dock innebär dessa fasta datavägar en del begränsningar. Framför allt just att interpolationen är begränsad till antingen närmsta granne eller linjär interpolation. Finns det ett behov av bättre filtrering så går det inte att direkt använda de fasta datavägarna, men det finns metoder för att implementera bättre omsampling i fragment-processorn. Sigg och Hadwiger [39] beskriver till exempel en metod för omsampling av texturer med bikubisk spline-filtrering implementerat i fragment-processorn. Det andra problemet med de fasta datavägarna är att de är svåra att utnyttja tillsammans med flera av de packade dataformat för gråskalebilder vilket beskrivs närmare i kapitel Linjära transformationer Om bilden som ska samplas om är lagrad i ett icke-packat format eller om formatet med kvadrantvis packad bild utökad med en tillräckligt stor ram används kan enkelt de fasta datavägarna för linjär interpolation användas. Det finns två grundläggande huvudmetoder för linjära transformationer. Den första metoden är att transformera koordinaterna för de primitiva grafiska objekt vilka används för att rita ut bilden. Den andra metoden är att istället transformera texturkoordinaterna de primitiva objekten är associerade med. I princip är det ingen skillnad på de båda metoderna, men några skillnader

59 6.2 Geometrisk omsampling 43 Figur 6.3. Originalbild (till vänster) roterad och nerskalad med repeterad bild (i mitten) respektive repeterad yttre ram (till höger). Figur 6.4. Originalbild (till vänster) roterad och nerskalad (till höger). uppstår. Vid transformation av texturkoordinater kommer hela bildytan i resultatbilden att ritas ut, men en del bildelement kan få texturkoordinater vilka är utanför texturens definitionsområde. Beroende på inställningar kommer inbilden antingen att vara repeterad eller låta den yttersta ramen av bildelement repeteras. I figur 6.3 är en bild roterad och nerskalad. Vid första transformationen används repeterad inbild, vid andra repeterad yttre ram. Ifall metoden att transformera positionen på de grafiska primitiva objekt används kommer områdena i utbilden vilka motsvaras av koordinater utanför inbildens definitionsområde inte att ritas ut. Fördelen med den metoden är att den kan vara snabbare ifall antalet utritade bildelement är mindre än storleken på utbilden vilket till exempel är fallet vid nerskalning. Ett problem med metoden är dock att det uppstår höga frekvenskomponenter i bilden vid kanten mellan uppdaterade och icke uppdaterade bildelement vilket kan ses figur 6.4. Vilken metod som är lämplig beror på vad för krav som ställs på utbilden. Innebär de höga frekvenskomponenterna från den senare metoden med transformation av de grafiska primitiva objekten svårigheter i efterföljande beräkningssteg bör den första metoden användas, men om prestandan är viktigare så kan den andra metoden användas Ickelinjära transformationer Ett exempel på ickelinjära transformationer är kompensering för linsdistorsion i kameror vilket kan vara nödvändigt ifall en kamera inte kan approximeras enligt

60 44 Tillämpningar Figur 6.5. Ickelinjär transformation i fragment-processorn (till vänster) respektive styckvis linjär transformation med vertex-processorn (till höger). hålkameramodellen. Då rasteriseringsenheten enbart kan interpolera fram texturkoordinater linjärt går det inte att använda den för godtyckliga ickelinjära transformationer. Det finns två sätt att lösa det problemet. Det ena är att dela upp de grafiska primitiva objekten i flera mindre och låta rasteriseringsenheten interpolera linjärt inom de mindre objekten men transformera vektorerna som bygger upp dem separat enligt den ickelinjära modellen. Transformationen av vektorerna utförs då med fördel i vertex-processorn, men det är också möjligt att ladda ner en förberäknad lista över de transformerade koordinaterna. Är transformationen statisk över många bilder är det den fördelaktiga metoden. Om styckvis linjär interpolering av texturkoordinater inte är tillräckligt kan transformationen istället utföras helt i fragment-processorn för varje fragment. Det kan vara mycket långsammare om det är en komplex transformation, men även här kan en lista med förberäknade koordinater användas, då lagrade i texturminnet. I figur 6.5 visas hur ickelinjär transformation utförts dels i fragment-processorn och dels styckvis linjärt via vertex-processorn Packade format Om något av de packade formaten från kapitel 3.4 används är det svårare att använda rasteriseringsenheten för att interpolera fram texturkoordinater vid transformation. Detta eftersom rasteriseringsenheten bara interpolerar fram en koordinat för varje grupp om fyra logiska bildpunkter. I figur 6.6 visas hur en rotation utförts med bilder lagrade i formatet med horisontellt packade bildpunkter. Man kan se att det bara är den ena av de fyra logiska resulterande bildpunkterna i varje resultatvektor som får korrekt värde. En metod för att komma runt problemet är att göra transformationen i flera steg. I ett första steg packas bilden upp och lagras i en textur med ett texturelement per logiskt bildelement. I det andra steget sker transformationen som vanligt, och i ett eventuellt tredje steg packas bilden ner igen. På så sätt kan man använda de inbyggda funktionerna för interpolering av koordinater och linjär omsampling utan oönskade effekter. Nackdelen är att de extra stegen tar tid.

61 6.3 Optiskt flöde 45 Figur 6.6. Fel som uppstår vid transformation av packade bildformat. För varje vektor om fyra logiska bildpunkter läses endast ett textursampel. Textursamplet har felaktig orientering vilket medför distorsion i utbilden. För att med den metoden undvika det sista separata steget med nerpackning och istället producera den packade bilden direkt kan en metod med flera texturkoordinater för varje bildpunkt användas. Det fungerar på så sätt att fyra olika texturkoordinater binds till varje vektor i de primitiver som används för att rita utbilden. Varje koordinat är förskjuten 1/4 texturelement. Rasteriseringsenheten kommer då att generera fyra olika texturkoordinater för varje fragment, en för varje logisk bildpunkt. I fragment-processorn används sen de fyra olika koordinaterna för att läsa sampel från texturen, ett sampel till varje logiskt bildelement. Att direkt utföra transformationer där även inbilden är packad är svårare. Det är möjligt att skriva ett program för fragment-processorn som adresserar de logiska bildpunkterna i inbilden och utför interpoleringen manuellt, men komplexiteten i ett sådant program gör att det är effektivare att göra det i flera steg. 6.3 Optiskt flöde Beräkning av optiskt flöde innebär att man från en visuell representation bestämmer objekts rörelse. Utifrån två bilder A och B samplade vid olika tidpunkter beräknas ett fält av tvådimensionella vektorer som beskriver hur B skiljer sig från A. Detta kallas dispariteten mellan de två bilderna och i princip ska den ena av de två bilderna kunna återskapas från den andra bilden med hjälp av dispariteten. Det finns flera algoritmer för att beräkna optiskt flöde; metoden som används här bygger främst på en metod utvecklad av Fleet och Jepson [15] som använder sig av den lokala fasen vid beräkningen. I Gökstorp [21] beskrivs optiskt flöde mer allmänt och där finns också en sammanställning över flera metoder som är vanliga vid beräkning av optiskt flöde.

62 46 Tillämpningar Teori Låt I(x, y, t) vara intensiteten i en bild vid koordinaterna (x, y) vid tiden t. Låt vidare samplingsperioden mellan två bilder, t, vara kort. Skillnaden mellan två bilder kan då beskrivas av I(x + x, y + y, t + t) = I(x, y, t) + N(x, y, t) (6.6) där N(x, y, t) representerar bruset. Detta kan även kan skrivas som I( x + v t, t + t) = I( x, t) + N( x, t) (6.7) där x = (x, y) T och v = (u, v) T = ( x/ t, y/ t) T. Om bruset antas vara försumbart ger en taylorutveckling vilket kan förkortas till I dx x dt + I dy y dt + I t = I xu + I y v + I t = 0 (6.8) I( x, t) ( v T, 1) = 0 (6.9) vilket är definitionen av optiskt flöde (basic optical flow constraint equation, BFC) enligt Horn [27]. Ur (6.9) kan disparitetsvektorn v lösas ut och beräknas med hjälp av de lokala derivatorna I x, I y och I t. Lösningen ger en linje av möjliga lösningar för v. För att få en unik lösning till ekvationen finns flera metoder. Den som används här är antagandet att flödet är lokalt konstant, det vill säga Om (6.8) deriveras med avseende på x och y fås vilka ger lösningen x u = y u = x v = y v = 0 (6.10) I xx u + I xy v + I xt = 0 (6.11) I xy u + I yy v + I yt = 0 (6.12) u = I xti yy I yt I xy I 2 xy I xx I yy (6.13) v = I yti xx I xt I xy I 2 xy I xx I yy (6.14) Under antagandet att v förändras långsamt och är konstant inom en liten omgivning lågpassfiltreras de partiella derivatorna innan v beräknas. Detta har praktiskt sett visat sig vara ett viktigt steg för att få fram användbara data En fasbaserad metod Istället för att applicera metoden direkt på bilderna filtreras de först med bandpassfiltrerande filter som beräknar fas och magnitud i olika riktningar. Detta främst eftersom fasen är mindre känslig för intensitetsförändringar över tiden, se Fleet och Jepson [16].

63 6.4 Stereofilter Skalpyramid Då algoritmen enbart kan upptäcka disparitet inom ett begränsat intervall används ett system med en skalpyramid för att upptäcka större dispariteter. Initialt byggs en skalpyramid av inbilderna upp och dispariteten för bildparet vid den minsta skalan beräknas. Den dispariteten används vid den näst högsta skalan för att justera den ena bilden mot den andra varefter dispariteten beräknas på dessa bilder. Detta utförs upp till den översta skalan, och dispariteten ackumuleras i varje beräkningssteg. I figur 6.7 visas hela beräkningsflödet för optiskt flöde då en skalpyramid med två skalor används Lågpassfilter En vital del av algoritmen är lågpassfiltreringen av de lokala derivatorna. I referensimplementationen gjordes detta med ett rekursivt filter enligt h(n) = (1 α) f(n) + α h(n 1) (6.15) Detta filter applicers först horisontellt från både vänster och höger och sen vertikalt uppifrån och nerifrån. Ett rekursivt filter är mycket dåligt anpassat för exekvering på en GPU då varje steg i beräkningen beror på det tidigare steget vilket gör algoritmen omöjlig att parallellisera. Ett alternativ till det rekursiva filtret är dess motsvarande icke-rekursiva filter, se figur 6.8. Ska det vara evivalent måste det dock ha oänlig utbredning, eller i praktiken dubbla bredden av bilden som ska filtreras. Detta innebär extremt tunga beräkningar för stora bilder. Lösningen blev att begränsa filtret till en viss längd och sätta elementen till noll utanför det intervallet. En filterkärna med runt element visade sig vara en god kompromiss mellan resultat och prestanda. Vid vissa fall räcker det med punkter Analys Algoritmen är relativt väl anpassad för beräkning på GPU; det är stora datamängder och de flesta delar av algoritmen är enkelt parallelliserbara. Dock innebär användandet av skalpyramiden att antalet renderingspass som krävs ökas markant då algoritmen måste köras separat för varje skala. Vid 5 skalor används sammanlagt 170 enskilda beräkningspass. Datamängden och beräkningsbördan per renderingspass minskar markant i de mindre skalorna; i stället börjar tiden för initialisering och byten mellan framebuffrar att ta överhand. 6.4 Stereofilter Stereoseende innebär att från två bilder samplade från närbelägna positioner beräkna hur långt bort olika objekt i bilderna befinner sig. Den mänskliga hjärnan utför kontinuerligt den operationen på bilderna från ögonen. Stereoseende är ett klassiskt problem inom datorseende. Grundprincipen är att från de två bilderna beräkna den horisontella dispariteten vilket blir ett mått

64 48 Tillämpningar Ackumulerad disparitetsbild skala 1+2 Disparitetsbild skala 1 Bild 1 skala 1 Optiskt flöde Bild 2 skala 1 Justerad Justering för optiskt flöde Bild 2 Skala 1 Uppsamplad disparitetsbild Nersampling Uppsampling Nersampling Disparitetsbild skala 2 Bild 1 skala 2 Optiskt flöde Bild 2 skala 2 Figur 6.7. Beräkning av optiskt flöde med en skalpyramid med två storlekar.

65 6.4 Stereofilter 49 Figur 6.8. Icke-rekursivt lågpassfilter ekvivalent med det rekursiva filter som används i optiskt flöde. Figur 6.9. Inbilder till stereofiltret: vänster- respektive högerbild Figur Resultat från stereofiltret: den horisontella dispariteten mellan de två inbilderna i figur 6.9.

66 50 Tillämpningar på hur långt från kameran objekten i bilden befinner sig. Det finns flera metoder, men de brukar delas upp i area-baserade respektive feature-baserade, se Barnard och Fischler [2]. Feature-baserade metoder bygger på att intressanta detaljer i bildera, till exempel enkelt urskiljbara kanter och hörn, isoloeras och matchas mot varandra. Detta producerar en gles disparitetsbild ur vilken en disparitetsbild med värden för varje bildpunkt vid behov kan approximeras. Area-baserade metoder matchar istället varje bildpunkt inom en omgivning och producerar ett disparitetsmått för varje bildpunkt. Med area-baserade metoder blir beräkningarna ofta mycket lika de som används för optiskt flöde, skillnaden är att de två inbilderna är tagna från olika position istället för från olika tidpunkter samt att det bara är den horisontella dispariteten som behöver beräknas. I det här arbetet används i princip samma area-baserade algoritm för stereo som den som används för optiskt flöde (se kapitel 6.3) men med skillnaden att den vertikala dispariteten aldrig beräknas. I figur 6.9 visas exempel på två inbilder till stereofiltret. Resultatet, den horisontella dispariteten, återfinns i figur Man kan notera att ju ljusare disparitetsbilden är, desto närmare kameran befinner sig objektet Analys Algoritmen som används för stereoseende är på samma sätt som den för optiskt flöde relativt väl anpassad för beräkning på en grafikprocessor. Det är relativt stora datamängder och tunga beräkningar. Skillnaden är att en stor del av beräkningsstegen från optiskt flöde kan undvikas eller slås ihop vilket gör den bättre anpassad då beräkningsbördan per beräkningspass blir något högre.

67 Kapitel 7 Resultat De implementerade algoritmerna har testats och jämförts med motsvarande CPUimplementation. Alla tester har utförts på flera olika storlekar på inbilderna då en grafikprocessor kan skilja mycket i effektivitet beroende på storleken på datamängden. 7.1 Stereofiltret CPU-implementationen av stereofiltret är en väl optimerad implementation där stora delar av algoritmen utnyttjar processorns vektoriserade SSE2-enhet med hjälp av handoptimerad assembler. Som jämförelse har även en mindre optimerad CPU-implementation i ren ANSI-C tagits med. Tester har utförts dels på ett stereofilter där en skalpyramid bestående av 5 olika bildstorlekar använts, och dels där bara den största skalan använts. Resultaten från dessa körningar kan ses i figur 7.1 respektive 7.2. Siffrorna som anges är behandlade bildpunkter per sekund, det vill säga inbildernas storlek delat med den totala tiden för beräkningen. Tiderna för nerladdning av inbilder och tillbakaläsning av resultatbilder är medräknade. Man kan notera att CPU-versionen har ungefär konstant beräkningstakt när bilderna är relativt små, men för större bilder blir takten lägre. Detta kan troligtvis 5 skalor 1 skala Intel Pentium GHz HT (SSE2) 1,00 1,00 Intel Pentium GHz HT (ANSI-C) 0,22 0,19 Nvidia GeForce Go ,87 1,73 Nvidia GeForce 6800 GT 2,01 1,89 Nvidia GeForce 7800 GTX 4,05 3,44 ATI Radeon X850 XT PE 1,79 1,86 ATI Radeon 9800 Mobility 0,75 0,60 Tabell 7.1. Uppsnabbningsfaktor för stereofiltret för några olika grafikprocessorere jämfört med referenslösningen för CPU. 51

68 52 Resultat Genomsnittlig beräkningstakt [Mpixel/s] Nvidia GeForce 7800 GTX Nvidia GeForce 6800 GT Nvidia GeForce Go 6800 ATI Radeon X850 XT PE ATI 9800 Mobility Intel Pentium4 3.2 GHz HT (SSE2) Intel Pentium4 3.2 GHz HT (ANSI C) Bildstorlek [pixlar 1/2 ] Figur 7.1. Genomsnittlig beräkningstakt för stereofiltret med 5 skalor Genomsnittlig beräkningstakt [Mpixel/s] Nvidia GeForce 7800 GTX Nvidia GeForce 6800 GT Nvidia GeForce Go 6800 ATI Radeon X850 XT PE ATI Radeon 9800 Mobility Intel Pentium4 3.2 GHz HT (SSE2) Intel Pentium4 3.2 GHz HT (ANSI C) Bildstorlek [pixlar 1/2 ] Figur 7.2. Genomsnittlig beräkningstakt för stereofiltret med en skala.

69 7.2 Optiskt flöde 53 förklaras med att den är starkt cache-beroende. Vid beräkning av större bilder får en mindre andel av bilden plats i cache-minnet och läsningar från systemminnet måste oftare utföras. GPU-versionen däremot kan man se är mycket långsam vid de minsta bildstorlekarna men blir snabbt effektivare vid större bildstorlekar. Detta eftersom ställtiden för varje beräkningspass kan amorteras och får mindre betydelse när datamängden per beräkningspass blir större. Brytpunkten för när GPU-versionen är snabbare än den optimerade CPU-versionen är vid bildstorlekar på mellan och beroende på vilken grafikprocessor som används. För stereofiltret där bara den högsta skalan används sker brytningen vid något mindre bildstorlekar. I tabell 7.1 finns en sammanställning över uppsnabbningsfaktorn för olika grafikprocessorer jämfört med den optimerade CPU-versionen. För varje arkitektur har den högst uppnådda beräkningstakten delats med den högst uppnådda beräkningstakten för den optimerade CPU-versionen, det vill säga beräkningstakten för den bildstorlek där den CPU-imlementationen presterade som bäst jämförs med beräkningstakten för den bildstorlek där den GPU-imlementationen var som bäst. Man kan se att det skiljer ganska mycket mellan olika grafikprocessorer men att det är möjligt att få en uppsnabbning på upp till 4 gånger med en modern grafikprocessor. 7.2 Optiskt flöde Referensalgoritmen för optiskt flöde är inte lika väl optimerad som stereofiltret, framför allt använder den inte CPUns vektorinstruktioner (SSE2) i lika stor utsträckning. Detta medför en i någon mening orättvis jämförelse då en bättre optimerad CPU-version skulle kunna blir signifikant snabbare än den som används. Dock får man även ta i beaktning att en sådan CPU-version skulle ta mycket lång tid att implementera; CPU-versionen och GPU-versionen är nu båda skrivna uteslutande i högnivåspråk och kan anses ha likartade utvecklingstider. Om man istället tittar på den optimerade stereoalgoritmen så har den tagit mycket längre att utveckla och är dessutom svårare att underhålla då den till stora delar består av handoptimerad assembler-kod Kvalikativ jämförelse Resultaten från beräkningar av optiskt flöde skiljer sig något mellan GPU-versionen och CPU-versionen då lågpassfiltreringen utförts på ett annat sätt samt att vissa randvillkor behandlats olika. I figur 7.3 visas de två inbilder som använts vid utprovningen. Den högra bilden är den vänstra bilden roterad tre grader medurs. Vid beräkning av optiskt flöde mellan dessa två bilder ska den horisontella dispariteten idealt sett bli en vertikal gradient och den vertikala dispariteten en horisontell gradient. I figur 7.4 återfinns resultatet från referenslösningen, horisontell disparitet till vänster och vertikal disparitet till höger. En vit bildpunkt i den horisontella dispariteten representerar en förskjutning åt vänster, en svart bildpunkt representerar en förskjutning åt höger och en grå punkt ingen förskjutning. På

70 54 Resultat Figur 7.3. Testbilder till optiskt flöde. Den högra bilden är samma som den vänstra roterad 3 grader medurs. Figur 7.4. Horisontell respektive vertikal disparitet från referenslösningen för beräkning av optiskt flöde applicerat på bilderna i figur 7.3 Figur 7.5. Horisontell respektive vertikal disparitet från GPU-versionen av optiskt flöde applicerat på bilderna i figur 7.3