Computaci de prop` sit general en processadors o o gr` cs a

` Oscar Barenys Garcia, Ivan Barenys Garcia Dept. of Computer Engineering and Maths, Universitat Rovira i Virgili, Av. Pasos Catalans 26, E-43007 Tarragona, Catalonia, Spain e-mail {oscar.barenys,ivan.barenys}@urv.cat

Abstract Last decade, graphics cards have evolved from performing texturing operations to being an array of fully programmable processors. This evolution has been driven by the computer games industry. In 1999, the rst graphics processors which accelerated all the traditional rasterization pipeline in hardware were introduced. This graphics chips were named GPUs (graphics processing units) following the analogy of CPUs (central processing unit). Since then, new generations of GPUs have centered in transforming some xed stages of the rasterization pipeline into fully programmable ones. Since some of these programmable stages provide a lot of computational power, GPUs have been seen as commodity supercomputers. In fact, they provide oating point processing power some orders of magnitude above CPUs. This have attracted researchers, who have found ways to use that power for general computations, starting a eld of research known as GPGPU computing (general purpose computing in GPUs). But, at least until very recently, both hardware, who has had some limitations, and the languages for programming it, who relying in existing graphics APIs have prevented using all the programmability of the underlying hardware, had become the two principal reasons for not being able to port some algorithms. This survey begins describing the evolution of GPUs and the new features they have been adding over time. It follows describing the computing model who abstracts GPUs well: the streaming computing model. At this point the two key points of the survey are exposed: GPU computing benets and limitations, and the available languages and tools for programming it. It ends enumerating briey, general algorithms which have been successfully ported to the GPUs, and describing what to expect from future GPU architectures. The aim of the paper is to encourage researchers to start programming with GPUs and nding new techniques for extracting their high computing power. Keywords: Graphics Processing Unit (GPU), Stream Computing model, GPGPU, High performance computing,Parallel computing.

posici , orientaci i camp de visi . Descriure la posici , o o o o orientaci i camp de visi de la c` mera es equivalent a xar un o o a punt de vista i un rectangle, el pla dins del qual es troba inscrit no cont el punt de vista. Aquest pla sanomena pla de visi e o i el rectangle marc de visi . El marc de visi cont limatge o o e 2D desitjada i pot entendres com el lm de la c` mera virtual. a Es busca una soluci discreta de la imatge 2D desitjada. Per o aix` es subdivideix el marc de visi en una malla de MxN o o subrectangles. La imatge 2D cercada es una discretitzaci del o marc de visi que contindr` MxN valors de color (anomenats o a picture elements o pxels) corresponents a un representant del color de cada subrectangle. Cada pxel sidentica per un parell de coordenades que lidentiquen unvocament dins la malla de MxN pxels. Sanomena a aquestes, coordenades del pxel. Per obtenir aquesta soluci es disposa essencialment de o dos m` todes: els m` todes de tracats de raigs i els m` todes de e e e rasteritzaci . Senuncien les seves caracterstiques: o

I. M OTIVACI O DE LES GPU S : EL PROBLEMA DE LA SNTESI REALISTA I INTERACTIVA D ENTORNS 3D I A. M` todes de sntesi dimatges dentorns 3D e La sntesi dimatges realista dentorns 3D t per objectiu la e sntesi dimatges 2D que recren un entorn 3D vist des duna certa posici i amb una certa direcci , orientaci i camp de o o o visi . La soluci obtinguda es la mateixa que la que sobtindria o o situant una c` mera virtual en aquest entorn amb la mateixa a

