Den tekniska utvecklingen av hårdvara och mjukvara för realtidsgrafik

Den tekniska utvecklingen av hårdvara och mjukvara för realtidsgrafik Anders Andersson aaa99005@student.mdh.se CD5420 - Vetenskap inom dataområdet, 2002-10-15 1

Sammanfattning Rapporten har en fokusering på den tekniska utvecklingen av hårdvara och mjukvarusystem för realtidsgrafik. Utvecklingen har varit oerhört snabb och framgångsrik. För att den ska fortsätta vara det och gå i rätt riktning finns det några viktiga aspekter som mjukvaruingenjörer ska ta hänsyn till när de konstruerar realtidstillämpningar med datorgrafik. Aspekter såsom : parallellisering av applikationer så långt som möjligt, parametrisering av viktiga systembeteenden pipelinesynen vid konstruktion av systemet är viktiga för att applikationer fullt ut ska kunna utnyttja dagens och framtida hårdvaruacceleratorer. 2

Innehållsförteckning Inledning... 4 Historik... 4 Teori... 5 Applikationssteget... 6 Geometristeget... 6 Modell och vytransformationen... 6 Ljussättning... 7 Projektion... 7 Klippning... 7 Skärmtransformation... 7 Rastreringssteget... 7 Framtid... 8 Slutsats... 9 Referenser... 10 3

Inledning Scener som den på framsidan kommer att bli en artificiell verklighet som du och jag kan gå omkring i om några år. Datorgrafik är för närvarande en av de mest kommersiellt och tekniskt expansiva områden i datorbranschen. Endast den grafikintensiva datorspelsbranschen omsatte redan för något år sedan mer pengar än filmbranschen. Prestandaökningen för hårdvara inom datorgrafik, inte bara följer Moores lag 1, utan är tre gånger prestandaökningen hos mikroprocessorer. Hur länge kommer detta att fortgå och vad krävs för att mjukvarutillämpningar skall dra nytta av all extra beräkningskraft så att vårt mål kan besannas? Historik Datorgrafik föddes med plotterskrivarna och CRT-skärmarna. Den har idag kommit att innefatta skapandeprocessen, lagring, och manipulation av modeller eller bilder av objekt. Objekt kan vara allt från matematiska abstraktioner till krigande monster. Idag är tillämpningar till stora delar interaktiva p.g.a. den ökande datorkraften och vår strävan efter interaktivitet. Fram till 1980-talet var området litet och mycket specialiserat, grafikhårdvara och mjukvara var dyr och användarvändliga grafikapplikationer få. Men detta förändrades i och med lanseringen av PC-datorn, som hade inbyggd rastergrafik (Xerox Star, Apple Macintosh och senare IBM PC). Rastergrafiken möjliggör användandet av bitmapgrafik som när den blev tillgänglig till ett rimligt pris resulterade i en explosion av användarvänliga grafikbaserade applikationer och användargränssnitt. Den tekniska och kommersiella utvecklingen, kanske mest för grafikhårdvara, tog fart senare delen av 90-talet, då det amerikanska teknikföretaget 3Dfx Interactive lanserade det första 3D-accelererande grafikkortet för en konsumentmarknad, få förutspådde sån potential, man kan rentav säga att 3Dfx skapade marknaden. Med kortet lanserades ett enkelt och optimerat API 2, Glide. API:et med OpenGL som förebild gjorde omgående succé i spelbranschen. Prestandaökningen med en 3Dfx produkt var ansenlig. Med tiden har Glide tappat sitt försprång gentemot OpenGL och Mirosofts DirectX, i takt med att 3Dfx fått en allt mindre roll på marknaden. Idag används nästan uteslutande Microsofts DirectX eller OpenGL som API för datorgrafik. OpenGL har länge haft problemet att utvecklingsprocessen varit så långsam att tekniken inte varit i paritet med ny hårdvara, något som verkligen inte gynnar ett API. För att lösa detta använde man sig av diverse tillägg till API:et, inga av vilka var standard. Intressant för senaste OpenGL versionen är implementeringen av shaders 3 och formulering av ett nytt standardiserat språk för shaders med tillhörande kompilator. Microsoft har haft den fördelen med DirectX att de inte behöver lyssna på någon annan utan kan implementera ny funktionalitet omgående, och förbättra implementationen med tiden. 1 Moores lag - antalet transistorer per kvadrattum på en IC-krets fördubblas vart år, eller den moderna tolkning att datadensiteten fördubblas var artonde månad, ger en acceleration för prestanda på ungefär 10 ggr / 5 år 2 API - Application Programming Interface 3 Samling matematisk operationer, små program, som utförs per-vertex samt per-pixel 4

