[Mesa-dev] [PATCH 2/4] mesa: Add helper function to see if we have a float depth format.

Mathias Fröhlich Mathias.Froehlich at gmx.net
Mon Sep 15 10:04:53 PDT 2014


Hi again,

On Monday, September 15, 2014 18:11:51 Roland Scheidegger wrote:
> btw I'm not entirely sure everything is really correct with llvmpipe wrt
> that extension (the rasterization stuff, gallium isn't involved in the
> texture conversion). There's some very annoying differences how things
> work between d3d10 and GL there (I suspect there's actually bugs wrt
> d3d10 too especially when outputting depth from the pixel shader but so
> far we got away with it).
> So, with old style GL rendering, you can't actually produce depth values
> outside 0/1, due to clipping. But this is no longer true since a while
> for various reasons - fragment shader writing depth, ARB_depth_clamp,
> clip control... There's various places such values are clamped later -
> with ARB_depth_clamp if enabled they are clamped to min/max depth range
> (hence not outside 0/1 unless using the nv extension), I'm pretty sure
> there's also a 0/1 clamp elsewhere if you output depth from a fragment
> shader.
> With d3d10, you can likewise disable clipping, but there's no 0/1 clamp
> anywhere in sight (just to value range reproducible by depth buffer
> format), and the depth clamp is always enabled, regardless any depth
> clip enable / disable bits (clamping to the zmin/max range, which is not
> limited).
> In any case, I think there's a lot of possiblities of subtle bugs when
> trying to support this extension.

You are actually mentioning clip control.
I knew that there is something in the queue, but I thought that this is
not available as an extension and only available with new enough OpenGL
versions. But there actually is ARB_clip_control.

This one actually fits the bill.
Am I right that you would not object against ARB_clip_control?

Greetings

Mathias



More information about the mesa-dev mailing list