M` todes de tracat de raigs. Aquests s n els que e o aconsegueixen una simulaci m s acurada de la realitat o e per` requereixen duna enorme pot` ncia de c` lcul i en o e a computadors de gran consum no permeten la sntesi dentorns 3d en temps real. Es basen en tracar raigs que simulen el cam invers que segueix la llum des dun emissor de llum ns un punt de vista tenint en compte les possibles reexions, refraccions, dispersions o absorcions que aquesta sofreix degut al interaccionar amb els diversos elements del medi: objectes, atmosfera, fum, aigua, etc. . . Es traca un raig (o varis) per a cada picture element, es a dir, un raig que comenca al punt de vista i interseca amb el marc de refer` ncia en un dels MxN subrectangles e associat al pxel. M` todes de rasteritzaci . Els m` todes de rasteritzaci e o e o s n una simplicaci dels m` todes de tracat de raigs o o e on no es permeten ni reexions perfectes ni refraccions. Tampoc es permeten reexions m ltiples o refraccions u m ltiples amb un material. Amb aquestes simplicacions u un raig de llum que arriba al punt de vista nom s pot e vindre directament duna font de llum o indirectament

 via nom s una reexi amb un objecte. Es a dir, aquest e o m` tode considera nom s la illuminaci directa. Aquesta e e o observaci permet obtenir una nova soluci per aquest o o m` tode. Conceptualment aquesta consisteix en projectar e els objectes sobre el marc de visi . Cada objecte projectat o recobrir` parcialment o totalment certs subrectangles del a marc de visi associats a cada pxel. Per cada pxel o recobert generarem un fragment (estructura que emmagatzema posici del pxel que lha generat, color i la o dist` ncia entre el punt de visi i el punt de lobjecte que a o sha projectat sobre el pxel que representa el fragment). El color que sassocia a un fragment es funci de la font o de llum de lescena, el punt material el qual sha projectat sobre aquest fragment i les propietats del material que constitueix lobjecte. Aquesta funci representa un model o dilluminaci . El model suposa que m ltiples llums o u actuen de forma additiva e independent sobre el color nal. Lobtenci del color dun fragment rep el nom de o ombreig del pxel. Aix es clar que la imatge cercada es pot obtenir de la seg ent manera: per cada pxel es u busquen tots els fragments amb la posici igual a la del o pxel i es cerca el pxel que tingui menys profunditat, llavors el color que sha dassignar a aquest pxel, es el del color daquest fragment. ` II. H IST ORIA DE LES GPU A. Primera generaci : Acceleraci completa o o Degut a que els m` todes de rasteritzaci eren els m` todes e o e m s utilitzats degut a la baixa capacitat computacional de e l` poca es van crear implementacions est` ndards i ecients e a del m` tode de rasteritzaci i APIs per a fer-ne us daquestes. e o En principi aquestes APIs eren propiet` ries i per tant la seva a evoluci venia donada pels interessos del fabricant que les o desenvolupava. Un exemple de implementaci fou la llibreria o IrisGL de Silicon Graphics. A nals de la d` cada dels 80, es van introduir sistemes e gr` cs que acceleraven certes parts del m` tode de rasteritzaci . a e o Aquest sistemes gr` cs es trobaven en computadors dalta a gama (ordinadors de m s dun mili de d` lars), i normalment e o o acceleraven les API dels fabricants dels sistemes gr` cs i a a la seva vegada nom s funcionaven en els seus sistemes e operatius. Per exemple els sistemes gr` cs de Silicon Graphics a acceleraven IrisGL. Va arribar un moment, en que coexistien diverses APIs gr` ques i diversos sistemes gr` cs, existint una forta incoma a patibilitat entre aquests. Aquest fet, va motivar la creaci duna o API est` ndard multifabricant i multisistema operatiu. Aquest a esforc conclogu al 1992 amb la creaci dOpenGL, derivat e o en gran part de lIrisGL. Amb una API est` ndard moltes a empreses van crear processadors gr` cs que acceleraven certes a etapes de lAPI 3D. Als 99 Nvidia va anunciar un nou processador gr` c que accelerava totes les etapes del m` tode a e de rasteritzaci i que oferia unes prestacions comparables a o la dels millors sistemes gr` cs de feia just una d` cada (que a e costaven de lordre d1M de d` lars) per un preu de 500 d` lars. o o El fabricant anomen` al processador gr` c GPU (Graphics a a

Processing Unit), emfatitzant el processador gr` c com un a component principal duna computadora, com el processador. Aquestes llibreries van identicar una organitzaci en la o computaci dels m` todes de rasteritzaci que permetia realo e o itzar implementacions hardware (sistemes gr` cs) ecients. a Aix les APIs reectien aquesta estructura. Aquesta estructura rep el nom de graphics pipeline i es una estructura an` loga a a la duna cadena de muntatge duna f` brica. Per obtenir el a resultat desitjat (els color dels pxels de la imatge desitjada) hi ha un conjunt detapes que treballen de forma independent. Lentrada duna etapa es la sortida de letapa que la precedeix excepte la primera etapa que accepta v` rtexs. La sortida de e lultima etapa es limatge sintetitzada. Com que aquestes etapes poden treballar de forma independent sha dividit el problema de la rasteritzaci en tasques independents i que es o poden executar de forma parallela. Hi ha quatre etapes diferenciades: Processament de v` rtexs. e Muntatge de primitives. Rasteritzaci . o Processament de fragments. LAPI exposa de manera clara les diverses etapes aix com variables de cada etapa que xaven un estat doperaci o daquestes. A grans trets el funcionament es el seg ent: u Laplicatiu que interacciona amb lAPI descriu els objectes de lescena mitjancant conjunts de primitives poligonals (tri angles p.ex.). Per cada v` rtex de la primitiva envia informaci e o addicional, com atributs de color, coordenades de textura i vector normal ( s necessari pel model dilluminaci ). Una e o textura es una malla de colors que permet denir a una o v` ries primitives amb color no constant. Les coordenades de a textura dun v` rtex permeten saber el color daquest, adrecant e la textura amb aquestes. La primera etapa sencarrega de fer operacions matem` tiques sobre els v` rtexs: projectant els v` rtexs a e e sobre el pla de visi i calculant el color daquest pel model o dilluminaci i el tipus de material xat per lusuari via o funcions de lAPI. Aquesta etapa transforma un v` rtex en un e v` rtex sobre el pla de visi i li assigna un color. Aquesta e o etapa tamb se la coneix com etapa de trasform&light. La e segona etapa sencarrega dassociar conjunts de v` rtexs a e primitives com triangles o polgons convexos.. La tercera etapa (rasteritzaci ) es la que sencarrega de generar els o fragments associant-lis a cadascun un color, una profunditat i unes coordenades de textura que s n interpolades linealment o entre les dels v` rtexs que formen la primitiva (interpolaci e o datributs). Finalment letapa de processament de fragments sencarrega daplicar textures a partir de les coordenades de textura de cada fragment. Aquesta rep el nom de etapa de sombreig de fragment. Per ultim hi ha un buffer que emmagatzema el fragment amb profunditat menor en cada moment. Aix` ho aconsegueix comparant la profunditat dun o fragment amb la del pxel emmagatzemat i si es menor la del fragment, emmagatzema aquest. Es vol fer notar la difer` ncia e subtil que hi ha entre un pxel i un fragment. Un fragment es un pxel en pot` ncia. Es a dir, si aquest supera la comparaci e o

de profunditat, sescriu el seu valor al buffer i llavors aquest passa a anomenar-se pxel. Realment un fragment ha de superar unes quantes proves (comparacions), entre elles la de profunditat, ns a esdevenir un pixel. Aquestes comparacions es poden programar en certa mesura i el conjunt de totes elles rep el nom de operacions de fragment, podent denir una etapa addicional. La gura 1 mostra la pipeline tradicional amb les diferents etapes que la caracteritzen, aix com les dades que aquestes generen a partir dels de letapa anterior.

m ltiples processadors gr` cs, increments en la precisi de u a o nombres otants, etc.. III. P ROGRAMACI O GENERAL EN GPU A. Motivaci o Tot i que els gran salts qualitatius en GPUs es solen donar cada 3 o 4 anys, la pot` ncia de c` lcul daquestes es duplica e a aproximadament cada any. Aquest es un ritme exponencial molt m s r` pid que el dels processadors. Es ben sabut que el e a rendiment dels processadors es duplica cada 18 mesos. Aquest fet, es una llei emprica que fou formulada per Moore i que els fabricants de processadors intenten mantenir-la acurada mantenint aquesta cad` ncia en la incorporaci de nous processos e o de integraci . Aix` ha donat lloc a que les GPUs actuals o o permetin una pot` ncia de c` lcul ordres de magnitud superior a e a la de les CPUs. La gura 2 mostra una comparaci daquests o dos tipus de processadors. La pot` ncia de c` lcul ve mesurada e a en ops o operacions en coma otant per segon amb precisi o simple. El terme GFLOP o GigaFLOP fa refer` ncia a 109 e operacions per segon. A la taula, ATI i NVIDIA fan refer` ncia e a procesadors gr` cs daquests fabricants mentre INTEL fa a refer` ncia a procesadors tradicionals (CPUs). e

Fig. 1.

Pipeline gr` ca tradicional. a

