• Advertisement
Sign in to follow this  

Pixel Shader vs Fragment Shader

This topic is 4294 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Are they just synonyms? A friend of mine uses Cg (I use HLSL) and he says the term pixel shader "doesn't exist". This (old) article says "fragment vertex processing" is used to do constrained vertex processing (reduce the # of possible shader combinations needed). Is that a different idea?

Share this post


Link to post
Share on other sites
Advertisement
The "pixel" in "pixel shader" is a misnomer because the pixel shader doesn't operate on pixels directly. The pixel shader operates on "fragments" which may or may not end up as actual pixels, depending on several factors outside of the pixel shader.

Unfortunately, the terms "pixel shader" and "binormal" (also a misnomer -- it should be "bitangent") are here to stay.

Share this post


Link to post
Share on other sites
Ok. So for sake of conversation, how have people dealt with constrained vertex processing as of late? (As discussed in that link)

Share this post


Link to post
Share on other sites
I think everyone pretty much refers to vertex shader or vertex program. "Fragment vertex processing" doesn't make much sense, because it's not like vertices have seperate fragments or something, like pixels can. Although, I guess a person could make an argument about a vertex program only modifying certain parts of a set of vertex streams or something, but that would just be arguing for the sake of arguing, I think.

Share this post


Link to post
Share on other sites
Quote:
I think everyone pretty much refers to vertex shader or vertex program. "Fragment vertex processing" doesn't make much sense


From my brief scan of the article linked it appears 'fragment vertex processing' refers to writing several bits of vertex programs (i.e. fragments of programs) that each do a different thing, so you'd have some to do transforms (this may change if you're using skinning for animation in one model, and then just rendering a static model with no animation), some to do lighting etc. You then construct a vertex program from several of these program fragments, this gives you a nice flexible materials system as you don't have to manually write a shader for every possible material, instead you write bits of a shader for each different type of lighting and shading a material could have and then just say use these bits for this material.

As for how this is handled now I believe UE3 has a similar approach of building up vertex and fragment programs from little bits. I saw a video where they showed a UI where an artist could build a shader and it was basically a flow chart, with each block representing some kind of operation in the shader (it may be a simple modulation of two colour components or a lighting technique or something like that). Half Life 2 has a system whereby they write one big shader with everything in and then use conditional compilation to only compile certain bits, they then create every possible combination of bits (the main shaders in HL2 end up producing ~5000 actual shaders). If you have dynamic branching available you can take the same approach as HL2 but instead of having to compile every possible combination you just have if(feature){} blocks in your shader. The reason you may not want to do this is dynamic branching may not be supported on your target hardware, or if it is supported it my be slower than using say the HL2 technique.

Share this post


Link to post
Share on other sites
Yeah I think it's just a crossing of terminology, fragment shaders and shader fragments are two different things. ;) Fragment shaders being another term for pixel shader, and shader fragments being pieces of shader code that can be linked/combined to form a complete shader program.
Monder - if( feature ){} is actually static branching, which is more efficient than dynamic branching since the same side of the branch is taken over the course of the DrawPrimitive call.

Share this post


Link to post
Share on other sites
Typically most people use PS for DirectX (HLSL) based shaders, and FS for Cg and GLSL. So thats the way I use them to minimize any confusion. Although as JohnBolton says the correct term is Fragment Shader.

Share this post


Link to post
Share on other sites
Even "shader" is a misnomer. Shaders don't "shade". I think that "vertex program" and "fragment program" are the best terms.

Share this post


Link to post
Share on other sites
Monder and FBMachine: Thanks! Looks like I confused yet another term...

noNchaoTic: I noticed that... Cg fans say "fragment!", M$ says "pixel!"

JohnBolton: Agreed! That was my whole confusion when beginning with "shaders".

Monder - that is really cool, how HL2 did that. Now the screenshots of shader UI's with flow charts start to make sense.

Thanks all.

Share this post


Link to post
Share on other sites
Quote:
that is really cool, how HL2 did that. Now the screenshots of shader UI's with flow charts start to make sense.


Basically at the top of the shader they have some stuff in comments that lists various names to define and the possible values they can be defined to, there's then a preprocessor (written in perl I think) which then goes and generates every possible combination. So for example you may have something like this at the top:

// DYNAMIC: "FEATURE1" "0..1"
// DYNAMIC: "FEATURE2" "0..1"

Then there'd be a shaders genertated with FEATURE1 and FEATURE2 set to 1, FEATURE1 set 0 and FEATURE 2 set to 1 etc. There's some more info here in the Combo variables section.

The Shader UI is an Unreal Engine 3 thing, there is a video of it though I can't find it atm, (I think they showcased it at GDC, possibly last year).

Share this post


Link to post
Share on other sites
Quote:
Original post by discman1028
Now the screenshots of shader UI's with flow charts start to make sense.


I'm thinking, now, that these screenshots that I had seen were shader networks, in art programs. These seem to be common.

Share this post


Link to post
Share on other sites
Quote:
Original post by noNchaoTic
JohnBolton says the correct term is Fragment Shader.


You call them fragment only if you're used to OpenGL.. And the term "shader" is not used on OpenGL (at least not in this meaning).

Well just use "Pixel Shaders", everybody knows what it is nowaday and every constructor only uses this terminology when referring to their hardware.

LeGreg

Share this post


Link to post
Share on other sites
Quote:
Original post by discman1028
Quote:
Original post by discman1028
Now the screenshots of shader UI's with flow charts start to make sense.


I'm thinking, now, that these screenshots that I had seen were shader networks, in art programs. These seem to be common.


Actually, now I'm thinking the original sshot I saw was from UE3. i.e. this.

Share this post


Link to post
Share on other sites
Quote:"Even "shader" is a misnomer. Shaders don't "shade". I think that "vertex program" and "fragment program" are the best terms."
--------------------------------------------------------------------------------

This is pedantic. Terms mean what we want them to mean. Shaders can indeed shade, and is what they often used for. Anyway, pixel shader sounds cooler and makes more sense than "fragment program", which means exactly nothing.

Also, the term "shader fragment" is also used.. by your method, what would these be called--"program fragments"? or "fragment program fragements"? --this makes no sense.

Shaders are unique in functionality, and ought to have a unique and recognizable name.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement