Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-11 12:14, schrieb Martin Storsjo:
+ hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 8, 8, format, D3DPOOL_DEFAULT, &surface, NULL); + ok(hr == D3D_OK, "IDirect3DDevice9_CreateOffscreenPlainSurface failed, hr = %08x\n", hr); Please use a non power of two size and skip the test if D3DPTEXTURECAPS_POW2 is set and D3DPTEXTURECAPS_NONPOW2CONDITIONAL is not set. That should avoid another regression in the np2 code.
There's a decent chance that StretchRect from a plain np2 surface works even if NP2 textures are completely unsupported, but it will be rather hard to find a Windows machine to confirm this.
+ memset(&lr, 0, sizeof(lr)); + hr = IDirect3DSurface9_LockRect(surface, &lr, NULL, 0); + ok(hr == D3D_OK, "IDirect3DSurface9_LockRect failed, hr = %08x\n", hr); There's no need to memset lr to 0. We know LockRect returns a properly initialized structure if it succeeds.
+ switch (format) + { + case D3DFMT_YV12: v_buf = chroma_buf; u_buf = chroma_buf + 4 * lr.Pitch/2; break; + case D3DFMT_I420: u_buf = chroma_buf; v_buf = chroma_buf + 4 * lr.Pitch/2; break; + default: break; + } The switch causes a warning here because YV12 and I420 are not part of the D3DFORMAT enum. Please use an if to make the compiler happy. Set v_buf and u_buf to NULL in case of other formats - this should avoid the warning that they may be uninitialized. (Although I think the compiler is broken here. It should see that they're not used for formats that are not YV12 and I420.)
+ /* Draw the top left quarter of the screen with color1, the rest with color2 */ + for (y = 0; y < 8; y++) + { + for (x = 0; x < 8; x += 2) + { + DWORD color = (x < 4 && y < 4) ? test_data[i].color1 : test_data[i].color2; + BYTE Y = (color >> 16) & 0xff; It would be nice to use different values for the two Y channels, unless this makes reading the result too difficult with filtering on.
+ hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET | D3DCLEAR_ZBUFFER, 0x00000000, 1.0f, 0); No need to clear the Z buffer.
+ ok(hr == D3D_OK, "IDirect3DDevice9_StretchRect failed with 0x%08x\n", hr); Please use %#x instead of 0x%08x and add interpunctuation at the end of the ok message. Another set of unwritten style rules :-\ .
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+5B8AAoJEN0/YqbEcdMwgLUP/19EoAQNiOg0JTdAHco28fTm zfSqZtMTv7JJAtznqt5EilK2gb33/oiyMXZcotg6YevJWRFrVQQw9K3b+JepxY4O l8ZBas9GGEAoTppb4W03w7Ngzr5J4yBBSXpVoEQDnmztywzZqcpaQc4y1/ukkkgg lN7HIPP3tychxk3IBiQtgVQ/U+xC6BmEgWdNClDBBpMnGkKbLERLjxpkOPi7fs1f FPOCW7P18BDLANw/FMipEqDsm+K/EOdVFBU4wcIWB7BOavZzwGRaKDFdifhwq2VR CBvm3uT6drct5put/JF/RIfnY5Za7GOIi5Ks4P0Gwt/e6xQ3WK+LrsEAASottF0O IUskCxGIKB/P7CsxtwGjTg9gDOm35W+4g0QiMvBoJk8dO2eggPXdNdmAR+5ZI/ez wxZzAl9m8VnXe0xeUSMha44n7F3EJ8Bz7F/Sixc6v8G6pmVdJNK9LM8+ZqD4muWQ cnZNKWLMeWaufb3KEVno0F2SUFhGb7q/FHBCInaz9EKOG5yMEEzNbHYMh3v/oJ9s IWXJgavdbIfUbj1YGulasKqlNzHzKnL+V2oMaqT+rGxypAcVentxIbV/bFseN091 b6oc8bL9KIKEHpWtPKqXYJ3wZBb2dKbcFhmd2VDNrWQSOTI5ZeU5xUnfsXeIthqo ntdGlkDSfAJlSMvzZOyh =m68B -----END PGP SIGNATURE-----
On Wed, 12 Feb 2014, Stefan Dösinger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-02-11 12:14, schrieb Martin Storsjo:
+ hr = IDirect3DDevice9_CreateOffscreenPlainSurface(device, 8, 8, format, D3DPOOL_DEFAULT, &surface, NULL); + ok(hr == D3D_OK, "IDirect3DDevice9_CreateOffscreenPlainSurface failed, hr = %08x\n", hr); Please use a non power of two size and skip the test if D3DPTEXTURECAPS_POW2 is set and D3DPTEXTURECAPS_NONPOW2CONDITIONAL is not set. That should avoid another regression in the np2 code.
Indeed, I changed the texture size later yesterday (and removed the hardcoded numbers by making the width/height a local variable); will check that capability.
There's a decent chance that StretchRect from a plain np2 surface works even if NP2 textures are completely unsupported, but it will be rather hard to find a Windows machine to confirm this.
Yeah, it's probably not worth worrying about that case.
+ memset(&lr, 0, sizeof(lr)); + hr = IDirect3DSurface9_LockRect(surface, &lr, NULL, 0); + ok(hr == D3D_OK, "IDirect3DSurface9_LockRect failed, hr = %08x\n", hr); There's no need to memset lr to 0. We know LockRect returns a properly initialized structure if it succeeds.
Ok - this was an artifact from the existing yuv_color test FWIW.
+ /* Draw the top left quarter of the screen with color1, the rest with color2 */ + for (y = 0; y < 8; y++) + { + for (x = 0; x < 8; x += 2) + { + DWORD color = (x < 4 && y < 4) ? test_data[i].color1 : test_data[i].color2; + BYTE Y = (color >> 16) & 0xff; It would be nice to use different values for the two Y channels, unless this makes reading the result too difficult with filtering on.
I guess it would make things a little bit more difficult when the output is filtered. As long as we calculate how to hit the center of the pixels correctly I guess it should work, but I went the easy route and just draw the top-left quarter of the screen in one color and the rest in another, and sample at four points near the corners of each quadrant. Handling the individual two different Y values in UYVY/YUY2 is already tested in the yuv_color test anyway, and for the other pixel formats there isn't really any distinction between first/second Y samples. I'll fix up the other style issues you pointed out and resend the set later today then. // Martin
participants (2)
-
Martin Storsjö -
Stefan Dösinger