{"id":2791,"date":"2013-10-05T15:22:52","date_gmt":"2013-10-05T14:22:52","guid":{"rendered":"http:\/\/t-machine.org\/?p=2791"},"modified":"2013-10-06T10:02:39","modified_gmt":"2013-10-06T09:02:39","slug":"why-is-a-fragment-shader-named-a-fragment-shader","status":"publish","type":"post","link":"http:\/\/new.t-machine.org\/index.php\/2013\/10\/05\/why-is-a-fragment-shader-named-a-fragment-shader\/","title":{"rendered":"Why is a Fragment Shader named a Fragment Shader?"},"content":{"rendered":"

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

(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)<\/p>\n

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<\/a> 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:<\/p>\n

\nWhy 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)\n<\/p><\/blockquote>\n


\nTo try and answer this, I hit up a couple of go-to resources:<\/p>\n

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

    Current theories<\/h2>\n

    Theory1: Original idea was to generate small “bits” of shader (or: “fragments”) and chain them together<\/h3>\n

    Reference: (private posts on TCE)<\/p>\n

    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<\/h3>\n

    Reference: (private posts on TCE)<\/p>\n

    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<\/h3>\n

    Reference: http:\/\/http.developer.nvidia.com\/CgTutorial\/cg_tutorial_chapter01.html<\/a><\/p>\n

    \n“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.\n<\/p><\/blockquote>\n

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

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

    Any more?<\/h2>\n

    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? <\/p>\n","protected":false},"excerpt":{"rendered":"

    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 \/ […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,20],"tags":[],"_links":{"self":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/2791"}],"collection":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/comments?post=2791"}],"version-history":[{"count":4,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/2791\/revisions"}],"predecessor-version":[{"id":2826,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/posts\/2791\/revisions\/2826"}],"wp:attachment":[{"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/media?parent=2791"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/categories?post=2791"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/new.t-machine.org\/index.php\/wp-json\/wp\/v2\/tags?post=2791"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}