mulatio on Usingg GLLSL, Ope

Transcription

1 22 2 GP PGPU Clloh Sim mulaio on Usingg GLLSL, Ope encl, and CUD DA Marrco Fraarcaangeli Taiu us Sofware Ialia I 22.1 Inroducion n Thiss chaper prov vides a comp parison sudyy beween hrree popular pplaforms for geneeric programm ming on he GPU, G namelyy, GLSL, CU UDA, and OpeenCL. These echn nologies are used for imp plemening ann ineracive physically-baased mehod ha simulaes a piece p of cloh h colliding wiih simple priimiives like sspheres, cylinders, and planess (see Figure 22.1). We asssess he advannages and hhe drawbacks in n erms of usaabiliy and perrformance. of eaach differen echnology Figu ure A pieece of cloh fallls under he innfluence of graaviy while coolliding wih a spherre a ineraciv ve raes. The cloh is compossed of 780,0000 springs connnecing 65,000 pariccles. 365

2 GPGPU Cloh Simulaion Using GLSL, OpenCL, and CUDA (i, j + 1) (i, j) (i + 1, j 1) (i 2, j 2) Figure A 4 4 grid of paricle verices and he springs for one of he paricles Numerical Algorihm This secion provides a brief overview of he heory behind he algorihm used in compuing he cloh simulaion. A sraighforward way o implemen elasic neworks of paricles is by using a mass-spring sysem. Given a se of evenly spaced paricles on a grid, each paricle is conneced o is neighbors hrough simulaed springs, as depiced in Figure Each spring applies o he conneced paricles a force F spring: Fspring k l l 0 bx, where l represens he curren lengh of he spring (i.e., is magniude is he disance beween he conneced paricles), l 0 represens he res lengh of he spring a he beginning of he simulaion, k is he siffness consan, x is he velociy of he paricle, and b is he damping consan. This equaion means ha a spring always applies a force ha brings he disance beween he conneced paricles back o is iniial res lengh. The more he curren disance diverges from he res lengh, hen he larger is he applied force. This force is damped proporionally o he curren velociy of he paricles by he las erm in he equaion. The blue springs in Figure 22.2 simulae he srech sress of he cloh, while he longer red ones simulae he shear and bend sresses. For each paricle, he numerical algorihm ha compues is dynamics is schemaically illusraed in Figure For each sep of he dynamic simulaion,

3 22.2 Numerical Algorihm 367 Iniial sae x, x 0 0 Compue acceleraion x F m Compue forces F(): springs and graviy Compue new sae x Δ, x Δ Updae sae x, x x Δ, x Δ Handle collisions Figure Numerical algorihm for compuing he cloh simulaion. he spring forces and oher exernal forces (e.g., graviy) are applied o he paricles, and hen heir dynamics are compued according o he Verle mehod [Müller 2008] applied o each paricle in he sysem hrough he following seps: 1. x x x Δ Δ. 2. x F x, x m x Δ 2x x Δ x Δ. Here, F is he curren oal force applied o he paricle, m is he paricle mass, x is is acceleraion, x is he velociy, x is he curren posiion, and Δ is he ime sep of he simulaion (i.e., how much ime he simulaion is advanced for each ieraion of he algorihm). The Verle mehod is very popular in real-ime applicaions because i is simple and fourh-order accurae, meaning ha he error for he posiion compuaion is O Δ. This makes he Verle mehod wo orders of magniude more 4 precise han he explici Euler mehod, and a he same ime, i avoids he compu-

