Primer: Shaders
notes.underscorediscovery.com
Primer: Shaders
1–10 of 36 posts
Re: Primer: Shaders
#2Part of the confusion is the confusing terminology. "Shader" is a bad name. How do you "shade" a vertex? That implies color, when in fact vertex "shading" is really about deforming the position of vertices. It has nothing to do with color!
"Vertex program" is a better term.
That brings us to "pixel shader." That's actually a good name in order for beginners to learn the concept, but it's imprecise. OpenGL insists on calling it a "fragment program" because with certain forms of antialiasing, there are multiple "fragments" per pixel. "Program" is also a better name than "shader" because there are things you can do per-pixel other than change the color. For example you could change the depth written to the Z-buffer, or you could cause the pixel to be skipped based on some criteria, like whether the texture color is pink.
Anyway, it's just a tiny program that executes either per-vertex or per-pixel. For example you could write a vertex program which moves each vertex in a sinewave pattern based on time. Or you could write a fragment program to change the color of each pixel from red to green and back based on time.
Then there are more advanced/recent concepts like a "geometry program," which lets you generate triangles based on vertices or edges.
Sometimes I wonder if it's overly complicated, or if the problem domain is just complicated. It took me years as a kid to finally grok this, but once I learned it, it turned out to be very simple. Honestly it wasn't until I got up enough courage to sit down with the OpenGL specs and read through them that everything clicked. They're dry reading but not difficult.
Re: Primer: Shaders
#3Part of the confusion is the confusing terminology. "Shader" is a bad name. How do you "shade" a vertex? That implies color, when in fact vertex "shading" is really about deforming the position of vertices. It has nothing to do with color! "Vertex program" is a better term. That brings us to "pixel shader." That's actually a good name in order for beginners to learn the concept, but it's imprecise. OpenGL insists on…
The reason it's not called vertex program is because the pipeline is defined in terms of stages (vertex -> tessellation control -> tessellation evaluation -> geometry -> rasterizer -> fragment). Together they are a program. When talking about this structure the choice that OpenGL made is:
"A shader program consists of a vertex shader (VS), tessellation control shader (TS control), tessellation evaluation shader (TS eval), geometry shader (GS) and fragment shader (FS)."
You could instead say this, but it would be confusing:
A shader program consists of a vertex program, tessellation control program, tessellation evaluation program, geometry program and fragment program.
And it would even get more confusing if you drop the first shader:
"A program consists of a vertex program, tessellation control program, tessellation evaluation program, geometry program and fragment program."
So for the sake of it being easy to talk about, a (shader) program is the whole thing, whenever somebody talks about a "program" it's the whole assemblage. And when somebody talks about a shader, it means one of the programs tied to a stage.
Re: Primer: Shaders
#4As someone who is not well-versed in graphics or graphics programming, this was a very well-explained primer. I very thoroughly enjoyed it, and learned something in the process!
Re: Primer: Shaders
#5Part of the confusion is the confusing terminology. "Shader" is a bad name. How do you "shade" a vertex? That implies color, when in fact vertex "shading" is really about deforming the position of vertices. It has nothing to do with color! "Vertex program" is a better term. That brings us to "pixel shader." That's actually a good name in order for beginners to learn the concept, but it's imprecise. OpenGL insists on…
The reason it's not called vertex program is because the pipeline is defined in terms of stages (vertex -> tessellation control -> tessellation evaluation -> geometry -> rasterizer -> fragment). Together they are a program. When talking about this structure the choice that OpenGL made is: "A shader program consists of a vertex shader (VS), tessellation control shader (TS control), tessellation evaluation shader (TS e…
Yeah, this has the side effect of making it almost impossible for newcomers to have any clue what the heck is going on until they have several months of (painful) experience trying to figure out each piece.
It doesn't have to be this complicated. Humans just made it that way. I'm just trying to make sure everyone understands that there's nothing mysterious or even especially interesting about these terms. It's complicated like an internal combustion engine is complicated, not like math.
Re: Primer: Shaders
#6Earlier quoted context omitted.
The reason it's not called vertex program is because the pipeline is defined in terms of stages (vertex -> tessellation control -> tessellation evaluation -> geometry -> rasterizer -> fragment). Together they are a program. When talking about this structure the choice that OpenGL made is: "A shader program consists of a vertex shader (VS), tessellation control shader (TS control), tessellation evaluation shader (TS e…
Yeah, this has the side effect of making it almost impossible for newcomers to have any clue what the heck is going on until they have several months of (painful) experience trying to figure out each piece. It doesn't have to be this complicated. Humans just made it that way. I'm just trying to make sure everyone understands that there's nothing mysterious or even especially interesting about these terms. It's compli…
So you are proposing that the difference in calling it a "program" vs. a "shader" increases the complexity of learning the concept by several months?
Re: Primer: Shaders
#7Earlier quoted context omitted.
Yeah, this has the side effect of making it almost impossible for newcomers to have any clue what the heck is going on until they have several months of (painful) experience trying to figure out each piece. It doesn't have to be this complicated. Humans just made it that way. I'm just trying to make sure everyone understands that there's nothing mysterious or even especially interesting about these terms. It's compli…
So you are proposing that the difference in calling it a "program" vs. a "shader" increases the complexity of learning the concept by several months?
Sure, it did for me. I think mental models are important, and that it's kind of dopey to call something by a confusing name. (I'm looking at you, physics!) But on the other hand, I'm not very smart, and I had to spend most of my time on gradeschool instead of learning shaders. It was also before wonderful resources like stackoverflow/HN/reddit/etc, so there weren't a lot of people to help clarify my mental model.
As I've gotten older it's become easier to think abstractly and accept that names sometimes have nothing to do with what things are. But when you're first starting out, it's natural to want to visualize everything you learn as what it sounds like.
Re: Primer: Shaders
#8Part of the confusion is the confusing terminology. "Shader" is a bad name. How do you "shade" a vertex? That implies color, when in fact vertex "shading" is really about deforming the position of vertices. It has nothing to do with color! "Vertex program" is a better term. That brings us to "pixel shader." That's actually a good name in order for beginners to learn the concept, but it's imprecise. OpenGL insists on…
The reason it's not called vertex program is because the pipeline is defined in terms of stages (vertex -> tessellation control -> tessellation evaluation -> geometry -> rasterizer -> fragment). Together they are a program. When talking about this structure the choice that OpenGL made is: "A shader program consists of a vertex shader (VS), tessellation control shader (TS control), tessellation evaluation shader (TS e…
I don't personally see why this is so confusing. I think that if you're writing shaders you can probably understand that 'program' is a somewhat recursive term. A program is made up of other programs (a function or a module is a program as well).
But even then, you could call them functions (which is practically a synonym for program in a sense, and also obviously recursive, in that functions call other functions).
Either would at least be less obviously 'wrong' in the sense GP meant it.
But I also think "kernel" is a stupid term for GPGPU programs, and definitely increases the barrier to learning what isn't really all that complicated of a thing (at least not at the intro level).
Re: Primer: Shaders
#9Earlier quoted context omitted.
So you are proposing that the difference in calling it a "program" vs. a "shader" increases the complexity of learning the concept by several months?
Sure, it did for me. I think mental models are important, and that it's kind of dopey to call something by a confusing name. (I'm looking at you, physics!) But on the other hand, I'm not very smart, and I had to spend most of my time on gradeschool instead of learning shaders. It was also before wonderful resources like stackoverflow/HN/reddit/etc, so there weren't a lot of people to help clarify my mental model. As…
If shaders are hard, it's mostly because they require a full understanding of 3D math, the complete graphic pipeline, texture sampling, image manipulation techniques and how it all comes together before you can actually start doing anything useful; so the learning curve has a slope of 'wat' to almost all newcomers.
If anything, naming is just a nuisance.
Re: Primer: Shaders
#10Earlier quoted context omitted.
Sure, it did for me. I think mental models are important, and that it's kind of dopey to call something by a confusing name. (I'm looking at you, physics!) But on the other hand, I'm not very smart, and I had to spend most of my time on gradeschool instead of learning shaders. It was also before wonderful resources like stackoverflow/HN/reddit/etc, so there weren't a lot of people to help clarify my mental model. As…
If shaders are hard, it's mostly because they require a full understanding of 3D math, the complete graphic pipeline, texture sampling, image manipulation techniques and how it all comes together before you can actually start doing anything useful; so the learning curve has a slope of 'wat' to almost all newcomers. If anything, naming is just a nuisance.
they require a full understanding of 3D math, the complete graphic pipeline, texture sampling, image manipulation techniques and how it all comes together before you can actually start doing anything useful
Hm, not really. I learned more from messing with working demos and prototypes than studying theory. But YMMV.
It's absolutely true that the whole pipeline is very intimidating for newcomers, though.
I love that phrase... "the learning curve has a slope of 'wat'."