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

[Roland Scheidegger]

Am 17.09.2014 09:21, schrieb Mathias Fröhlich:
> 
> Good Morning,
> 
> On Monday, September 15, 2014 20:33:17 Roland Scheidegger wrote:
>> I don't really know what to do though. It looks like the implementation
>> doesn't really do what the nv spec claims anyway, so it's difficult to
>> even figure out what should be done...
> 
> That all gets much more interesting than I thought initially.
> 
> Yes, it would be good if somebody knowing the history can shed more light on this.
> 
> In the mean time I have just made a diff of the two specs and tried
> to look at the difference. The diff file is attached and is taken from NV_ to ARB_.
> 
> IMO the most important differences are:
> 1. The clamping for the *NV API entrypoints.
> 2. The different enum values for internal formats.
> 3. Clamping of fragment depths with is done in ARB and current GL standard
>    and avoided in NV.
> 4. Clamping of shader fragment depth outputs with is done in ARB and
>    current GL standard and avoided in NV.
> 5. Interactions with ARB_depth_buffer_float:
> <taken from NV_depth_buffer_float>
>     The ARB and NV internal formats for floating-point depth buffers
>     behave identically.  This extension optionally relaxes the clamping
>     behavior of ARB_depth_buffer_float when using the NV entry points.
>     If an ARB internal format is used to define a depth buffer, the
>     values passed to DepthRangedNV, ClearDepthdNV, and DepthBoundsdNV
>     are not clamped to [0,1].
> 
>     Additionally, querying DEPTH_BUFFER_FLOAT_MODE_NV is allowed on a
>     floating-point depth buffer created with an ARB internal format.
> 
> 
> Lets put this together from the spec side:
> 
> Point 1 and 2 are clear IMO.
> Point 5 contradicts somehow with 3 and 4 since the specified behavior
> in 3 and 4 makes a difference in clamping based on the used internal
> format enum. But I read in point 5 that there is no difference in these
> except that the NV api entry points don't clamp their arguments.
> 
> 
> The behavior of existing implementations:
> 
> Then there is an implementation in the wild which adheres to point 5.
> Means closed NVidia does not distinguish between the two differently
> speced behaviors of the internal formats and just treats them the same
> like their ARB counterparts, but additionally provides the entry points
> that don't clamp the input values.
> 
> 
> So, now my interpretation:
> 
> Initially there was the NV stuff, now there are floats in the depth buffer,
> so why clamp. Then, there were objections, clamping was reestablished
> and we got an extension that was widely accepted and that made it into the standard.
> So, people should use the new standard/ARB stuff which does what you need.
> Now, there is one thing missing in ARB/plain GL. You can get way better depth
> buffer resolutions for perspective projection if you would be able to get rid
> of the non zero bias in the view point transform. See
> https://urldefense.proofpoint.com/v1/url?u=http://outerra.blogspot.co.uk/2012/11/maximizing-depth-buffer-range-and.html&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0A&m=2tTODTa4rvJ%2B%2FSrSwNGYR%2Bd%2FKWVnaleYsFMGdIdu37s%3D%0A&s=4c90e35d13b7b4e15199119bfed21cabd7ec6748b82a073b5264a4c47a7dd070
> And you can achieve this using the NV_depth_buffer_float api entry points
> that do not clip their inputs. So, from the above I would think that the
> NV_depth_buffer_float variant is more or less superseded by the
> ARB_depth_buffer_float variant if the depth precision issue would be solvable
> without the NV api entry points. So, therefore and to cope with the conflicts,
> point 5 from above was probably added to NV_depth_buffer_float:
> Just use the now standard behavior like described in ARB_depth_buffer_float but
> additionally provide the *NV api entry points to get rid of the non zero bias.
> 
> BTW: That's one of the reasons of the ARB_clip_control's GL_ZERO_TO_ONE
> behavior - the above blog article is cited also in ARB_clip_control.
> 
> I may be biased because I am after the depth issue which is then solvable
> without larger problems and on a large base of GL implementations.
> We have a statement in NV_depth_buffer_float that was added close to the end
> of its history that tells that is behavior should not differ that much
> from ARB_depth_buffer_float.
> Additionally we find an existing implementation that behaves about this way.
> 
> I would vote for implementing that, which should be mostly what the current
> series implements.
> But if we want to model more of the subtle differences in the specs,
> I would need some directions which heading and how far to go.
> Alternatively, saying that we don't want to cope with this mess in mesa
> would be sad but an option.
> 


I agree it is something which would be nice to have in mesa, however I'm
not really a big proponent of implementing some half-baked bogus mess
extension, which is further more completely different to what the only
available implementation actually does.
Just to make this clear, are you saying that blob really clamps all
float depth values to [0,1] when
- using teximage2d
- writing depth from fragment shader
- using interpolated depth (with depth_clamp enabled maybe?)

So I think I'm missing something why can you even clear the depth buffer
to a value outside [0,1] then?

In any case, I'm not really against this, though I'm not really the
right person to judge this in any case. I think though at the very least
there should probably be big warning comments in the code mentioning it
doesn't actually implement what the extension says and why. It would
probably be better though if nvidia would fix up their extension spec
(or failing that, someone could make some proper non-vendor extension).
I wonder what AMD is doing on their blob. I suspect though they just do
the different non-clamping entry points...

(As a side note, doing clamping probably severely restricts the
usefulness of it for the purposes of d3d10 interoperation.)

Roland