Shader terminology

I’m finding the effect framework to have some confusing terminology. If I look in the pdxfxlib (effect library) file I see something like:

Keys:
    Effect.Name: TextureEffect

fair enough, that defines a custom effect. However, when I look at pdxfx file (effect file) I’ll see something like:

namespace TextureArraySample.Effects
{        
    shader TextureEffect
    {
        // define vertex shader
        mixin TransformationWAndVP; // use built in vertex shader
        
        // define pixel shader
        mixin TextureShader; // define a custom shader 
    };
}

Here you have the shader keyword, but this is an effect, not a shader. There are well defined shader stages on the GPU, vertex, tesselation, pixel etc. A shader is a program that operates over one of these shader stages. If I lookup Effect in DirectX I see this:

A DirectX effect is a collection of pipeline state, set by expressions written in HLSL and some syntax that is specific to the effect framework. After compiling an effect, use the effect framework APIs to render. Effect functionality can range from something as simple as a vertex shader that transforms geometry and a pixel shader that outputs a solid color, to a rendering technique that requires multiple passes, uses every stage of the graphics pipeline, and manipulates shader state as well as the pipeline state not associated with the programmable shaders.

So an effect is a higher level abstraction, above shader. It is an effect that may operate over many pipeline stages, not a shader. But in Paradox you have blurred the terminology, so that shaders operate over many pipeline stages, and it’s made worse by defining the shaders as classes, rather than shaders.

Take ShaderBase.pdxsl, it has the sl extention, so it’s written in shader language. It’s called ShaderBase, but it’s not a shader in Paradox, it’s a class. And unfortunately, it has VSMain() and PSMain(), so it’s actually an effect, a composition of shaders, not a shader at all, shader language doesn’t define any language that I know of to call into another shader program.

Now, if you are going to use the term ‘shader’ to mean both a shader-stage program and a composition of shader-stage programs, then you shouldn’t use the term ‘effect’ and you probably shouldn’t use the term class. I find it confusing when navigating the shader/effect tree to see class/shader/effect and they all mean the same thing (but different things in specific and non-traditional circumstances).

I have a little experience with hlsl and I either had to write an effect (xna/dxtoolkit) or as in SharpDX (without toolkit) I would write the vertex and pixel shaders separately. There is a clear separation between the shader-stages there. This is all really confusing for people learning this stuff and it confused me too. I spent some time looking through the shader source over the weekend.

I don’t think this is your fault, I think this terminology has been used too loosely everywhere, that is, the usage of ‘effect’ and ‘shader’, to mean the same thing and different things in different code/frameworks.

Now, I may have to defer to you expertise, but if I were to define these terms clearly for myself I would use the following:

class ShaderBase { ... } // as it is now, but i would replace it with...

effect EffectBase { … }
// use effect instead of class & shader, effects define compositions of shader programs.

class ComputeColor { ... } // as it is now, but i would replace it with...

shader ComputeColor { … }
// shaders are part/full shader programs that operate within a shader-stage, Paradox provides shader inheritance.

I would not permit mixing vertex and pixel shaders within a shader file, these are clearly not shader-programs, they are effects. Effects are ultimately broken down into discrete vertex and pixel shader bytecode, so why should we confuse the matter by having an abstraction that mixes them together as 'shaders'.
I would remove the 'class' term entirely from the effect framework. These are shader programs we are writing, yes, you are providig a kind of class inheritance but, but they are still shaders.
1 Like

Thanks for the feedback, very helpful.
Not sure yet what will happen but we will definitely do another pass on our shading language.