In the 4.2 spec the definition of glDepthRange was changed to
void DepthRange( double n, double f );
from previous
void DepthRange( clampd n, clampd f );
with the wording changed to “If a fixed-point representation is used, the parameters n and f are clamped to the range [0; 1] when computing zw.”
So I expected it to behave like glDepthRangedNV that explicitly states that the values of n and f are not clamped. However, with glDepthRange with 4.2 core context and 306.97 NV drivers I’m reading back clamped values. Am I doing something wrong or have I read the spec incorrectly, assuming that with the floating point representation (of depth buffer) n and f would not be clamped?
No, this is a spec bug. Despite removal of GLclamp, all depth values are always clamped to [0,1].
No, that is a driver bug. The spec says what ought to happen; drivers are supposed to comply with that. If they don’t, it’s the driver’s fault.
This was a deliberate change in a revision of the spec document. It’s even stated in the changelog for 4.2 exactly why it was changed. If a driver isn’t doing what it says, that’s the driver’s fault. Depth values are not always clamped.
If depth is always clamped, what good is GL_DEPTH_COMPONENT32F? Is there a bug to remove that too? And who filed that bug, since the ARB deliberately made this change to allow unclamped depth ranges?