Re: [PATCHv5 3/3] d3d9/tests: Add tests for different YUV texture layouts
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.
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
-----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-----
participants (3)
-
Henri Verbeet -
Martin Storsjö -
Stefan Dösinger