subroutines and multiple render targets

[Alfonse Reinheart]

Lack of vertex shader DOES produce an INVALID_OPERATION error at draw time in core profile.

Does it?

If the current vertex stage program object has no vertex shader, or no program object is current for the vertex stage, the results of programmable vertex processing are undefined.

It doesn't seem that way. Or if it does, the GL_INVALID_OPERATION must come from something else.

Come on, if you don't have to run fragment shaders on the shader cores, more vertex shaders can be in flight at once. How wouldn't be that faster? Think about it.

You're effectively alleging that shader compilers and implementations that are smart enough to inline functions, remove dead code, and various other optimizations are too stupid to optimize an empty fragment shader into the same thing as not having one. So as I said before, where is your evidence that any real systems will exhibit this performance difference?

In short, show me the driver/compiler which cannot optimize away an empty fragment shader.

Just create a core profile context, setup a vertex shader-only program, set draw buffers to none, attach a depth texture to your framebuffer and let it go. I bet you it will work.

Yes, and so will this fragment shader:

#version 330
 
out vec4 someColor;
 
void main()
{
  someColor = vec4(1.0f, 0.0f, 0.0f, 1.0f);
}

If you use this fragment shader without a call to glBindFragDataLocation, it will in virtually all cases assign `someColor` to output number 0. But the OpenGL standard does not require this behavior.

My point is that the standard itself doesn't provide coverage for the behavior that you suggest it does, not whether or not it will "work" on some or even all implementations. You can rely on undefined behavior if you want, but you shouldn't suggest that others do so.

[aqnuep]

It doesn't seem that way. Or if it does, the GL_INVALID_OPERATION must come from something else.

Okay, I admit I was wrong about this, in fact not having a vertex shader only makes the results of vertex processing undefined but doesn't generate an error. At least one of us can admit if he's wrong...

[thokra]

The spec clearly states in chapter 14

Thus, rasterizing a primitive consists of two parts. The first is to determine which squares of an integer grid in window coordinates are occupied by the primitive. The second is assigning a depth value and one or more color values to each such square. [..] The color values assigned to a fragment are determined by a fragment shader as defined in section 15. [..] The final depth value is initially determined by the rasterization operations and may be modified or replaced by a fragment shader.

Furthermore, section 15.2 clearly states:

Writing to gl_FragDepth specifies the depth value for the fragment being processed. If the active fragment shader does not statically assign a value to gl_-FragDepth, then the depth value generated during rasterization is used by subsequent stages of the pipeline.

Now, I think there may be room for interpretation here, although I have to agree that such an important fact should be made clear as day. So here's mine: Depth values are initially defined during rasterization. If a fragment shader is active and writes to gl_FragDepth, then the value is modified and set to the specified new value. Furthermore, it has to do so statically, i.e. not base writing to gl_FragDepth on dynamic braching whatsoever. Otherwise, the initial value, produced during rasterization and not during fragment shading, is used. Not having a fragment shader, i.e. fragment shader execution leading to undefined results, automatically results in gl_FragDepth not being set and thus the rasterized depth value not being modified. The depth value is defined - after rasterization.

In conclusion, I agree with aqnuep and I have yet to see a case where generating a correct depth map without a fragment shader has not worked cross-platform and cross-vendor and I have working examples of renderings on AMD, NVIDIA and Intel hardware.

Furthermore, why on earth would the ARB mandate that a fragment shader be present to actually defined a valid depth value? What about depth pre-passes? Nobody gives a damn about fragment shader outs. What about occlusion queries? Fragment shading? Why? I think this would be an oversight no one in the ARB could justify.

[aqnuep]

Thanks, thokra, for searching that for me. Apparently, I was doing lazy when trying to find the relevant spec statements.

Another thing to note, which is actually related to the original question:

While the driver may be able to optimize out an empty fragment shader, it cannot optimize out a shader that dynamically uniformly calls subroutines from which only a single subroutine is the one that doesn't emit any colors.

In this particular case the driver cannot optimize out the fragment shader as the decision is done at run-time (even if the decision is dynamically uniform) thus you'll have to pay for the cost of fragment shader execution for sure.