Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Primer: Shaders

notes.underscorediscovery.com

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Primer: Shaders

#11

Post by jakobe »

sillysaurus3 wrote: post #2

Part 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…

Shader is a good name, because it implies what one of the main purposes of the code is: to apply lighting (shading) to the stuff.

How do you shade a vertex? Read about Gouraud shading. The idea is to do the expensive lighting calculation only at the vertices, and interpolate in-between. The "vertex shader" would calculate the shading at the vertices.

Obviously, you can use a vertex shader to do things other than shading, but "shader" is just a name, not a definition of all things this program can do.

Re: Primer: Shaders

#12

Post by 0x0 »

jakobe wrote: post #11
sillysaurus3 wrote: post #2

Part 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…

Shader is a good name, because it implies what one of the main purposes of the code is: to apply lighting (shading) to the stuff. How do you shade a vertex? Read about Gouraud shading. The idea is to do the expensive lighting calculation only at the vertices, and interpolate in-between. The "vertex shader" would calculate the shading at the vertices. Obviously, you can use a vertex shader to do things other than shad…

I found the name confusing the first time I encountered it. At first, I assumed it only had something to do with applying fancy lighting effects. Only after studying things further did it become obvious that a shader is responsible for doing 3d->2d projection and pixel filling - and you need them even if you only want to draw solid color shapes!

Re: Primer: Shaders

#13

Post by ANTSANTS »

sillysaurus3 wrote: post #2

Part 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…

Traditionally, lighting was calculated per vertex, not per pixel, and the results of those calculations were simply interpolated across the surface of the triangle. A "shader" is not the most general term they could have used for a GPU program, but you very well can "shade" a vertex.

Edit: Is this seriously being downvoted? "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!" is factually inaccurate because you can, and many games do, calculate color and lighting information per-vertex.

Re: Primer: Shaders

#14

Post by lingoberry »

sillysaurus3 wrote: post #2

Part 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…

I just want to say that you're correct, I've had this problem as well. As a non-native speaker for some reason it also didn't occur to me that the "shade" in shader has anything to do with color. It's just one of those things you can misunderstand. The way you explain it is much easier to understand.

I think all the people defending the term are all quite invested in the area already, so it's obvious to them.

Re: Primer: Shaders

#15

Post by sillysaurus3 »

ANTSANTS wrote: post #13
sillysaurus3 wrote: post #2

Part 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…

Traditionally, lighting was calculated per vertex, not per pixel, and the results of those calculations were simply interpolated across the surface of the triangle. A "shader" is not the most general term they could have used for a GPU program, but you very well can "shade" a vertex. Edit: Is this seriously being downvoted? "How do you "shade" a vertex? That implies color, when in fact vertex "shading" is really abou…

Actually, the per-vertex color is passed into the pixel shader, which then decides what to do with it. The vertex shader itself has nothing to do with color except calculating an initial value and passing it to the pixel shader. The pixel shader can be set up to interpret that value as anything. It could make it a grayscale color, it could invert it, it could use only one of the four channels, etc.

There used to be no pixel shaders, which is why vertex shaders had to be used to do shading. That was circa 2004 though. EDIT: This paragraph is incorrect, see comment below.

Also, the whole idea of "color" in a vertex shader is mistaken. There is only one color: the RGB that ultimately shows up on the screen. Until then, there are values which are passed from the main application source code to the vertex / pixel shaders, which then decide what to do with those values. Sometimes the pixel shader interprets them as a color, but they're really just floating point numbers. That may seem like a silly distinction, but again, if your mental model is incorrect as a newcomer then you're going to have a hard time.

Re: Primer: Shaders

#17

Post by reitzensteinm »

sillysaurus3 wrote: post #15
ANTSANTS wrote: post #13

Earlier quoted context omitted.

Traditionally, lighting was calculated per vertex, not per pixel, and the results of those calculations were simply interpolated across the surface of the triangle. A "shader" is not the most general term they could have used for a GPU program, but you very well can "shade" a vertex. Edit: Is this seriously being downvoted? "How do you "shade" a vertex? That implies color, when in fact vertex "shading" is really abou…

Actually, the per-vertex color is passed into the pixel shader, which then decides what to do with it. The vertex shader itself has nothing to do with color except calculating an initial value and passing it to the pixel shader. The pixel shader can be set up to interpret that value as anything. It could make it a grayscale color, it could invert it, it could use only one of the four channels, etc. There used to be n…

According to this, it's the other way around.

"The first shader-capable GPUs only supported pixel shading, but vertex shaders were quickly introduced once developers realized the power of shaders"

