Hi Roland, On Monday, September 15, 2014 16:57:49 Roland Scheidegger wrote: > Hmm actually that wasn't right, it does make a difference if the nv or > core format enums are used, at least for texture specification (nv won't > clamp, whereas core will) and probably for rasterization too, what a > mess. I don't think the patches handle that right. I thought that too and thought that we will need an other internal format for them. One being clamped and one not.
Then I looked at the closed implementation of the company inventing this. There, both GL_DEPTH_COMPONENT32F_NV and GL_DEPTH_COMPONENT32F do not clamp the z values in the viewport transform, means when glDepthRangedNV is used and n or f are outside of [0, 1], you get depth values between unclamped n and f. But if you take a fragment shader that writes gl_FragDepth, the output value is clamped to [0, 1] past the fragment shader. This is again with both enum buffer internal formats. So, the NVidia driver does not distinguish between the buffer types, more between the uses. And I thought I will try doing the same so far here. That variant would be easier to achieve, treat buffers like they are treated with the patch, alias the .._FLOAT with .._FLOAT_NV variant. Then with a usual projection matrix you will get values that you expect from the world -> [-1, 1] -> [n, f] range if you're not writing gl_FragDepth. If you write gl_FragDepth, just continue what you do today - I don't know if mesa clamps that today. But yes, I can see the argument for doing that as specified. So, for the gallium side, introduce a PIPE_FORMAT_Z32_FLOAT_UCLAMP and PIPE_FORMAT_Z32_FLOAT_UCLAMP_S8X24_UINT? Other names? What to do? Greetings Mathias _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
