In the first part of “WebGL, GPGPU & Flocking Birds”, I introduced flocking. I mentioned briefly that simulating flocking can be a computationally intensive task.
It’s possible to speed this up using various tricks and techniques (eg with more efficient threading, data structures etc), but when one greed for more objects, yet another brick wall can be found quickly.
So in this second part, I’ll discuss the role of WebGL and GPGPU which i would use for my flocking birds experiments. It certainly may not be the best or fastest way to run a flocking simulation, but it was interesting experimenting with WebGL to do some of heavy lifting of the flocking calculations.
I think another way one can look at WebGL, is as an interface or a way to tap into your powerful graphics unit. Its like learning how to use a forklift to lift heavy loads for you.
Intro to GPUs and WebGL Shaders
For a long time, I understood computers had a graphics card or unit but never really understood what it is really until recently. Simply put, the GPU (Graphics Processing Unit) is a specialized piece of hardware for processing graphics efficiently and quickly. (More on Cuda parallel programming on Udacity, if you’re interested)
The design of a GPU is also slightly different from a CPU. For one, GPU can have thousands of cores compared to dozen that a CPU may have. While GPU cores may run at a lower clockrate, its massive parallel throughput may be higher than what a CPU can perform.
A GPU contains vertex and pixel processors. Shaders are code used to do to program them, to perform shading of course. That includes coloring, lighting, post-processing for images.
A shader program have a linked vertex shader and a pixel(aka fragment) shader. In a simple example to draw a triangle, a vertex shader calculates the coordinates of the 3 points of the triangle. The calculated area in between the triangle is passed on to the pixel shader where it paints each pixels in the triangle.
Some friends have asked me what language is used to program WebGL shaders. They are written in language call GLSL (Graphics Library Shading Language), a C like language also used for OpenGL shaders. At least, I think if you understand JS, GLSL shouldn’t be too difficult to be picked up.
Knowing that WebGL shaders are what used to run tasks on the GPUs, we have a basic key in unlocking powerful computation capabilities that GPUs have, even though it is primary for graphics. Moving on to the exciting GPGPU – “General-purpose computing on graphics processing units”.
Exploring GPGPU with WebGL
WebGL, instead of only rendering to the screen, has the ability to write to its own memory. These rendered bitmaps in memory or RAM is referred to Frame Buffer Objects (FBOs) and the process can sometimes be simply referred as a render-to-texture (RTT).
This may start to sound confusing, but what you need to know is that the output of shader can be a texture, and that texture can be an input for another shader. One example is an effect to rendering a scene inside a TV as part of a scene inside a room.
Frame buffers are also commonly use for post-processing effects. (Steven Wittens has a library for RTT with three.js)
Now how do we start making use or abusing this for GPGPU? First consider what would a Frame Buffer possibility represent. We know that a render texture is basically a quad / 2d array holding RGB(A) values, and we could decide that a texture could represent particles, and that we could represent each pixel as each particle’s position.
For each pixel we can assign the RGB channels to the positional component (red=x position, green=y position, blue=z position). A color channel may only have a limited range of 0-255, but if we enable floating-point texture support, each channel goes from -infinity to infinity (though there’s still limited precision). Currently, some devices (like mobile) do not support floating-point texture support, so one should decide whether to drop support for those devices or pack a number over a few channels to simulate a value type of larger range.
The next step after the simulation phase is to display the gpu simulated particles on screen. The approach is to render particles like normal, however, the vertex shader then looks up its positional information stored in the texture. Its like adding just a little more code to your vertex shaders to read the position from the texture, and “hijacking” the position of the vertex you’re about to render. This requires an extension to lookup textures in the vertex shader but likely its supported when floating point textures are.
Hopefully by now, this gives a little idea on how “GPGPU” could be done in WebGL. Notice I mentioned with WebGL, because its likely that you can perform GPGPU in other ways(eg. with WebCL) in a different approach. (Well, someone wrote a library call WebCLGPU, a WebGL library which emulates some kind of WebCL interface, but I’ll leave you to explore that).
(Some trivial: In fact, this whole GPGPU with WebGL was really confusing to me at first and I did not know what its supposed to be called. While one of the earliest articles about GPGPU with Webgl referred to this technique as “FBO Simulations”, many still refer to as GPGPU.
What’s funny what that initially I thought GP-GPU (with its repetitive acronym) is used to describe “ping-pong”-ing of textures in the graphics card but well… there may be some truth in that. 2 textures are typically used and swapped for simulating positions because its not recommended to read and writing to the same textures at the same time.)
Exploration and Experiments
Lastly, one point about exploration and experiments.
Simulating particles GPGPU are getting common these days, (there are probably many on chrome experiments), and I’ve also worked on some in the past. Not to say that they are boring, (one project which i found interesting is the particle shader toy) but I think there are many more less explored and untapped areas of GPGPU. For example, it could be used for fluid, physics simulations and applications such as terrain sculpting, cloth, hair, cloth simulation etc.
As for me, I started playing around with flocking. More about it in the 3rd and final part of these series.