Teori Datorgrafik är alltså skapandeprocessen, lagring, och manipulation av modeller eller bilder av objekt. Vanliga grundläggande termer är: Polygon flerhörning (minst tre hörnpunkter, triangel) Vertex en hörnpunkt i en polygon Pixel kort för Picture Element, bildelement Textur bild som appliceras på en polygonyta En modell består ofta av flera polygoner eller trianglar, annars kan en sådan representation alltid genereras utifrån en annan. Detta antas därför hädanefter. Kärnan i implementationer av realtidsgrafik är den s.k. grafikpipeline:n. Dess huvudsakliga uppgift är att generera eller rendera en tvådimensionell bild, givet en observatör (virtuell kamera), tredimensionella modeller, ljuskällor, ljusmodeller, texturer osv. Grafikpipeline:en kan delas in i olika konceptuella steg, figur 1, som i sin tur ofta kan delas in i olika steg lite beroende på tillämpning. Applikation Geometristeget Rastrering Figur 1: Grafikpipeline, bestående av tre konceptuella steg. Varje steg kan i sig också innehålla steg eller en pipeline, ofta också parallellt exekverande steg i komplexare tillämpningar (se transformationssteget, steg 2). Indelning med en pipeline i n steg ger teoretiskt en hastighetsökning med en faktor n (om stegen körs parallellt), vilket är anledningen till att det används så flitigt. Flaskhalsen i konstruktionen är det långsammaste steget (eftersom de andra stegen är beroende av det data flaskhalssteget producerar) vilket sätter gränsen för hur snabbt systemet exekverar och därmed också renderingshastigheten. I olika sammanhang avses olika typer av steg, det finns: Pipelinesteg, kan köras samtidigt med alla andra pipelinesteg Funktionella steg, utför en viss uppgift, men specificerar inte hur det exekverar i pipeline:en Konceptuella steg, övergriplig indelning av systemet 5

Applikationssteget Utvecklare har störst kontroll 4 över vad som händer i applikationssteget, eftersom det alltid exekverar i mjukvara. För att förbättra prestanda i systemet kan alltid implementationen ändras. I de andra stegen är det svårare att ändra implementationen eftersom den till stora delar bygger på hårdvara. Det man kan göra är att indirekt styra tiden transformation och rastreringssteget tar genom att minska antalet primitiver (punkter, linjer och trianglar) som ska renderas, i applikationssteget. En konsekvens av att applikationssteget alltid exekverar i mjukvara är att steget inte delas in i delsteg. Men för att öka prestanda kan steget exekvera samtidigt i parallell på flera processorer (superskalär konstruktion). En process som man vanligen implementerar i applikationssteget är kollisionsdetektion och hantering, hantering av användarinput, olika tekniker för reducering av geometrisk data osv. Geometristeget Geometristeget svarar för majoriteten av per polygon eller vertex operationer. 5 Steget är ytterligare uppdelad i funktionssteg [Lamothe91], se figur 2. Beroende på implementation kan de olika funktionella stegen vara identiska med pipeline steg. Modell-vy transformation Ljussättning Projektion Klippning Skärm transformation Figur 2: Geometristeget uppdelat i funktionella steg Modell och vytransformationen Från applikationen till skärmen transformeras modeller till olika koordinatsystem för att göra manipulationer så flexibla och intuitiva som möjligt. Ursprungligen befinner sig modellen otransformerat, i ett för den, lokalt koordinatsystem (ofta kallat model space eller local space). Modeller associeras sedan med en modell transformering vilket möjliggör att flera modeller kan dela minne för grundläggande geometri. När modelltransformering appliceras på de ursprungliga punkterna och normalerna i det lokala koordinatsystem erhålls punkter och koordinater i det s.k. världskoordinatsystemet. I världskoordinater finns alla modeller i samma koordinatsystem liksom kameran eller observatören utifrån vilken den egentliga vyn ska beräknas. 4 På applikationsnivå kan man t.ex inte helt garantera att en viss process tar en bestämd tid eftersom operativsystemet kan schemalägga andra processer för exekvering innan den specifika processen exekverat klart 5 Inte fallet vid t.ex vertex morphing som äger rum i applikationssteget pga tidsberoendet 6

