anyone an idea what the exact relation between result.depth and fragment.position in the fragment program is? Naively I thought assigning result.depth with fragment.position.z should result in the standard fixed function pipe behaviour…but wrong.
Here are some fragments of the ARB_fragment_program specification
(12) Should depth output be pulled from the 3rd or 4th component?
RESOLVED: 3rd component, as the 3rd component is also used for
depth input from the "fragment.position" attribute.
(26) Is depth output from a fragment program guaranteed to be
invariant with respect to depth produced via conventional
RESOLVED: No. The floating-point representation of depth values
output from a fragment program may lead to the output of depth
with less precision than the depth output by convention GL
rasterization. For example, a floating-point representation with
16 bits of mantissa will certainly produce depth with lesser
precision than that of conventional rasterization used in
conjunction with a 24-bit depth buffer, where all values are
maintained as integers. Be aware of this when mixing conventional
GL rendering with fragment program rendering.
On some implementations, the components of fragment.position may be
generated by interpolating per-vertex position values. This may
produce x and y window coordinates that don’t exactly match those of
the fragment center and z window coordinates that do not exactly
match those generated by fixed-function rasterization. Therefore,
there is no guaranteed invariance between the final z window
coordinates of fragments processed by fragment programs that write
depth values and fragments processed by any other means, even if the
fragment programs in question simply copy the z value from the
Thanks, this explained and solved the issue!
I suppose the surprisingly big precision difference results from the comparably low precision floating point fragment shader (24bit on ATI) and the fairly high precision 24bit fixed point depth buffer I used.