Re: [PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 4)

[Henri Verbeet]

On 14 May 2014 16:12, Matteo Bruni <mbruni(a)codeweavers.com> wrote:
> ---
>  dlls/d3d9/tests/device.c | 133 ++++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 107 insertions(+), 26 deletions(-)

Unfortunately this still fails for me on Windows. The returned counts
change between runs, which could perhaps be related to the backbuffer
size being larger than the window size. It does seem to reliably pass
when either running the test in fullscreen mode, or changing the
backbuffer size to e.g. 640x480. The former is probably the easier
fix.
> +    ok(data.word[0] == (WORD)expected || broken(!data.word[0]),
> +            "Occlusion query returned an unexpected result (0x%.8x).\n", data.dword[0]);
> +    if (!data.word[0])
> +    {
> +        skip("Occlusion query result looks broken, ignoring returned count.\n");
> +        broken_occlusion = TRUE;
> +    }
> At 1024x768 for example, "expected" is going to be 0xc0000. Is this
> for drivers that always return 0 for occlusion queries, or is this for
> the testbot, which IIRC runs at the resolution? If it's really broken,
> I think this should also check for "(WORD)expected" being 0, and then
> use win_skip() instead of skip().

[PATCH 1/5] d3d9/tests: Test GetData behavior with various size values. (try 4)

[Matteo Bruni]

2014-05-14 17:06 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>:
> On 14 May 2014 16:12, Matteo Bruni <mbruni(a)codeweavers.com> wrote:
> > ---
> >  dlls/d3d9/tests/device.c | 133 ++++++++++++++++++++++++++++++++++++++---------
> >  1 file changed, 107 insertions(+), 26 deletions(-)
>
> Unfortunately this still fails for me on Windows. The returned counts
> change between runs, which could perhaps be related to the backbuffer
> size being larger than the window size. It does seem to reliably pass
> when either running the test in fullscreen mode, or changing the
> backbuffer size to e.g. 640x480. The former is probably the easier
> fix.

Okay, going for fullscreen.
> > +    ok(data.word[0] == (WORD)expected || broken(!data.word[0]),
> > +            "Occlusion query returned an unexpected result (0x%.8x).\n", data.dword[0]);
> > +    if (!data.word[0])
> > +    {
> > +        skip("Occlusion query result looks broken, ignoring returned count.\n");
> > +        broken_occlusion = TRUE;
> > +    }
> > At 1024x768 for example, "expected" is going to be 0xc0000. Is this
> > for drivers that always return 0 for occlusion queries, or is this for
> > the testbot, which IIRC runs at the resolution? If it's really broken,
> > I think this should also check for "(WORD)expected" being 0, and then
> > use win_skip() instead of skip().

It's for the testbot, which AFAICS returns 0 regardless of the
resolution or fullscreen / windowed mode. I haven't seen other D3D
drivers claiming to support occlusion queries and then returning 0
yet.
It's a bit unfortunate that 0 is actually the expected result there
for 1024x768. I think I'll move the test checking the entire DWORD
first and set the broken_occlusion flag based on that. I should
definitely use win_skip though.