Re: [PATCHv5 3/3] d3d9/tests: Add tests for different YUV texture layouts

[Henri Verbeet]

On 13 February 2014 14:52, Martin Storsjo <martin(a)martin.st> wrote:
> +    IDirect3DSurface9 *surface = NULL, *target = NULL;
> You don't need those to be NULL.
> +    HRESULT color;
> You'll want to use D3DCOLOR instead of HRESULT here.
> +        /* Some (all?) Windows drivers do not support YUV 3D textures, only 2D surfaces in
> +         * StretchRect. Thus use StretchRect to draw the YUV surface onto the screen instead
> +         * of drawPrimitive. */
> +        if (IDirect3D9_CheckDeviceFormat(d3d, 0, D3DDEVTYPE_HAL, D3DFMT_X8R8G8B8, 0,
> +                D3DRTYPE_SURFACE, format) != D3D_OK)
> +        {
> +            skip("%s is not supported.\n", fmt_string);
> +            continue;
> +        }
> You should also verify the StretchRect() is supported with
> CheckDeviceFormatConversion().
> +                    BYTE Y = (color >> 16) & 0xff;
> +                    BYTE U = (color >>  8) & 0xff;
> +                    BYTE V = (color >>  0) & 0xff;
> It's probably just as easy to just store the separate components to begin with.
> +            hr = IDirect3DDevice9_StretchRect(device, surface, NULL, target, NULL, D3DTEXF_POINT);
> +            ok(hr == D3D_OK, "IDirect3DDevice9_StretchRect failed with %#x.\n", hr);
> +
> +            /* Native D3D can't resist filtering the YUY surface, even though we asked it not to
> +             * do so above. To prevent running into precision problems, read at points with some
> +             * margin within the rect. */
> That's not technically true, no filtering would be D3DTEXF_NONE. I
> don't know if that's going to make a difference in practice though.

[PATCHv5 3/3] d3d9/tests: Add tests for different YUV texture layouts

[Martin Storsjö]

On Fri, 14 Feb 2014, Henri Verbeet wrote:
> On 13 February 2014 14:52, Martin Storsjo <martin(a)martin.st> wrote:
> > +                    BYTE Y = (color >> 16) & 0xff;
> > +                    BYTE U = (color >>  8) & 0xff;
> > +                    BYTE V = (color >>  0) & 0xff;
> > It's probably just as easy to just store the separate components to begin with.

Actually, since color can either be test_data[i].color1 or 
test_data[i].color2, splitting it per component would blow it up into 
Y1/Y2, U1/U2, V1/V2, and duplicating the condition for selecting color 
based on coordinate for all three components, so I think this format is 
simpler in the end.
> > +            hr = IDirect3DDevice9_StretchRect(device, surface, NULL, target, NULL, D3DTEXF_POINT);
> > +            ok(hr == D3D_OK, "IDirect3DDevice9_StretchRect failed with %#x.\n", hr);
> > +
> > +            /* Native D3D can't resist filtering the YUY surface, even though we asked it not to
> > +             * do so above. To prevent running into precision problems, read at points with some
> > +             * margin within the rect. */
> > That's not technically true, no filtering would be D3DTEXF_NONE. I
> > don't know if that's going to make a difference in practice though.

I tested that now as well, and there's no difference, the sharp edges in 
the YUV texture are blurred when scaled up.

I applied the other changes you suggested, those changes will be part of 
the next resend of the patchset.

// Martin

[PATCHv5 3/3] d3d9/tests: Add tests for different YUV texture layouts

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2014-02-17 12:53, schrieb Martin Storsjö:
> On Fri, 14 Feb 2014, Henri Verbeet wrote:
> > That's not technically true, no filtering would be D3DTEXF_NONE. 
> > I don't know if that's going to make a difference in practice 
> > though.
>
> I tested that now as well, and there's no difference, the sharp 
> edges in the YUV texture are blurred when scaled up.
>
> I applied the other changes you suggested, those changes will be 
> part of the next resend of the patchset.
> D3DTEXF_NONE behaves like D3DTEXF_POINT if used for minification or
> magnification. It only has a different behavior when assigned to
> D3DSAMP_MIPFILTER. There is no way to do no min/mag filtering when the
> source surface / texture size doesn't exactly match the destination
> rectangle size.

In my yuv_color_test cleanup patch I have reworded the comment to
correctly say "point filtering" instead of "no filtering".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTAf3GAAoJEN0/YqbEcdMwCXsQAJVp53HiaKCXBce/OtaodwlL
axO2Pe8draccKUNupHDhTHtuXLcJV7uc3RV80VxN47h3sDchOFYz0j/H3hQZwuUo
0DrUWFCaLzGB3twpmyZq/zLgERizx6G5NVSMQJTIvAMmOzibJqHxgl+AHBWfmVGG
hdldw5fLSbQCpacpbrWpNZOiap0Bs24XTw7si4S8q25PrM89lm8XJKJROnFatloF
vvvtw2jbaWtzxQHoIt0y9SnZhDvpftJwDfPhN2jVDJnusuYAwZWTMtrQzHj/jUtI
KuK8mxWJUhjocmgv23Qh43S92zOBxRqkz76V0xrPLjIcCMyBoCCojBkahQa0gSbG
1i25pApi59KrnRJ/zUNAOtIDea81Iq71YOVwnC2E/EqpG+vbqYl8mBeKxybrZ8jU
S9JA+xsJL+ZFJ1NlTyU/KV4fweHgmerIaj12+XF3TeTR04L268EqDD2jIb14FTfy
msaeAyckR2emN5midcFCjUUIEG+t1CsWInfdI8Z1X2sQugBHZvxUEOWovXoTarHi
ji0cBNOEfEINtoNj7GIa7OdZsOkVncpUcI2ySTA9Ykb7cO25dYYk4hSmobE/Pvun
KaeSsVvXALLfRraXg7cQnTg8Befx+gIZuvyYSK7MENe1S2F8fR257X5lrNXS3djE
MEdB/nivZnLkSq4dk39D
=gluy
-----END PGP SIGNATURE-----