GLSL, default value for output color

Question

Which is the default value for the output color in GLSL in case you dont set it?

#version 330

uniform sampler2DRect colorTex;
uniform vec3 backgroundColor;

out vec4 outputColor;

void main(void)
{
    vec4 frontColor = texture(colorTex, gl_FragCoord.xy);
    outputColor.rgb = frontColor + backgroundColor * frontColor.a;
}

Is it (0, 0, 0, 1)?

Ps: that code belongs to the old GL, trying to use it with the GL3, I get the following error

error C7011: implicit cast from "vec4" to "vec3"

I am right to suppose that in the old GL, the implicit cast was allowed?

This is the fragment shader of the front to back depth peeling example of Nvidia, you can find the code here, org.jogl.demos.dualdepthpeeling\org.jogl.demos.dualdepthpeeling\src\demos\dualDepthPeeling\shaders\front_peeling_final_fragment.glsl

To fix the error change it to outputColor.rgb = frontColor.rgb + backgroundColor * frontColor.a; — Richard Viney
@RichardViney, yeah, I know, but that code is the orignal example of the depth peeling example and I would like to understand which was the meaning of the author — elect
Maybe they were declaring backgroundColor as a vec4. You can't do vec4 + vec3 directly like that. — Richard Viney
@RichardViney I dont know, I think it is unlikely since in the code they are effectively loading a vec3 uniform.. (ps: I inserted the link to the original code in the question) — elect
This is a very old sample. It's possible that early GLSL compilers from NVIDIA would allow automatic conversions like this (back when it was built on their Cg compiler), but it certainly isn't valid in modern GLSL. Fortunately the fix is trivial. — Richard Viney

jozxyqk jozxyqk · Accepted Answer · 2015-03-23T09:12:54

With regard to the default fragment shader output: There is no default and the result is undefined if you don't set one. See other answers.

I notice you have a texture, and sampling an 'unbound'/incomplete texture is different [1][2]. There is a default, but in practice I would not rely on this for all drivers!:

If a fragment shader uses a sampler which associated texture object is not complete, as defined in section 3.8.10, the texture image unit will return (R, G, B, A) = (0, 0, 0, 1). [↱]

There's also a uniform value which may not be set either. These remain constant for the entire draw call, and like samplers, also have a default (although this is more of an "initial" value).

As a result of a successful link operation, all active user-defined uniform variables belonging to program will be initialized to 0 [↱]

But what actually happens when you don't set a fragment colour?

Being undefined in the spec means (0, 0, 0, 1) is a valid value and may in fact be the one you get. If a GL implementation (such as the one Nvidia or ATI provide with their driver + hardware) were to make this the consistent returned value, the generated shader code needs to set a default value or catch the case when you don't set one. This just adds overhead. It's faster to do nothing instead.

The shader must still return a value though, and what ever value is in the register/s for your fragment shader thread gets returned. This is uninitialized data (from the point of view of your shader program). Just like uninitialized memory in a CPU program, the value could be anything, generally depending on what was there beforehand. It's not uncommon for this to be all zeroes, or even something pretty consistent depending on the previous task the GPU was doing (i.e. another shader you run). Although I've found uninitialized values in the fragment shader quite commonly presents as flickering and can make patterns like this:

nvidia rasterizer pattern

GLSL, default value for output color

2 Answers

But what actually happens when you don't set a fragment colour?