Khronos public bugtracker – Bug 726
Last modified: 2013-08-08 09:47:08 PDT
The spec doesn't fully explain what `depth_unchanged` means when redeclaring gl_FragDepth.
The important statements are these:
"When the layout qualifier is <depth_unchanged>, the shader compiler will honor any modification to gl_FragDepth, but the rest of the GL assume that gl_FragDepth is not assigned a new value."
"If a shader redeclares gl_FragDepth using the <depth_greater>, <depth_less> or <depth_unchanged> and then violates this contract, the results of the depth test may be inaccurate and any resulting rendering will produce undefined results."
What is unclear is what "this contract" means for <depth_unchanged>. It can be interpreted in two ways:
1. The contract is that you will set this value (if you do set it) to gl_FragDepth.z. Thus, undefined behavior if you don't.
2. If you set this value, OpenGL will completely ignore whatever you set it to and assume that gl_FragDepth.z is what you set it to. Thus, undefined behavior cannot happen.
I'm leaning towards 1 as the contract in question, because 2 doesn't really qualify as a "contract" so much as "OpenGL will ignore what you did."
If #1 is the case, perhaps a better way to say it would be:
"When the layout qualifier is <depth_unchanged>, gl_FragDepth can only be set to the fragment's interpolated depth value."
I checked the current language specification, the current API specification, and the extension in the registry and could not find the statement about "this contract ... may be inaccurate". (I assume it has since been fixed or eliminated, but if you still see it in a recent document, send more detail about which document and where.)
This statement is still present:
"When the layout qualifier is depth_unchanged, the shader compiler will honor any modification to gl_FragDepth, but the rest of the GL can assume that gl_FragDepthis not assigned a new value."
I believe it is clear. The value can be changed (to a different value) in the shader, while the rest of the system may assume it had not. That may lead to confusing results, which can be avoided by instead being consistent.
Closing out, unless someone can see that the offensive language is still present in a current specification. ("this contract ... may be inaccurate".)