[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 2/5] d3d9: Add depth clamp tests.
From:       Stefan_Dösinger <stefandoesinger () gmx ! at>
Date:       2010-01-26 19:21:55
Message-ID: 5C77B078-16A7-410A-A289-3B2A462A1F0A () gmx ! at
[Download RAW message or body]


Am 26.01.2010 um 19:23 schrieb Henri Verbeet:

> On 26 January 2010 18:56, Stefan Dösinger <stefandoesinger@gmx.at> wrote:
> > It would be interesting to see how D3DCMP_GREATER behaves with clipping off. Does \
> > the clamping occur before the depth test, or after the test but before writing \
> > the values into the depth buffer. (ie, is 3.0 > 1.0 or is 3.0 == 1.0) 
> It's not completely trivial to reliably test that due to precision
> differences between the vertex data and the depth buffer
Why? I'd expect that if you first draw something with depth clamping enabled with \
z=2(so it ends up at 1.0) then it really ends up at 1.0 and not 0.999998. If the Z \
buffer is cleared without drawing anything I'd expect it to contain an exact 1.0 as \
well. If there are precision problems in either situation I think the card/driver \
would be pretty broken.

> ARB_depth_buffer_float doesn't describe interactions with
> ARB_depth_clamp, which might imply we'll have to disable depth
> clamping for floating point depth buffers, but I doubt floating point
> depth buffers are particularly useful without shaders anyway.
Did you try depth clamping with shaders? Wrt vertex shaders I don't really expect \
surprises on either side, and wrt pixel shaders there are at least no surprises on \
the GL side(since we have that replacement pipeline and are using shaders anyway)


[prev in list] [next in list] [prev in thread] [next in thread]