GPU Architecture

• Stupid small instruction set
• Trades off for many, many cores
  • Lots of parallelism, lots of math, lots of floating-point operations

http://www.nvidia.com/object/what-is-gpu-computing.html

GPU Architecture

• Intended to churn out lots of triangles and pixels
• Pipeline:
  • Vertex Shader computes 3D geometry for a frame
  • Clipping/Projection squashes 3D objects into 2D space and determines regions of screen to draw to
  • Pixel/Fragment shader takes regions of screen and fills in color, with color or images or textures

https://www.opengl.org/wiki/Rendering_Pipeline_Overview

Emergent Behavior

• Eventually, people figured out ways to use this architecture for more than just triangles and pixels (kind of)
• Before any kind of proper "Compute Shader" API existed, people used the graphics pipeline to fake it
  • Initial applications:
    • Particle rendering systems physics calculations
      • e.g. smoke, fire, liquid, cloth
    • Ray-tracing (a typically expensive kind of lighting calculation)
    • Other ad-hoc big data transformations in the fields of chemistry/biology/other hard sciences (though I'm not sure on specifics and haven't actually been able to find anything)

Just for a sense of scale...

Credit for images:

http://theotherguy103.deviantart.com/art/Fire-particle-system-157655165

http://www.darwin3d.com/gdm1999.htm

https://www.youtube.com/watch?v=HurJ3b7n_8w

https://software.intel.com/en-us/articles/dynamics-and-particle-effects-part-1

http://gamma.cs.unc.edu/CSTREAMS/cloth/

The "Old-Fashioned" Way:

• A "texture" is just an image
  • A 2D array of structs which look like this:

//Exact specifics differ on hardware capabilities
//and/or user-defined output color definitions
//e.g. R8G8B8A8 uses bytes instead of floats
//This is a theoretical R32G32B32A32 example

struct Pixel
{
    float red;
    float green;
    float blue;
    float alpha; //transparency/opacity, usually
}

The "Old-Fashioned" Way

• Let's break that assumption:
  • What we really have is analogous to a vector

//Represents a point in 3D space
//Acceleration, Velocity, Position

struct Vec4
{
    float x;
    float y;
    float z;
    float w; //"are we in clip space yet?" indicator
}

The "Old-Fashioned" Way

Let's make a particle system!

• Assumption: Global forces, like wind or gravity
• "Texture" 1: Velocity
• "Texture" 2: Position
• Texture 3: Final screen output

"Texture" in quotes really means, "think of this as an array of structs"

Real Compute Shaders

• Let's be honest, this way kind of sucks!
  • It assumes you're working in a graphics application
  • It involves using terminology in ways that don't reflect how you're actually using them
    • The "texture" is really an "array"
    • The "color" is really a "velocity" or "position"
  • Basically a huge morass of coupling problems

Things have changed since then!

Real Compute Shaders

• OpenGL as of 4.3 now has Compute Shaders as a specific kind of shader program
  • No more need to repurpose vertex/fragment shader stages
• Same with OpenGL ES as of 3.1
• ​OpenCL exists as standalone and doesn't require graphical context
  • Requires different drivers and libraries entirely than OpenGL
• WebGL doesn't have any support, has to do it the vertex/fragment way
• WebCL exists and is in-progress, but isn't in browsers by default  yet
• DirectX has DirectCompute (not as familiar with this, sorry!)
• ​Vulkan requires you to set up your own pipeline
  • ​Avoids OpenGL/OpenCL "requires graphics"/"requires different libs" issue, configure per-app as needed

No one "right" method, depends on application

The Ecosystem as it stands:

Real Compute Shaders

• The specifics vary, but in general:
  • More generic terms
  • "Shader Storage Buffer Object" instead of "Texture"
    • User-defined buffers of structs
    • Not constrained to the RGB <=> XYZ architecture inherent to the graphics pipeline
  • Work divided into "Work Groups" and "Work Items" instead of "Regions" and "Fragments"

OpenGL 4.3 details and presentation slides:

https://www.khronos.org/assets/uploads/developers/library/2014-siggraph-bof/KITE-BOF_Aug14.pdf