4 GPGPU Cloh Simulaion Using GLSL, OpenCL, and CUDA aional cos involved in he Runge-Kua fourh-order mehod. In he Verle scheme, however, velociy is only firs-order accurae; in his case, his is no really imporan because velociy is considered only for damping he springs Collision Handling Generally, collision handling is composed of wo phases, collision deecion and collision response. The oucome of collision deecion is he se of paricles ha are currenly colliding wih some oher primiive. Collision response defines how hese collisions are solved o bring he colliding paricles o a legal sae (i.e., no inside a collision primiive). One of he key advanages of he Verle inegraion scheme is he easiness of handling collision response. The posiion a he nex ime sep depends only on he curren posiion and he posiion a he previous sep. The velociy is hen esimaed by subracing one from he oher. Thus, o solve a collision, i is sufficien o modify he curren posiion of he colliding paricle o bring i ino a legal sae, for example, by moving i perpendicularly ou oward he collision surface. The change o he velociy is hen handled auomaically by considering his new posiion. This approach is fas and sable, even hough i remains valid only when he paricles do no penerae oo far. In our cloh simulaion, as he sae of he paricle is being updaed, if he collision es is posiive, he paricle is displaced ino a valid sae. For example, le s consider a saionary sphere placed ino he scene. In his simple case, a collision beween he sphere and a paricle happens when he following condiion is saisfied: x Δ c r 0, where c and r are he cener and he radius of he sphere, respecively. If a collision occurs, hen i is handled by moving he paricle ino a valid sae by moving is posiion jus above he surface of he sphere. In paricular, he paricle should be displaced along he normal of he surface a he impac poin. The posiion of he paricle is updaed according o he formula x Δ c d x Δ c, x Δ c d r, where x Δ is he updaed posiion afer he collision. If he paricle does no penerae oo far, d can be considered as an accepable approximaion of he normal o he surface a he impac poin.

5 22.4 CPU Implemenaion CPU Implemenaion We firs describe he implemenaion of he algorihm for he CPU as a reference for he implemenaions on he GPU described in he following secions. During he design of an algorihm for he GPU, i is criical o minimize he amoun of daa ha ravels on he main memory bus. The ime spen on he bus is acually one of he primary bolenecks ha srongly penalize performance [Nvidia 2010]. The ransfer bandwidh of a sandard PCI-express bus is 2 o 8 GB per second. The inernal bus bandwidh of a modern GPU is approximaely 100 o 150 GB per second. I is very imporan, herefore, o minimize he amoun of daa ha ravels on he bus and keep he daa on he GPU as much as possible. In he case of cloh simulaion, only he curren and he previous posiions of he paricles are needed on he GPU. The algorihm compues direcly on GPU he res disance of he springs and which paricles are conneced by he springs. The sae of each paricle is represened by he following aribues: 1. The curren posiion (four floaing-poin values). 2. The previous posiion (four floaing-poin values). 3. The curren normal vecor (four floaing-poin values). Even hough he normal vecor is compued during he simulaion, i is used only for rendering purposes and does no affec he simulaion dynamics. Here, he normal vecor of a paricle is defined o be he average of he normal vecors of he riangulaed faces o which he paricle belongs. A differen array is creaed for soring he curren posiions, previous posiions, and normal vecors. As explained in laer secions of his chaper, for he GPU implemenaion, hese aribues are loaded as exures or buffers ino video memory. Each array sores he aribues for all he paricles. The size of each array is equal o he size of an aribue (four floaing-poin values) muliplied by he number of paricles. For example, he posiion of he i-h paricle p i is sored in he posiions array and accessed as follows: pos i vec3(in_pos[i * 4], in_pos[i * 4 + 1], in_pos[i * 4 + 2], in_pos[i * 4 + 3]) The cloh is buil as a grid of n n paricles, where n is he number of paricles composing one side of he grid. Regardless of he value of n, he horizonal and he verical spaial dimensions of he grid are always normalized o he range