B. Segona generaci : programabilitat o Tot i que aquest processador gr` c incorporava tot a el pipeline al hardware les diferents etapes del proc s(stages) tenien una limitada conguraci . Per exe o emple, es podia congurar latenuaci duna llum, el color o daquesta, etc.. per` el model de lilluminaci es trobava xat o o al hadware. Desde llavors la evoluci ha anat centrada en oferir o programabilitat a certes parts del proc s. Per programabilitat e senten que podem executar un programa arbitrari en una etapa de la pipeline. Un moment important en levoluci o dels processadors gr` cs fou a nals de 2002 quan sofer a programabilitat a dues etapes molt importants del proc s: els e v` rtexs i els pxels (en realitat els fragments). El programa en e principi es el mateix per tot un conjunt. Es pot anar-ho canviant per cada conjunt de elements (pxels o v` rtexs), per` canviar e o el programa requereix relativament molt de temps i per tant es canvia despr s de processar molts elements. Sha de notar e que aquest canvi es necessari si volem modelar liluminaci de o diferents materials, degut a que la implementaci en un mateix o programa de diferents models diluminaci no es ecient (ja o que requereix branques). Veure III-D. Els programes reben el nom de shaders o ombrejadors i fan refer` ncia a que e en principi aquesta programabilitat venia donada per recrear models diluminaci arbitraris. o Fins avui en dia levoluci dels processadors gr` cs ha anat o a dirigida a disminuir les limitacions que presentaven aquestes etapes programables. Millores que han experimentat han sigut: habilitat per executar codi condicional, augment de nombre de registres temporals o constants, capacitat de denir programes m s llargs, etc.. e A m s a m s shan continuant oferint noves possibilitats: e e textures amb valors en coma otant, modes de ltratge de pantalla i textura amb m s qualitat i/o velocitat, textures e 3D, augment de les dimensions de textura m` xima permeses, a optimitzacions en el buffer Z, capacitat de treball parallel de

Fig. 2.

Evoluci de la pot` ncia de c` lcul de les CPUs i GPUs. o e a

Aquest ritme daugment de la pot` ncia juntament amb els e salts qualitatius de cada generaci , va afavorir limplementaci o o dalgorismes en GPU amb rendiments superiors als que proporcionaven els processadors de l` poca. Aquesta tend` ncia e e es va iniciar amb la segona generaci de processadors gr` cs. o a Aquest fet va fer que molts investigadors es veiessin atrets per portar certs tipus dalgorismes a la GPU. Aix sha creat un nou camp de recerca conegut com GPGPU o computaci de o prop` sit general en GPU. Aquesta disciplina sencarrega de o portar de manera ecient algorismes a la GPU, o en cas de que aix` no sigui possible intentar de trobar nous algorismes o que resolent el mateix problema que els originals permetin una implementaci ecient en GPUs. Veure III-B. o B. Algorismes parallelitzables i el Streaming computing model En aquest apartat es descriu el model de computaci que o abstrau amb certa delitat la programabilitat de les GPUs

actuals. Aquest rep el nom de streaming model o model de processat de uxos. Aquest model permet expressar el parallelisme dun algorisme (que ho permeti) des del punt de vista de les dades. Es a dir, sintenta expressar lalgorisme com una funci que saplica a un conjunt de dades de manera o igual e independent per a cada element. No tots els algorismes ho permeten. En aquest model, la funci que saplica rep el o nom de kernel o nucli. El conjunts delements als que la funci saplica reben el nom de streams o uxos de dades. o En GPGPU, tpicament, el nucli simplementa en un pro cessador de pxels i el ux de dades, dentrada, seran els frag ments que el rasteritzador generi. Aquest ux ser` processat a pel nucli i emmagatzemat en textures. Un altre model per expressar el parallelisme dalgorismes es basa en extreure la capacitat de parallelitzaci de les o tasques que el componen. Aquest es basa en descomposar lalgorisme en tasques independents una de laltre o que requereixen una sincronitzaci mnima. Aquest ultim model o sutilitza per CPUs. Hi ha algorismes que en natura s n seq encials i no sen o u pot extreure parallelisme (per exemple calcular nombres de Fibonnaci es una tasca s` rie). En canvi altres problemes e admeten diversos algorismes, alguns dels quals poden semblar molt poc parallelitzables per` de fet ser-ho. Un exemple o p.ex es el factorial dun nombre n! que es pot calcular multiplicant el factorial el nombre que el precedeix (n 1)! per el nombre n. Aquesta denici recursiva es trasllada a un o algorisme s` rie per` tamb es pot calcular multiplicant per e o e exemple els nombres de 1 a n/2 i per una altra banda els nombres de (n/2) + 1 a n (cosa que es pot fer en parallel) i multiplicar el resultat daquests dos per obtenir el factorial desitjat. Aquest exemple vol deixar clar que certs algorismes ecients per la execuci en s` rie poden no ser implementables o e per lexecuci en parallel. Tot i aix es pot intentar trobar un o nou algorisme que resolgui el mateix problema que el primer i que sigui en certa manera parallitzable (per exemple que permeti expressar-ho en el model de uxos). Aquest algorisme pot no ser tan ecient (en complexitat per exemple) per` o potser, que el guany degut a la parallelitzaci sigui superior o a la p` rdua deci` ncia daquest. Un exemple pr` ctic podria e e a ser un algorisme dordenaci ecient com pot ser el quicko sort amb una complexitat O(n log(n)). Aquest algorisme no es pot portar de manera ecient a la GPU degut a la manca de scatter que presenten aquestes. En canvi shan ` implementat amb exit algorismes basats en xarxes dordenaci o ` que tot i tenir complexitat no optima O(n log2 (n)) superen a ` implementacions optimes en CPUs. Es pot descarregar codi font daquestes implementacions a[Gpu05]. C. Benecis Les GPUs presenten els benecis seg ents per als qui volen u portar els seus algorismes: Gran pot` ncia de c` lcul en coma otant (precisi e a o simple). Per algorismes amb gran requeriment de pot` ncia e en coma otant com poden ser simulacions cientques, an` lisis de mercats nancers, etc. . . a

Acc s a mem` ria amb gran ample de banda. Aquest fet e o permet implementar algorismes amb grans requeriments de mem` ria com dordenaci de grans bases de dades per o o clau amb un alt rendiment. Les GPUs disposen de busos dinterconnexi amb la mem` ria damplada superior a o o les CPUs. A m s els xips de mem` ria funcionen a e o freq encies superiors (tot i que les lat` ncies s n supeu` e o riors) que les CPUs. Aix mentre en GPUs parlem de amples de banda de 64Gbytes/s en CPU parlem damples de banda de 12.8Gbytes/s. Gran capacitat de mem` ria. Actualment hi ha proceso sadors gr` cs amb 1Gbyte de mem` ria. a o Cost redut. Consum de pot` ncia el` ctrica moderat. e e Programabilitat. La taula II compara punts clau de les implementacions m s e ecients de diferents tipus de processadors. El primer beneci pot semblar ill` gic, es a dir, que la o pot` ncia de c` lcul de les GPUs sigui molt superior a les de e a les CPUs ja que els processadors disposen dels mateixos processos de fabricaci /integraci que les GPUs (de fet sobserva o o empricament que les GPUs van una generaci per darrera en o processos dintegraci ). La ra principal es que la majoria del o o transistors duna CPU es troben destinats a tasques que no aporten pot` ncia de c` lcul per` que ajuden a la execuci de e a o o manera m s ecient de codi s` rie (com poden ser les mem` ries e e o cau L1,L2 o les unitats de predicci de branques) . Es a dir en o una GPU el 70% dels transistors implementen unitats de coma otant. En canvi en una CPU poden arrivar a ocupar nom s el e 5%. Quasi b tota la p` tencia programable de les GPUs actuals e o es troba en els processadors de pxels. Per fer-nos una idea, un processador gr` c de segona genereaci dalt rendiment cont a o e 8 processadors de v` rtexs i ns a 48 processadors de pxels. e Aquest fet juntament amb el fet que el processador de pxels escriu directament a memoria i t un acc` s r` pid a mem` ria e e a o (texture samplers) ha donat lloc a no utilitzar els recursos dels processadors de v` rtexs. e Sha de saber, que a m s els procesadors gr` cs disposen e a de gran pot` ncia de c` lcul no programable, ja que hi ha etapes e a de funcionalitat xada, com s n la interpolaci datributs o o en letapa de rasteritzaci o b la ltraci de textures que o e o requereixen relativament de gran capacitat de c` lcul. De fet, un a fabricant (NVIDIA) ha notat que la pot` ncia no programable e en coma otant de la seva GPU es superior a la programable. Sha dentendre que la fracci de pot` ncia no programable o e anir` disminuint amb el temps degut a la ampliaci detapes a o programables aix com a lintent d s de pot` ncia disponible u e en etapes no programables, en etapes programables. Els r` tios de pot` ncia de c` lcul per unitat monet` ria i de a e a a pot` ncia de c` lcul per unitat de consum el` ctric s n molt e a e o m s elevats que els daltres processadors. La ra pel primer e o r` tio es degut als factors deconomia descales. Degut a que a les GPUs van dirigides pel gran consum per part del mercat dels videojocs i que es fabriquen en processos de integraci o punters, permeten oferir molta pot` ncia a preus baixos. La e ra pel segon r` tio es que tota la pot` ncia la consumeixen les o a e

unitats otants mentre en un processador es reparteix entre molts altres elements que no aporten pot` ncia otant. e La precisi en coma otant ha anat evolucionant. Els o primers processador gr` cs feien us de precisions no a est` ndards propiet` ries de cada fabricant. Per exemple ATI a a utilitzava un format otant de 24 bits, i Nvidia oferia un format de 16 bits anomenat half compatible amb un format de coma otant per emmagatzemar el color utilitzat per la Industrial Light&Magic, anomenat OpenEXR. Amb el temps aquests fabricants han evolucionat cap a la precisi est` ndard o a simple, de 32 bits. La ra , per no implementar aquesta o precisi des dun principi, es que el nombre de transistors o necessaris per implementar una unitat de coma otant amb una precisi donada creix quadr` ticament amb aquesta. Aix o a xat un nombre de transistors (xen el preu de fabricaci per o la seva viabilitat comercial) el nombre de unitats de coma otant que un fabricant pot integrar decreixen amb la inversa del quadrat de la precisi . A m s donat que el nombre dunitats o e de coma otant determina el rendiment del processador gr` c a en els videojocs els fabricants van optar per oferir precisions ` disminudes en que epoca. D. Limitacions Actualment les limitacions s n les seg ents: o u

Precisi simple. Per a certs problemes que requereixen o moltes operacions (els errors darrodoniment es van acumulant) o b per la de simulaci de problemes fsics on e o es troben representats elements que difereixen en diversos ordres de magnitud (per exemple simulacions del bigbang que necessiten de simulacions desde el nivell at` mic o ns al de gal` xies), la precisi simple no es sucient. En a o aquestos casos no shan portat aquests codis a la GPU tot i que lalgorisme pot ser traslladat a la GPU de manera efectiva. El primer daquest casos encara es pot portar degut a que shan portat m` todes dextensi de precisi e o o existents en la CPU (oat-oat,quad-oat) que mantenen els bits dexponent (ordres de magnitud representables) per` augmenten la mantissa (precisi ). En el segon cas o o es necessita una implementaci nativa de doble precisi . o o Manca del tipus de dada enter, amb les instruccions b` siques sobre aquest, incloent operacions bin` ries. a a Aquest permetria implementar en principi algorismes amb grans requeriments de pot` ncia de c` lcul amb enters e a com poden ser algorismes criptogr` cs, llibreries de noma bres grans(bignum), factoritzadors de nombres enters, tests de primalitat, algorismes de compressi , etc. . . o Baix rendiment condicional. La segona generaci , ha ino trodut suport limitat de codi condicional en processadors de pixels, per` aquest no es ecient sino hi ha una gran o coher` ncia en les decisions condicionals, es a dir, si no e es pren la mateixa branca per igual en una gran zona de pixels. Streaming Model. Veure III-B. Els elements del ux es processen de manera independent sense la possibilitat dinteracci o intercanvi de dades entre aquests. o

Falta de operacions de scatter. El terme scatter fa refer` ncia a lhabilitat descriure en posicions arbitr` ries e a de mem` ria. L nica manera descriure a mem` ria es o u o via els programadors de pixels que escriuen les dades generades en una posici que ve xada per la posici o o del pxel. Alguns problemes poden reformular-se com problemes gather. El terme gather fa refer` ncia a e la capacitat de lectura des de posicions arbitr` ries de a mem` ria. o Acc` s a mem` ria complex. Lacc s a mem` ria ve e o e o regit pels samplers(mostrejadors) de textura i aquests nom s admeten un adrecament amb coordenades otants. e Ultimament trunquen una transformaci de les coordeo nades otants a nombres enters per adrecar a mem` ria, o fet que pot provocar problemes per errors darrodoniment. Manca de debuggers i prolers.Veure III-E. Baix rendiment en les transfer` ncies CPU GPU. e Aix` implica que algorismes que nom s es puguin poro e tar parcialment als processadors gr` cs i que hagin de a intercanviar un volum de dades moderat o superior amb el processador central no veuran augmentat el rendiment respecte a una implementaci en un processador central o degut a que les possibles millores de rendiment per part del processador gr` c es veuran atenuades per el coll a dampolla que suposa la transfer` ncia de dades entre la e GPU i la CPU. Limitacions en lacc s a la mem` ria. El programador e o daplicacions en GPU normalment no t control sobre e la gesti de mem` ria i en particular no existeixen als o o llenguatges de programaci de GPUs el tipus de dades o punter. L nica manera dinteraccionar amb la mem` ria u o es mitjancant les textures (operaci de sol lectura i amb o acc s aleatori) i que permeten efectuar operacions de e gather. La primera revisi de processadors de segona o generaci nom s permetia lacc s a mem` ria des dels o e e o processadors de pxels. Una segona revisi permetia o lacc s des dels processadors de v` rtexs si b amb certes e e e restriccions i rendiment limitat. Les operacions descriptura s n possibles nom s des del processador de pxels. A o e m s la direcci descriptura ve xada pr` viament. Per tant e o e no es factible realitzar operacions de scatter (escriptura aleat` ria). Hi ha t` cniques per obtenir lefecte de scatter o e tot i que aquestes no s n ecients ja que utilitzen el o processador de v` rtexs per pertorbar els pxels de sortida. e Intensitat aritm` tica. Tot i que les GPU proporcionen e gran capacitat de c` lcul i un acc s de gran ample de a e banda a la mem` ria el r` tio daquestes dos quantitats o a augmenta de manera continua. Aix` implica que per utilo itzar aquestes dues capacitats de la GPU al m` xim shan a de dissenyar algorismes que facin moltes operacions matem` tiques comparades amb accessos a mem` ria. El a o r` tio daquests dos factors rep el nom de intensitat a aritm` tica. e Capacitat limitada descriptura dun programa de pixels: 16 valors de precisi simple per pxel. o

E. Sistemes de programaci de GPUs o Per facilitar el desenvolupament en una plataforma, id` niament es necessiten tres eines: o

Llenguatge 3D API HLSL2bin 1 pas Multiples OS Fabricant

Cg OpenGL/DirectX No Si Nvidia

HLSL DirectX No No(Windows) Microsoft

OGLSL OpenGL Si Si M ltiples u

Un Llenguatge dalt nivell. Un depurador. Un proler.

TABLE I C OMPARATIVA DE HLSL S

Actualment per a la programaci de GPUs nom s es diso e posa de llenguatges dalt nivell adequats. La depuraci dels o programes es molt arcaica. La depuraci interactiva sol ser o gr` ca. Aquesta es realitza dibuixant les variables a la a pantalla on es transformen valors en colors. Aquest m` tode e es util per solucionar errors greus: conceptes mal entesos, mala xaci de lestat de la API 3D, etc. . . . Per errors m s o e subtils es dibuixen les variables en pantalles virtuals o rendertargets i es transfereix a la mem` ria de la CPU on pot o ser analitzada amb detall amb programes sobre la CPU. Els prolers els proporcionen els fabricants dels processadors gr` cs i proporcionen informaci util que ens permet saber a o quins factors s n el limitadors de rendiment. La informaci o o proporcionada pot ser per exemple: limitacions de rendiment per insucient ample de banda amb la mem` ria degut a l s o u exhaustiu de la lectura de textures, c` rrega molt elevada dun a tipus de processador que fa que laltre no es pugui aprotar al m` xim, etc.. a El llenguatge dalt nivell abstrau al programador del llenguatge m` quina del processador, i li proporciona abstraccions a l` giques, de ux, etc... destinades a simplicar el desenvoluo pament del programari. Els llenguatges dalt nivell per programar les GPUs reben el nom de llenguatges de ombrejat dalt nivell (HLSL). Per programar en GPU es disposa de tres llenguatges: Cg, HLSL i OpenGL Shading language. Aquests llenguatges s n lleno guatges de programaci molt semblants al C, per` aquests o o introdueixen abstraccions especques gr` ques com v` rtexs, a e textures, etc. . . A m s introdueixen instruccions especiques e del camp dels gr` cs com instruccions de refracci , reexi , a o o illuminaci ,etc. . . Lespecialitzaci daquest llenguatges els o o permet exposar de manera molt propera larquitectura el processador gr` c. Cg i HLSL s n essencialment iguals, per` a o o el primer ha anat evolucionant incorporant abstraccions de llenguatges orientats a objectes com poden ser interfaces, etc. . . El beneci principal daquests llenguatges es que permeten obtenir un rendiment superior a llenguatges especialitzats per GPGPU. El principal problema que presenten es que aquests llenguatges implementen processos de v` rtexs i pxels que e es troben immersos dins de la pipeline gr` ca duna API a 3D i per tant depenen de lestat daquesta (per exemple el rasteritzador pot estar congurat per treballar en mode l o en mode omple). A m s un sha preocupar denllacar les e textures que els programes utilitzen amb les desitjades, etc.. Resumint sha de dominar la programaci gr` ca amb APIs o a 3D i tamb els llenguatges dalt nivell per` aix` ens permet e o o obtenir el m` xim rendiment. a

La taula I mostra les caracterstiques principals dels llen guatges dalt nivell, com les API 3D amb les que pot interaccionar, suport de m ltiples sistemes operatius i el fabricant u del llenguatge. Una caracterstica general del desenvolupament en GPUs es que el codi binari dels programes es crea en temps dexecuci . o Aquesta caracterstica permet la compatibilitat amb nous pro cessadors gr` cs assegurant a la vegada que el codi sexecutar` a a amb el m` xim rendiment possible en cada generaci . Per a a o tal prop` sit els llenguatges dalt nivell proporcionen funcions o per generar un codi intermedi. Aquest es transformat a codi binari pels controladors del processador gr` c, que coneixent a el conjunt dinstruccions natives, aix com els throughput i lat` ncies daquestes, els permet optimitzar el codi pel procese sador on sexecuta. El OpenGL Shading Language n s una e excepci ja que la transformaci dalt nivell a nivell binari no o o es realitza en dos passos sent possible aix lobtenci de codi o binari m s ecient ( a la taula I veure la HLSL2bin 1 pas). e Per facilitar la programaci als investigadors daltres camps o no habituats als conceptes de programaci dAPIs shan o dissenyat abstraccions superiors sobre els llenguatges dalt nivell que permeten locultaci dels conceptes gr` cs i auo a tomatitzen la xaci de lestat de les APIs 3D i la creaci o o dels programes ombrejadors necessaris i la seva execuci , etc.. o Aquests exposen el model de processat per uxos i reben el nom de llenguatges GPGPU. Llenguatges daquest tipus s n Brook [Buc04] i Sh. o Un desavantatge dels llenguatges GPGPU, per exemple de Brook, es que la visualitzaci dels resultats duna computaci o o es complexa degut a que ell regula la API 3D. Per aquests casos (simulacions en GPU on volem visualitzar les dades daquesta com p.ex. les simulacions fsiques com uids) es recomanable l s de llenguatges dalt nivell. u Actualment shan creat empreses (RapidMind i PeakStream) que ofereixen llibreries que estenen el llenguatge C++ amb tipus de dades i construccions destinades a exposar el model de uxos de dades. A m s ofereixen depuradors i prolers e m s adequats per a la programaci GPGPU. Un avantatge e o que ofereixen aquests entorns de programaci per GPUs es o que suporten altres arquitectures optimitzades pel proc s de e uxos, larquitectura Cell n s un exemple, i generen codi e binari per a aquestes. A m s aquestes ofereixen llibreries e amb funcionalitats d s est` ndard en lentorn cientc, que u a proporcionen els blocs b` sics a partir dels quals depenen a altres algorismes cientcs. Exemples poden ser llibreries que ofereixen rutines BLAS,FFT,etc.. Per ultim, cal dir que alguns daquests llenguatges (p.ex. PeakStream) garanteixen una pre-

cisi mnima en el c` lcul de certes operacions matem` tiques o a a (logaritmes p. ex.) que els fabricants de GPU no garanteixen. Disposar daquestes cotes de precisi inferior permet lobo tenci de cotes de la precisi mnima del resultat desitjat, o o requisit necessari en entorns cientcs. Aquests entorns a m s e generen codi tan ecient com codi programat en llenguatges dalt nivell [Rap06] i a m s poden generar codi per diverses e arquitectures paral.leles com poden ser el processador Cell, processadors multinucli i processadors gr` cs. a Recentment fabricants de processadors gr` cs han alliberat a llenguatges que no es troben lligats de cap manera a pipelines gr` ques exposant tota la programabilitat del processador a gr` c i del seu controlador de mem` ria. Resultats oferts pels a o fabricants mostren que guanys de factor 2 en rendiment sobre codi en llenguatges dalt nivell s n habituals en un ampli o ventall dalgorismes mentre que alguns experimenten guanys de ns a 10 vegades de rendiment. Veure [Seg06]. IV. I MPLEMENTACIONS D ALGORISMES EN GPU Shan portat algorismes b` sics d` lgebra lineal (per a maa a trius denses i disperses), algorismes de cerca, dordenaci , o visi per ordinador, de processat del senyal: imatge, vdeo i so o (FFTs),simulacions fsiques basades en equacions diferencials (uids, robes, s` lids rgids, etc..),algorismes de bases de dades, o m` todes dilluminaci global (tracat de raigs,m` todes de e o e radiositat i photon mapping), i geometria computacional entre daltres. Es recomana [Owe05] per ampliar informaci . o Els autors han implementat un simulador dones daigua amb visualitzaci avancada en temps real. Aix` es gr` cies o o a a que la simulaci fsica (la resoluci de les equacions o o diferencials que modelen el moviment de les ones) es troba implementada en GPU. Lalgorisme de simulaci sha impleo mentat en la CPU i proves experimentals han mostrat que la velocitat de simulaci era 5 vegades menor. M s informaci o e o a [RTFSS06]. Vegeu la gura 3.

La gura 4 mostra un comparaci del rendiment de tres o ` algorismes diferents, algebra lineal (SGEMM), processat del senyal (FFT) i mercats nancers (Black-Scholes), executantse en CPU i GPU. SGEMM implementa la multiplicaci de o matrius, FFT fa refer` ncia a la transformada de Fourier r` pida, e a i Black-Scholes fa refer` ncia a un model devoluci del valor e o de les accions molt utilitzat a l` mbit dels mercats nancers. a La columna de la dreta de cada algorisme descriu el rendiment daquest en GPU respecte a una implementaci en CPU. El o llenguatge GPGPU usat es el que proporcionen les llibreries de RapidMind. Es poden consultar els detalls de la comparaci o a [Rap06].

Fig. 4. GPUs.

Comparativa del rendiment de diferents algorismes entre CPUs i

V. C ONCLUSIONS I

PREVISIONS DE FUTUR

Fig. 3.

RTFSS: Simulaci i visualitzaci daigua en GPU. o o

La tercera generaci acaba just de comencar, amb lanunci o el dia 8 de Novembre de 2006 per part de Nvidia, de la sortida al mercat duna nova generaci de processos gr` cs. Aquests o a processadors es basen en un arquitectura totalment nova que proporciona nous nivells de rendiment i programabilitat. Sesperen processadors gr` cs de tercera generaci duna a o altra companyia(AMD/ATI) per principis del 2007. Sha de dir que degut a la forta compet` ncia a que shan vist sotmesos e els diferents fabricants de processadors gr` cs aquests han a anat abandonant el negoci. A m s el disseny dun processador e gr` c suposa una inversi molt important (de lordre de a o centenars de milions de d` lars) . Aix nom s sesperen que o e els fabricants mencionats siguin els unics capacos doferir processadors de tercera generaci amb un rendiment adequat o en futur proper (1 o 2 anys). Les millores que aporta s n les seg ents: o u Nova etapa programable: Processador de geometria (que opera sobre primitives) amb la possibilitat dinserir o destruir elements al/del pipeline. . Model de programaci unicat per les diverses etapes o programables(mateixes instruccions i funcionalitat). Operacions amb nombres enters. Textures denters, operadors binaris i enters a totes les etapes programables.

Possibilitat dutilitzaci de textures com arrays (sense o ltrar-les) adrecant-les amb coordenades enteres. Augment del rendiment del codi condicional: necessita coher` ncies de nom s 32 pixels.. e e Permet un major control sobre la disposici de la o mem` ria. o El processadors de tercera generaci incorporen una unio caci funcional (a nivell de programaci ) dels processadors o o fet que ha motivat que els fabricants de processadors gr` cs a hagin creat un processador que pugui executar tots els tipus de programes: pxels, v` rtexs o geometria (unicaci a nivell e o hardware). Encara m s, generalment incorporen un gestor que e controla lassignaci de manera ecient dels processadors o (de manera que en qualsevol moment hi hagi una utilitzaci o m` xima daquests) i per tant el fet de no utilitzar la proa gramabilitat de v` rtexs no ens far` perdre pot` ncia de c` lcul e a e a programable. A m s proporciona funcionalitat m s avancada de la que e e permet lapipeline gr` ca programable (ja que els llenguata ges dalt nivell implementen les etapes programables de la pipeline) com per exemple scatter o escriptura en posicions arbitraries no prexades. Tamb permet funcionalitat m s e e avancada de la que permet el model de computaci sobre o uxos ja que permet certa interacci e intercanvi de dades o entre els processadors d elements(pxels,v` rtexs o geometria). e Cal dir que aquesta funcionalitat sha afegit pensant en els usuaris que volen utilitzar la GPU com un processador general. Per poder accedir a aquestes funcionalitats avancades Nvidia ha creat un llenguatge nou CUDA que permet utilitzar tota la funcionalitat nova (CUDA per ex. permet lus de punters, scatter, etc..). ATI per la seva part tamb ha anunciat un e llenguatge de baix nivell (ATI CTM) [Seg06] que tamb e permet accedir a habilitats del processador que no exposen els lleng es dalt nivell existents. u Sespera per mitjans de 2007 disposar de processadors gr` cs amb 1GBytes de mem` ria i acc s a mem` ria al voltant a o e o de 140Gbytes/s i un Teraop/s de pot` ncia programable. e A m s sespera que al 2008 els processador gr` cs, que e a ns ara operaven amb otants de precisi simple(single o precision), puguin realitzar les operacions amb doble precisi o (64bits). En un futur m s llunya sespera que les GPUs i les CPUs e convergiran oferint prestacions similars. Aix` es degut a que o darrerament els processadors degut a problemes de consum i dissipaci de pot` ncia han tingut que canviar del paradigma de o e augmentar la velocitat de c` lcul daquests via increments en a la freq encia de rellotge a incrementar la pot` ncia del procesu` e sadors via la inclusi de diversos nuclis de processament. Per o altre banda les GPUs com hem comentat cada vegada podem veure-les m s com un conjunt de processadors oferint aquests e cada vegada prestacions similars a les duna CPU. Eventualment tamb es pret n integrar a nivell de silici una e e GPU en una CPU que seria un coprocessador. Aix` es similar o a quan a nals dels 80 es va integrar una unitat otant en les CPUs que ns llavors era un element extern. Es denominava llavors coprocessador matem` tic o FPU(oating point unit). a

Com podem veure les principals limitacions que shan descrit que presentaven la generaci actual seran resoltes en o la tercera generaci de processadors gr` cs. o a La distinci que sha fet entre generacions pot ser diferent o de la daltres autors per` sha cregut que amb certa cura aproxo ima els grans canvis que han aportat els diferents processadors gr` cs en cada generaci . a o R EFERENCES
[Buc04] Buck I., Foley T., Horn D., et altres. Brook for GPUs: Stream computing on graphcis hardware in ACM Transactions on Graphics 23,3, August 2004, pp. 777-786. [Gpu05] GPUSort: A high performance GPU sorting library. http://gamma.cs.unc.edu/GPUSORT, 2005. [Owe05] John D. Owens, et altres. A Survey of General-Purpose Computation on Graphics Hardware in Eurographics 2005, State of the Art Reports, August 2005, pp. 21-51. [Rap06] McCool M. et altres. Performance evaluation of GPUs using the RapidMind Development Platform http://www.rapidmind.com, October 2006. [RTFSS06] RTFSS: a Real Time Free Surface Fluid Solver http://rtfss.sourceforge.net, 2006. [Seg06] Segal M., Peercy M., A Performance-Oriented Data Parallel Virtual Machine for GPUs http://www.ati.com/developer, August 2006.

Tipus de procesador Pot` ncia pic (te` rica) precisi simple (GFLOPS/s) e o o Pot` ncia pic (observada) precisi simple (GFLOPS/s) e o Pot` ncia pic (te` rica) precisi doble (GFLOPS/s) e o o Pot` ncia pic (observada) precisi doble (GFLOPS/s) e o Quantitat de mem` ria integrada (Mbytes) o Ample de banda de pic (GB/s) No de processadors Tipus processador FLOPS/CLK per cada processador e Frequ` ncia de rellotge (Ghz) No de transistors (milions) Tecnologia dintegraci (nm) o Preu ($) Data de sortida

Intel QX6700 CPU 85 70 42 35 X 9 4 SIMD 4-vectorial 8 (ADD4+MUL4) 2,66 582 65 1000 Novembre 2006

NVIDIA 8800 GPU 520 340 X X 768 85 128 escalar 3 (MADD1+MUL1) 1,35 681 90 600 Novembre 2006

ATI X1950XT GPU 360 240 X X 256 60 48 SIMD 4-vectorial 12 (MADD4+ADD4) 0,625 384 90 250 Setembre 2006

RSX(PS3) GPU 210 200 X X 256 23 48 SIMD 4-vectorial 8(MADD4) 0,55 278 90 250 Marc 2006

Cell BE CPU 200 160 14 11 256 25 8 SIMD 4-vectorial 8 (MADD4) 3,2 234 90 600 (consola PS3) 2006

TABLE II C OMPARATIVA DE DIFERENTS ARQUITECTURES PARALLELES