gl_FragCoord.z confusion

[MrFrustum]

Hello,

my question is simple.

Where do gl_FragCoord.z come from?

Is it coming from the rasterizer ( the eventually new incoming depth buffer value ) or is it the actual value grabbed from the depth buffer?

[Aleksandar]

I'll give you an answer by asking you a question.
Does fragment shader execution comes before writing to a framebuffer of after? If you don't change fragmet's depth some of early-z techniques would eliminate FS execution if they are sure it wouldn't generate a new value in the framebuffer.

[MrFrustum]

:) ok ok.

I'm trying to figure out how to access depth buffer directly in the fragment shader. It seems that DX10 can do that via Shader Resource View without rendering into a texture and binding it again in the second pass.

Does OpenGL exposes this feature too?

[Aleksandar]

Why do you need that? To write your own function that will decide whether to write new Z-value in the dept buffer or something else? If you need the final values of the depth buffer you would need a second pass anyway.

[Alfonse Reinheart]

I'm trying to figure out how to access depth buffer directly in the fragment shader.

You don't.


It seems that DX10 can do that via Shader Resource View without rendering into a texture and binding it again in the second pass.

That's just because D3D10 requires you to create the equivalent to OpenGL's "default" buffers itself. Shader Resource View is just a way to bind parts of textures (particular mipmaps, groups of mipmaps, etc) as textures to fetch from.

[MrFrustum]

Yes i would like to write my custom depth testing when i need it ( to avoid Z-fighting for example ). So is not possible to access depth buffer in the fragment shader.
Right?

There is a similar problem with blending. You can't access color buffer in the fragment shader and write your custom blending function. Right?