6 GPGPU Cloh Simulaion Using GLSL, OpenCL, and CUDA 0,1. A paricle is idenified by is array index i, which is relaed o he row and he column in he grid as follows: rowi i n, col i mod n. i From he row and he column of a paricle, i is easy o access is neighbors by simply adding an offse o he row and he column, as shown in he examples in Figure The pseudocode for calculaing he dynamics of he paricles in an n n grid is shown in Lising In seps 1 and 2, he curren and previous posiions of 1 he he i-h paricle are loaded in he local variables pos i and pos i, respecively, and hen he curren velociy vel i is esimaed in sep 3. In sep 4, he oal force force i is iniialized wih he graviy value. Then, he for loop in sep 5 ieraes over all he neighbors of p i (seps 5.1 and 5.2), spring forces are compued (seps 5.3 o 5.5), and hey are accumulaed ino he oal force (sep 5.6). Each neighbor is idenified and accessed using a 2D offse x offse, y offse from he posiion of p i wihin he grid, as shown in Figure Finally, he dynamics are compued in sep 6, and he resuls are wrien ino he oupu buffers in seps 7 and 8. for each paricle p i 1. pos i x i 1 2. pos i x i Δ 1 3. vel i pos i pos i Δ 4. force i = (0, -9.81, 0, 0) 5. for each neighbor rowi xoffse, coli y offse if rowi xoffse, coli y offse is inside he grid 5.1. i neigh rowi yoffse * n coli xoffse 5.2. pos neigh x neigh 5.3. d res xoffse, yoffse n 5.4. d curr pos neigh pos i pos neigh pos i 5.5. force spring = dcurr dres k vel i b pos neigh pos i 5.6. force i += force spring pos i = 2 pos i pos i + force i m Δ 1 7. xi pos i x Δ pos 8. i i Lising Pseudocode o compue he dynamics of a single paricle i belonging o he n n grid.

7 22.5 GPU Implemenaions GPU Implemenaions The differen implemenaions for each GPGPU compuing plaform (GLSL, OpenCL, and CUDA) are based on he same principles. We employ he so-called ping-pong echnique ha is paricularly useful when he inpu of a simulaion sep is he oucome of he previous one, which is he case in mos physicallybased animaions. The basic idea is raher simple. In he iniializaion phase, wo buffers are loaded on he GPU, one buffer o sore he inpu of he compuaion and he oher o sore he oupu. When he compuaion ends and he oupu buffer is filled wih he resuls, he poiners o he wo buffers are swapped such ha in he following sep, he previous oupu is considered as he curren inpu. The resuls daa is also sored in a verex buffer objec (VBO), which is hen used o draw he curren sae of he cloh. In his way, he daa never leaves he GPU, achieving maximal performance. This mechanism is illusraed in Figure Odd simulaion seps (ping...) Inpu Oupu Buffer 0 x GPU compuaion Buffer 1 x Δ GPU Verex Buffer Objec Draw 2. Even simulaion seps (...pong) Oupu Buffer 0 x Δ GPU compuaion Inpu Buffer 1 x Draw Verex Buffer Objec GPU Figure The ping-pong echnique on he GPU. The oupu of a simulaion sep becomes he inpu of he following sep. The curren oupu buffer is mapped o a VBO for fas visualizaion.

8 GPGPU Cloh Simulaion Using GLSL, OpenCL, and CUDA 22.6 GLSL Implemenaion This secion describes he implemenaion of he algorihm in GLSL 1.2. The source code for he verex and fragmen shaders is provided in he files verle_cloh.vs and verle_cloh.fs, respecively, on he websie. The posiion and velociy arrays are each sored in a differen exure having n n dimensions. In such exures, each paricle corresponds o a single exel. The exures are uploaded o he GPU, and hen he compuaion is carried ou in he fragmen shader, where each paricle is handled in a separae hread. The updaed sae (i.e., posiions, previous posiions, and normal vecors) is wrien o hree disinc render arges. Frame buffer objecs (FBOs) are employed for efficienly soring and accessing he inpu exures and he oupu render arges. The ping-pong echnique is applied hrough he use of wo frame buffer objecs, FBO1 and FBO2. Each FBO conains hree exures soring he sae of he paricles. These hree exures are aached o heir corresponding FBOs as color buffers using he following code, where fb is he index of he FBO and exid[0], exid[1], and exid[2] are he indices of he exures soring he curren posiions, he previous posiions, and he normal vecors of he paricles, respecively: glbindframebufferext(gl_framebuffer_ext, fbo->fb); glframebuffertexure2dext(gl_framebuffer_ext, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, exid[0], 0); glframebuffertexure2dext(gl_framebuffer_ext, GL_COLOR_ATTACHMENT1_EXT, GL_TEXTURE_2D, exid[1], 0); glframebuffertexure2dext(gl_framebuffer_ext, GL_COLOR_ATTACHMENT2_EXT, GL_TEXTURE_2D, exid[2], 0); In he iniializaion phase, boh of he FBOs holding he iniial sae of he paricles are uploaded o video memory. When he algorihm is run, one of he FBOs is used as inpu and he oher one as oupu. The fragmen shader reads he daa from he inpu FBO and wries he resuls in he render arges of he oupu FBO (sored in he color buffers). We declare he oupu render arges by using he following code, where fb_ou is he FBO ha sores he oupu: glbindframebufferext(gl_framebuffer_ext, fb_ou); GLenum mr[] = {GL_COLOR_ATTACHMENT0_EXT, GL_COLOR_ATTACHMENT1_EXT, GL_COLOR_ATTACHMENT2_EXT}; gldrawbuffers(3, mr);