I actually very much disagree with your point about names. I write shaders when I have to, I'm not very good at it, but it feels fundamentally very broken, much as I picture the days of 16 bit x86 assembly (memory segmentation?).

There are arbitrary length, register etc limits per DX version, there's no clean cross platform method of writing shaders, the documentation is fragmented, vague, for the wrong platform or non existent.

Sure, the naming could be better, but page one of a decent textbook should set you straight. The other issues, not so much. Of course, that's more or less the price you pay for being on the bleeding edge of performance.

http://en.wikipedia.org/wiki/Shader#History

Re: Primer: Shaders

#18

Post by sillysaurus3 »

reitzensteinm wrote: post #17
sillysaurus3 wrote: post #15

Earlier quoted context omitted.

Actually, the per-vertex color is passed into the pixel shader, which then decides what to do with it. The vertex shader itself has nothing to do with color except calculating an initial value and passing it to the pixel shader. The pixel shader can be set up to interpret that value as anything. It could make it a grayscale color, it could invert it, it could use only one of the four channels, etc. There used to be n…

According to this, it's the other way around. "The first shader-capable GPUs only supported pixel shading, but vertex shaders were quickly introduced once developers realized the power of shaders" I actually very much disagree with your point about names. I write shaders when I have to, I'm not very good at it, but it feels fundamentally very broken, much as I picture the days of 16 bit x86 assembly (memory segmentat…

Oh! You're right, I was mixed up about the history. Sadly my mixup will probably detract from my other, non-history points as well. Thank you for correcting me.

I write shaders when I have to, I'm not very good at it, but it feels fundamentally very broken, much as I picture the days of 16 bit x86 assembly (memory segmentation?).

There are arbitrary length, register etc limits per DX version, there's no clean cross platform method of writing shaders, the documentation is fragmented, vague, for the wrong platform or non existent.

This is exactly why I push people to try using OpenGL and avoid Direct3D. All of those problems are D3D problems, not shader problems.

GL has no arbitrary length limits, and it has extremely accurate and thorough documentation. If a program is too complex to execute properly on the given hardware, then it's executed properly in software. Some see that as a terrible thing, and sometimes it is, but in today's mega-GPU world it's becoming increasingly rare to write shader programs that are so complicated that they have to be emulated in software by the driver. Getting an accurate result seems much better.

Re: Primer: Shaders

#19

Post by reitzensteinm »

sillysaurus3 wrote: post #18
reitzensteinm wrote: post #17

Earlier quoted context omitted.

According to this, it's the other way around. "The first shader-capable GPUs only supported pixel shading, but vertex shaders were quickly introduced once developers realized the power of shaders" I actually very much disagree with your point about names. I write shaders when I have to, I'm not very good at it, but it feels fundamentally very broken, much as I picture the days of 16 bit x86 assembly (memory segmentat…

Oh! You're right, I was mixed up about the history. Sadly my mixup will probably detract from my other, non-history points as well. Thank you for correcting me. I write shaders when I have to, I'm not very good at it, but it feels fundamentally very broken, much as I picture the days of 16 bit x86 assembly (memory segmentation?). There are arbitrary length, register etc limits per DX version, there's no clean cross p…

The limits are hardware limits. DX version is common shorthand for rough hardware generation. If you develop against the same shader model versions in GLSL, you'll have exactly the same limits.

See:

http://en.wikipedia.org/wiki/High-level_shader_language#Shad...

Re: Primer: Shaders

#20

Post by sillysaurus3 »

reitzensteinm wrote: post #19
sillysaurus3 wrote: post #18

Earlier quoted context omitted.

Oh! You're right, I was mixed up about the history. Sadly my mixup will probably detract from my other, non-history points as well. Thank you for correcting me. I write shaders when I have to, I'm not very good at it, but it feels fundamentally very broken, much as I picture the days of 16 bit x86 assembly (memory segmentation?). There are arbitrary length, register etc limits per DX version, there's no clean cross p…

The limits are hardware limits. DX version is common shorthand for rough hardware generation. If you develop against the same shader model versions in GLSL, you'll have exactly the same limits. See: http://en.wikipedia.org/wiki/High-level_shader_language#Shad...

Each video card has a different limit. If you develop against GLSL, you have the limit of whatever videocard you're using, which is substantially different from what DX would have you believe its limit is. GPUs are capable of more than what Microsoft would have you believe they're capable of.

The limits that you're referring to are artificial, because Microsoft mandates that if a pixel shader has more than N instructions then it shouldn't be allowed to compile, regardless of what the videocard is actually capable of doing. It's confusing, and the reason they decided to do it that way was for compatibility across a wide variety of hardware.

Post reply on HN