Why is a Fragment Shader named a Fragment Shader?

I’m writing some KISS tutorials on using OpenGL ES 2.0 in iOS/mobile, because I was frustrated that most of the tutorials on GL ES used incorrect or outdated approaches.

(I’m using the OpenGL ES 2.0 Programming Guide as my baseline, along with my own experiences of game-programming, and checking it all against Khronos Group / OpenGL.org’s docs as I go)

I use this stuff in iOS apps, but … I’m a relative novice with shader-pipelines. So I’ve been leaning on the guys at The Chaos Engine for proofreading and to help me avoid spreading misinformation. Most stuff people broadly agree on, but there’s been some interesting debate over a seemingly trivial question:

Why does OpenGL use the term “Fragment Shaders” to describe the shaders-that-generate-pixels? (where other API’s call the same thing “Pixel Shaders”, a much easier to understand/remember name)

To try and answer this, I hit up a couple of go-to resources:

Google “define Fragment Shader” (some Wikipedia hits, but they dodge the central question, and say “it’s the same as a Pixel Shader”)
My copy of “OpenGL ES 2.0 Programming Guide” (one of the authors was an editor of the GL ES 2.0 Specification)
Khronos Group’s official OpenGL.org website, and it’s wiki (although the wiki is often wrong or misleading, sadly)

Current theories

Theory1: Original idea was to generate small “bits” of shader (or: “fragments”) and chain them together

Reference: (private posts on TCE)

Theory2: When you use sub-pixel rendering techniques, a Fragment Shader is run multiple times per-pixel (it’s run once per-sub-pixel), so PixelShader is a misleading name

Reference: (private posts on TCE)

Theory3: A Fragment is “the potential to create a Pixel”. Multiple Fragments come together (one from each 3D object that overlaps a pixel) to create a final value of a Pixel

Reference: http://http.developer.nvidia.com/CgTutorial/cg_tutorial_chapter01.html

“A pixel represents the contents of the frame buffer at a specific location, such as the color, depth, and any other values associated with that location. A fragment is the state required potentially to update a particular pixel.

I’d not used this one before, but after writing the articles, it’s my current favourite. A “vertex” in OpenGL is definitely not a point-in-3D – it’s simply a collection of metadata, one part of which might be (but doesn’t have to be!) a 3D position.

Likewise, it makes sense that a “fragment” in OpenGL is definitely not a pixel-on-screen – it’s simply a collection of possibly incomplete metadata about the pixel we intend to (eventually) draw.

Any more?

Anyone else got a better explanation? An official definition? Or even … an unofficial one, but sourced with a link where someone from 3DFX / OpenGL / Khronos explains it in their own words?

A cursory review of the academic literature indicates that the term “fragment” often meant a manageable part of whatever it was you were rendering, at first. Tom Duff’s “Compositing 3-D Rendered Images” (1985) uses it in passing to refer to partial segments of a pixel, for example.

Karl Sims in “Particle animation and rendering using data parallel computation” (1990) discusses “dicing” particles into “pixel-sized fragments” for parallel processing by “fragment processors”.

Now, I’m no expert at terminology archaeology, but both of these papers have a not-insignificant number of citations. Perhaps the latter contributed in getting the term to stick, and perhaps it didn’t, but for lack someone stepping up and saying they named it that way, it seems like a good springboard for a more thorough search.

2 replies on “Why is a Fragment Shader named a Fragment Shader?”

For what I’ve read, both 2 and 3 sound good. 3 better than 2.

I remember the first explanation I got was nº2. But last time I readed the programming guide I thing I found something similar to 3 and it sounds as a good explanation to me.

Comments are closed.