För att möjliggöra projektion och klippning utförs också en vy-transformation på kamera och modeller, se figur 3. Transformationen placerar kameran i mitten av koordinatsystemet riktad mot den negativa z-axeln alternativt positiva z-axeln, beroende på implementation. vyriktning vytransformation Figur 3: Den vänstra bilden visar scenen med objekt och kamera innan vytransformationen och den högra scenen efter transformationen. Den ljusgrå delen är vyvolymen (antar konformad vyvolym pga perspektivprojektion) som bl.a. klippning sker utefter. Ljussättning Modellerna kan ha färg associerade till sina ytor och ljuskällor ska påverka färgen på ytor på något speciellt sätt enligt en s.k. ljusekvation som ska approximera de fysikaliska företeelserna (fotoner och ytor). Modeller representeras ofta som trianglar och vid varje hörnpunkt räknas en färg ut med avseende på t.ex. triangelns ursprungliga färg, normaler, position och typ av ljuskälla. Projektion Projektion normerar kamerakoordinater. Transformationen är ofta av typen perspektivtransformation vilken tar hänsyn till perspektiv (objekt längre bort ser mindre ut) vid transformeringen. Klippning Den vy-volym som projektionen gav upphov till används här för att testa om geometri är synlig eller inte, se figur 3. Geometri som inte är synlig förkastas (inga mer beräkningar utförs på geometrin under den här bilden). Geometri som är helt synlig skickas vidare till skärmtransformationen. Om geometri är halvt synlig i vyvolymen klipps geometrin och endast den synliga geometrin skickas vidare. Skärmtransformation Primitiverna inuti vyvolymen skickas till skärmtransformation. X- och Y-koordinater för varje primitiv transformeras till skärmkoordinater. Z-komponten skickas vidare till rastreringssteget. Rastreringssteget Givet transformerade och projicerade hörnpunkter, färger och texturkoordinater (från geometristeget) är målet med rastreringssteget att tilldela korrekta färger till alla bildelement för att rendera en bild korrekt (rastrering). Rastreringssteget hanterar alltså per-pixel operationer till skillnad från geometristeget som hanterar per-polygon operationer. För hög prestanda bör rastreringssteget vara implementerad i hårdvara [Blinn96]. 7

Teknik Den tekniska utveckling inom grafikhårdvara går till stora delar så bra p.g.a. tidigare framsteg inom datorarkitektur. Fler och fler funktioner integreras i hårdvara för att öka prestanda, funktionaliteten blir allt mer generell. Dagens grafikkort (2002) har internt minne i samma storleksordning som primärminnet, för lagring av bl.a. geometri och bildelement (pixel), integrerad minneskontroller som är state-of-the-art t.o.m. för moderkortstillverkare, dedicerad databuss med DMA 6. Fler och fler pipelinesteg implementeras i hårdvara; från att bara ha accelererat delar av rastreringen till att nu också innefatta hela geometristeget och rastreringssteget. På mikronivå (aritmetiska och logiska operationer) sker prestandaökningen som bekant genom parallellisering. För att öka den visuella kvalitén bör lämpligen exekveringshastigheten och storleken för vertex- och pixelprogram 7 ökas. Intressant är att det rent teoretiskt finns en gräns för de senare vilket bör ses som god motivering till att prioritera den visuella kvalitén till förmån för transformationer. Framtid Prognoser är svåra att göra, speciellt av framtiden Niels Bohr För att få begrepp om den beräkningskraft som krävs för verklighetstrogna miljöer, kan nämnas att det för Pixars filmproduktion A Bugs Life (1998) tog en 330MHz UltraSPARC tre till fyra timmar i snitt att generera en bild (mycket komplexa, men ovanliga bilder, upp till 20 timmar) och en gigabyte minne av bara geometrisk data [Möller99]. För att uppfylla ett minimalt realtidskrav på 12 bilder/sekund behövs en uppsnabbning med ungefär 150 000 gånger. Moores lag ger en acceleration på 2 gånger per 1.5 år eller 10 gånger på 5 år. Enligt Moores lag, bara, kan man tidsbestämma realtidslösningar för scener såsom A Bugs Life och scener med liknande komplexitet till om cirka 22 år. Fast det kan ta längre tid, Moores lag kan ju upphöra att gälla p.g.a. någon orsak 8. Men det kan också ta kortare tid. Konsumentinriktade grafikchipset fördubblar för närvarande sin prestanda var sjätte månad och förväntas följa den trenden i en nära framtid p.g.a. hög konkurrens på marknaden, breddat kundunderlag och den effekt detta ger i form av tillväxt och utveckling inom industrin, och förbättrade arkitekturer och algoritmer. Situationen verkar dock osannolik att fortgå och applikationsprocessorer följer fortfarande Moores lag, men det är ett intressant fenomen. Håller det i sig kan A Bugs Life genereras i realtid år 2007. Att ge korrekta prognoser är ofta svårt p.g.a. slumpens inverkan. Det man däremot lättare kan ge, är prognoser om vad som inte kommer att inträffa: Processorer och grafikkort blir tillräckligt bra Datorgrafik blir tillräckligt komplext eller överflödigt PDA:er och mobiltelefoner kommer aldrig att vara i behov av realtidsgrafik 6 Direct Memory Access Direkt minnesåtkommst, huvudprocessorn belastas inte av minnesoperationer som kringenheter utrustade med detta utför. 7 Eng. shaders - Samling matematisk operationer, små program, som utförs per-vertex samt per-pixel 8 För halvledarteknik - ledare måste rymma elektronen, elektriska störningar på nanonivå, värmeutveckling osv. 8