9 22.7 CUDA Implemenaion 373 In he nex simulaion sep, he poiners o he inpu and oupu FBOs are swapped so ha he algorihm uses he oupu of he previous ieraion as he curren inpu. The wo FBOs are sored in he video memory, so here is no need o upload daa from he CPU o he GPU during he simulaion. This drasically reduces he amoun of daa bandwidh required on he PCI-express bus, improving he performance. A he end of each simulaion sep, however, posiion and normal daa is read ou o a pixel buffer objec ha is hen used as a VBO for drawing purposes. The posiion daa is sored ino he VBO direcly on he GPU using he following code: glreadbuffer(gl_color_attachment0_ext); glbindbuffer(gl_pixel_pack_buffer, vbo[position_object]); glreadpixels(0, 0, exure_size, exure_size, GL_RGBA, GL_FLOAT, 0); Firs, he color buffer of he FBO where he oupu posiions are sored is seleced. Then, he posiions VBO is seleced, specifying ha i will be used as a pixel buffer objec. Finally, he VBO is filled wih he updaed daa direcly on he GPU. Similar seps are aken o read he normals daa buffer CUDA Implemenaion The CUDA implemenaion works similarly o he GLSL implemenaion, and he source code is provided in he files verle_cloh.cu and verle_cloh_kernel.cu on he websie. Insead of using FBOs, his ime we use memory buffers. Two pairs of buffers in video memory are uploaded ino video memory, one pair for curren posiions and one pair for previous posiions. Each pair comprises an inpu buffer and an oupu buffer. The kernel reads he inpu buffers, performs he compuaion, and wries he resuls in he proper oupu buffers. The same daa is also sored in a pair of VBOs (one for he posiions and one for he normals), which are hen visualized. In he beginning of he nex ieraion, he oupu buffers are copied in he inpu buffers hrough he cudamemcpydevicetodevice call. For example, in he case of posiions, we use he following code: cudamemcpy(pposou, pposin, mem_size, cudamemcpydevicetodevice); I is imporan o noe ha his insrucion does no cause a buffer upload from he CPU o he GPU because he buffer is already sored in video memory. The

