[Piglit] [PATCH] hiz, new depth test
eric at anholt.net
Mon Nov 12 09:43:10 PST 2012
Tapani Pälli <tapani.palli at intel.com> writes:
> On 11/05/2012 10:09 PM, Chad Versace wrote:
>> On 11/05/2012 12:04 PM, Chad Versace wrote:
>>> On 10/31/2012 06:38 AM, Tapani Pälli wrote:
>>>> Here is a new test that tries to demonstrate failure with hiz code when
>>>> frambuffer depth and color do not match. This failure happens for example
>>>> with MESA_FORMAT_RGB565 color buffer and MESA_FORMAT_X8_Z24 depth buffer.
>>>> This test seems to fail, however my suggested fix does not make it pass
>>>> either so I am a bit puzzled if I am testing here the right thing. My
>>>> suggested fix was to not use fast depth clear in this case which produces
>>>> good visual results with test applications, however this piglit test does
>>>> not pass.
>>>> Any help appreciated;
>>> I suspect that the test failure may be unrelated to hiz. The failing probes are
>>> *color* probes. I've ran the test in non-auto mode, and, at least visually,
>>> the color at the failing probe points are correct.
>>> Maybe Piglit or Mesa is handling RGB565 incorrectly? I'm still looking into it.
>> I found it. Adding `piglit_set_tolerance_for_bits(5, 6, 5, 0)` to the top of
>> piglit_display() fixes the test.
>> On what gen do you expect the test to fail? It passes for me on Sandybridge.
> It fails for me on Ivybridge, this is platform where the original bug
> also occured where some of the apps do not render correctly on Android
> (only background color / solid fill is seen on the screen), what is
> common with these apps is the use of 16bit color buffer and 24 bit depth
> buffer. My following mesa patch fixes the issue in Android:
Are you saying that this testcase, with the set_tolerance fix, does fail
for you on ivb? It doesn't here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the Piglit