Det är intressant också att se hur intressenter på realtidsgrafikmarknaden är beroende av varann och hur den påverkar andra marknader, för det gör den. Det finns många beräkningsintensiva applikationsområden så som simulering av fysikaliska företeelser och kryptering osv. Realtidsgrafik är bara en av dem, men ett som miljontals människor kommer i kontakt med genom dataspel. Mikroprocessoraktörer, bl.a. Intel 9 och i mindre grad AMD 10, förstår naturligtvis detta och fokuserar hela instruktionsuppsättningar på datorgrafik. Grafik säljer spel och spel säljer hårdvara. En av de bästa aspekterna med datorgrafik från ett marknadsföringsperspektiv är att grafik kräver mycket datorkraft. Det finns några möjliga utvecklingar och gränslinjer. Uppdateringsfrekvens av bilden 11 - frekvenser över 72 Hz är oskiljbara för det mänskliga ögat [Foley99]. Argument för högre frekvens kan däremot vara en minskning av responstid. Mot detta talar att responstiden ändå kan minimeras om systemet (programmet) konstruerats korrekt från början. Skärmupplösning IBM:s röntgen display ger 2560x2048 pixel:s med 200 DPI 12, 1200 DPI har många skrivare idag. Bit:ar per pixel 24 bitar används idag 13 och är mer än tillräckligt för färgvisning. Det mänskliga ögat uppfattar mindre än 10 milj. färger vid sida-vid-sida jämförelse av färger och kan bara särskilja 300 olika färger direkt från minnet, synmekanismen är dessutom känslig för yttre påverkan [Schils02]. I den 32-bit:ars grafik som ibland används, tillsynes onödig, används en 8-bitars s.k. alfa-komponent för att beräkna genomskinlighet (är ingen färg och kan genereras betydligt smidigare). En utveckling utan gräns är scenkomplexitet, antalet objekt och sätt objekt renderas i en scen. Djupkomplexiteten i scener ökar, primitiver blir mindre, belysningsmodeller mer komplexa osv. Det finns argument för att man på sikt bäst löser problemet genom någon form av raytracing 14, antagligen massivt distribuerad (en uppvisning i divide-andconqurermetodik om inte annat). Slutsats För att vara i paritet med hårdvaruutvecklingen bör realtidsgrafikmjukvara parallelliseras i högre grad. Parallell behandling av data som har betydelse för kollisiondetektion och hantering är ett exempel på en relativt enkel åtgärd. Eftersom realtidssystemen i mycket hög grad är dynamiska bör stora delar av systemet vara parametriserat så att man m.h.a reglerteknik eller annan, mer utpräglad, maskininlärning kan konfigurera köer, periodtider, parallellisering osv. 9 Med MMX-instruktionerna som praktexempel men också de senare SEE och SEE2 är klart spelinriktade 10 3DNow!-instruktionerna är spelinriktade och senare integrering av DSP-instruktioner för stöd för b.la video 11 FPS Frames Per Second, den frekvens som grafikkortet uppdaterar skärmen med nya bilder. 12 DPI Dots Per Inch Bildpunkter per tum 13 8 bit för röd, 8 bit för grön och 8 bit för blå färg. Ger totalt 16777216 teoretiskt olika färger. 14 För varje bildelement skjuts ett knippe strålar ut i scenen, vid interferens och intersektioner mellan objekt och strålen beräknas färgvikter. Strålen ger tillsammans med de andra strålarna i knippet upphov till en bildpunkt. Alla bildpunkter på för skärmen bildar bilden. 9

Referenser [Foley99] [Blinn96] [Möller99] Foley, van Dam, Feiner, Hughes Computer Graphics Principles and Practice, Addison Wesley, 1999 Jim Blinn, A trip down the Graphics Pipeline, Morgan Kaufmann Publishers, 1996 Tomas Möller, Eric Haines, Real-Time Rendering, A K Peters Ltd, 1999 [Lamothe91] André Lamothe, Black art of 3D Game Programming, Waite Group Press, 1995 [Schils02] Paul Schils, Color Phenomena, <http://home.wanadoo.nl/paulschils/11-eye.html>, 2002-09-04 10