10 GPGPU Cloh Simulaion Using GLSL, OpenCL, and CUDA oupu daa is shared wih he VBOs by using graphicscudaresource objecs, as follows: // Iniializaion, done only once. cudagraphicsglregiserbuffer(&cuda_vbo_resource, gl_vbo, cudagraphicsmapflagswriediscard); // During he algorihm execuion. cudagraphicsmapresources(1, cuda_vbo_resource, 0); cudagraphicsresourcegemappedpoiner((void **) &pos, &num_byes, cuda_vbo_resource); execuecudakernel(pos,...); cudagraphicsunmapresources(1, cuda_vbo_resource, 0); In he iniializaion phase, we declare ha we are sharing daa in video memory wih OpenGL VBOs hrough CUDA graphical resources. Then, during he execuion of he algorihm kernel, we map he graphical resources o buffer poiners. The kernel compues he resuls and wries hem in he buffer. A his poin, he graphical resources are unmapped, allowing he VBOs o be used for drawing OpenCL Implemenaion The OpenCL implemenaion is very similar o he GLSL and CUDA implemenaions, excep ha he daa is uploaded a he beginning of each ieraion of he algorihm. A he ime of his wriing, OpenCL has a raher young implemenaion ha someimes leads o poor debugging capabiliies and sporadic insabiliies. For example, suppose a kernel in OpenCL is declared as follows: kernel void hello( global in *g_idaa); Now suppose we pass inpu daa of some differen ype (e.g., a floa) in he following way: floa inpu = 3.0F; cfloalsekernelarg(ckkernel, 0, sizeof(floa), (void *) &inpu); clenqueuendrangekernel(cqqueue, ckkernel, 1, NULL, &_szglobalworksize, &_szlocalworksize, 0, 0, 0); When execued, he program will fail silenly wihou giving any error message because i expecs an in insead of a floa. This made he OpenCL implemenaion raher complicaed o develop.

11 22.9 Resuls Resuls The described mehod has been implemened and esed on wo differen machines: A deskop PC wih an Nvidia GeForce GTS250, 1GB VRAM and a processor Inel Core i5. A lapop PC wih an Nvidia Quadro FX 360M, 128MB VRAM and a processor Inel Core2 Duo. We colleced performance imes for each GPU compuing plaform, varying he numbers of paricles and springs, from a grid resoluion of 32 32(1024 paricles and 11,412 springs) o (65,536 paricles and approximaely 700,000 springs). Numerical resuls are colleced in he plos in Figures 22.5 and From he daa ploed in Figures 22.5 and 22.6, he compuing superioriy of he GPU compared wih he CPU is eviden. This is mainly due o he fac ha his cloh simulaion algorihm is srongly parallelizable, like mos of he pariclebased approaches. While he compuaional cos on he CPU keeps growing linearly wih he number of paricles, he compuaion ime on he GPU remains relaively low because he paricle dynamics are compued in parallel. On he GTS250 device, his leads o a performance gain ranging from 10 o 40 imes, depending on he number of paricles. I is ineresing o noe ha in his case, GLSL has a much beer performance han CUDA does. This can be explained by considering how he memory is accessed by he GPU kernels. In he GLSL fragmen program, images are employed o sore paricle daa in exure memory, while in CUDA and OpenCL, hese daa is sored in he global memory of he device. Texure memory has wo main advanages [Nvidia 2010]. Firs, i is cached, and hus, video memory is accessed only if here is a cache miss. Second, i is buil in such a way as o opimize he access o 2D local daa, which is he case because each paricle corresponds o a pixel, and i mus have access o he posiions of is neighbors, which are sored in he immediaely adjacen exure pixels. Furhermore, he resuls in GLSL are sored in he color render arges ha are hen direcly mapped o VBOs and drawn on he screen. The daa resides in video memory and does no need o be copied beween differen memory areas. This makes he enire process exremely fas compared wih he oher approaches. The plos also highligh he lower performance of OpenCL compared wih CUDA. This difference is caused by he fac ha i has been raher difficul o une he number of global and local work iems due o causes requiring furher

12 GPGPU Cloh Simulaion Using GLSL, OpenCL, and CUDA Time (ms) CPU GLSL OCL CUDA CPU GLSL OCL CUDA CPU GLSL OCL CUDA CPU GLSL OCL CUDA 1024 paricles 4096 paricles 16,384 paricles 65,536 paricles 11,412 springs 47,380 springs 193,044 springs 779,284 springs Figure Compuaion imes measured on differen compuaion plaforms using a GeForce GTS 250 device (16 compuing unis, 128 CUDA cores) Time (ms) CPU GLSL OCL CUDA CPU GLSL OCL CUDA CPU GLSL OCL CUDA CPU GLSL OCL CUDA 1024 paricles 4096 paricles 16,384 paricles 65,536 paricles 11,412 springs 47,380 springs 193,044 springs 779,284 springs Figure Compuaion imes measured on differen compuaion plaforms using a Quadro FX 360M device (2 compuing unis, 16 CUDA cores).

13 22.10 Fuure Work 377 invesigaion. OpenCL is a very young sandard, and boh he specificaion and he driver implemenaion are likely o change in he near fuure in order o avoid such insabiliies. The GLSL program works on relaively old hardware, and differen from CUDA, i does no require Nvidia hardware. CUDA on he oher hand, is a more flexible archiecure ha has been specifically devised for performing compuing asks (no only graphics, like GLSL), which is easier o debug and provides access o hardware resources, like he shared memory, allowing for a furher boos o he performance. OpenCL has he same feaures as CUDA, bu is implemenaion is raher naive a he momen, and i is harder o debug. However, differen from CUDA, i has been devised o run on he wides range of hardware plaforms (including consoles and mobile phones), no limied o Nvidia ones, and hus, i is he main candidae for becoming he reference plaform for GPGPU in he near fuure. The main effor when dealing wih GPGPU is in he design of he algorihm. The challenging ask ha researchers and developers are currenly facing is how o redesign algorihms ha have been originally conceived o run in a serial manner for he CPU, o make hem parallel and hus suiable for he GPU. The main disadvanage of paricle-based mehods is ha hey require a very large number of paricles o obain realisic resuls. However, i is relaively easy o parallelize algorihms handling paricle sysems, and he massive parallel compuaion capabiliies of modern GPUs now makes i possible o simulae large sysems a ineracive raes Fuure Work Our algorihm for cloh simulaion can be improved in many ways. In he CUDA and OpenCL implemenaions, i would be ineresing o exploi he use of shared memory, which should reduce he amoun of global accesses and lead o improved performance. For fuure research, we would like o invesigae ways o generalize his algorihm by inroducing conneciviy informaion [Tejada 2005] ha sores he indexes of he neighbors of each paricle. This daa can be sored in consan memory o hide as much as possible he ineviable laency ha using his informaion would inroduce. By using conneciviy, i would be possible o simulae deformable, breakable objecs wih arbirary shapes, no only recangular pieces of cloh.

14 GPGPU Cloh Simulaion Using GLSL, OpenCL, and CUDA Demo An implemenaion of he GPU cloh simulaion is provided on he websie, and i includes boh he source code in C++ and he Windows binaries. The demo allows you o swich among he compuing plaforms a run ime, and i includes a hierarchical profiler. Even hough he source code has been developed for Windows using Visual Sudio 2008, i has been wrien wih cross-plaform compaibiliy in mind, wihou using any Windows-specific commands, so i should compile and run on *nix plaforms (Mac and Linux). The demo requires a machine capable of running Nvidia CUDA, and he CUDA Compuing SDK 3.0 needs o have been compiled. A video is also included on he websie. Acknowledgemens The shader used for rendering he cloh is fabric plaid from RenderMonkey 1.82 by AMD and 3DLabs. The auhor is graeful o Professor Ingemar Ragnemalm for having inroduced him o he fascinaing world of GPGPU. References [Müller 2008] Mahias Müller, Jos Sam, Doug James, and Nils Thürey. Real Time Physics. ACM SIGGRAPH 2008 Course Noes. Available a hp://www. mahiasmueller.info/realimephysics/index.hml. [Nvidia 2010] NVIDIA CUDA Bes Pracices Guide, Version 3.0, Available a hp://developer.download.nvidia.com/compue/cuda/3_0/oolki/docs/nvidia_ CUDA_BesPracicesGuide.pdf. [Tejada 2005] Eduardo Tejada and Thomas Erl. Large Seps in GPU-Based Deformable Bodies Simulaion. Simulaion Modelling Pracice and Theory 13:8 (November 2005), pp