February 2014 - Wine-Devel - list.winehq.org

Re: [PATCH 5/6] wined3d: Add support for I420 textures

by Martin Storsjö

On Wed, 12 Feb 2014, Stefan Dösinger wrote: > Am 2014-02-11 12:14, schrieb Martin Storsjo: >> I420 is similar to YV12, but the chroma planes are swapped. > Do you have an application that uses this? Just making sure we're not > adding dead code here. Actually I don't. I first ran into this area with the OpenH264 test decoding application, which currently uses NV12 textures. Once I started adding support for that to wine, I also tested what other common YUV pixel formats actual hardware supports (I tested on a friend's physical windows machine), which wine doesn't, and found that the real windows machine also supported I420 but not e.g. NV21, in addition to YV12, UYVY and YUY2 which already were supported. I can easily change the above mentioned test app to use I420, which works both on the physical windows machine and in wine with this patch, but I can't name any other app off-hand which would use this format. So if you prefer to hold off adding support for this format until there's a concrete need, I can drop this one. // Martin

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----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-----

Feb. 12, 2014

Re: [PATCH 5/6] wined3d: Add support for I420 textures

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-11 12:14, schrieb Martin Storsjo: > I420 is similar to YV12, but the chroma planes are swapped. Do you have an application that uses this? Just making sure we're not adding dead code here. Otherwise this looks good, but patch 3 needs fixes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+4lrAAoJEN0/YqbEcdMwDjUP/1mawzD6WIoBsR/eFxSDu2SZ yE4AHd/HaUkYwYan6CjiYAV8uf3ikUIGHQhvyF79jKikRWUCGHRoQTL8xwx6wcXm fCIQjPuuwpizEpdGjD+mZHWMgg+RtgbYrJbSX8pWtRfcRQsVxtB8Q5tXyVtZGwWr vBtmeQUlaIBlSH8hG5ZC0UGsljP/hwV/LayeYmAKFRTccX/PFKTM1cua5AznPrxQ noEW9kYxpilWDPwvNWsic7e6FCYTHxMGZblVC5FSMxSq/66CAYUakD1iRc4xomw7 9jk0UQ308LKTzw7m86HfvnuqvIHprhZcn1IHwDWAmGxsQD+e+4uJ8XBwAKA575Sm RUQMDZdXzsxmBkZIYGDs7WNI03v6rEsGaM3KoHuurfhmc7XaCjzla0W3Y0yLgN4P 9+7WHzBZ8CyYDBHsNKNkFpXEwQuSzAbzr+nt8/8RhrwHyIa2RX26xCe91+6MYKkc trwK1inGiB3CBvzEha/YQuGzeyzTp8oV6yhGnGpf5tPJlRtzxc8IpHmWXCdwrk6z 3AAxUliwm4cYTPgrY2zAXHc/0rTULQ+3GCUb3pWGgdKCDzmyWsPaZ5TY0XmBGvIH R9JrC39ku/Md33+oWCKF4tpwzJ1go6eWnbBu/mPKStpoTaIi708H/vrTCmL/dHCp aYOYafddUXk5NKEcS91m =dZNW -----END PGP SIGNATURE-----

Feb. 12, 2014

Strange behavior from native OpenGL

by Ken Thomases

Hi, I have been working on refining a d3d9 test patch I recently submitted <http://source.winehq.org/patches/data/102263> and noticed a strange behavior when running on a real Windows machine. I'm wondering if anybody is familiar with it or can check my reasoning. The strange behavior is that a failed call to wglCreateContext() must be done before SetPixelFormat() will work properly. The call to wglCreateContext() has to fail because it can't succeed until SetPixelFormat() has been done. And yet it still seems to be necessary. My test does the following sequence: CreateWindowA() GetDC() ChoosePixelFormat() SetPixelFormat() GetPixelFormat() This seems fairly simple, straightforward, and commonplace. Although everything through the SetPixelFormat() indicates success, the GetPixelFormat() call still returns 0. This causes the test to be skipped. This happened on the testbot, but I assumed that was caused by the VM's display driver. However, when I got the chance to try on a real Windows machine, it happened there, too. I looked around to see if the same sort of thing is done elsewhere in Wine. It's done in the opengl32 tests in test_setpixelformat() <http://source.winehq.org/source/dlls/opengl32/tests/opengl.c#L254> and it works there, both on the testbot and the Windows machine. So, then I figured it must be working in those tests because of stuff that is done beforehand. I disabled most of the opengl32 tests other than test_setpixelformat(). That was testbot job <https://newtestbot.winehq.org/JobDetails.pl?Key=4751> and it still passed on the testbot and real Windows. I then disabled the expected-to-fail call to wglCreateContext() that is done in the test main entry function (START_TEST(opengl)). Once that is disabled, test_setpixelformat() starts failing in the same way as my d3d9 test. That is testbot job <https://newtestbot.winehq.org/JobDetails.pl?Key=4752>. So, can it really be that a failed call to wglCreateContext() is necessary before SetPixelFormat() will work properly? One thing that I haven't had the chance to test yet is whether a wglCreateContext() call _after_ SetPixelFormat() will cause a subsequent GetPixelFormat() to return the right format. That is, perhaps SetPixelFormat() has worked and the pixel format is remembered, but it's only "realized" once wglCreateContext() is called. And GetPixelFormat() only returns realized pixel formats. Also, it's possible that it's sufficient to call any opengl32 function and not wglCreateContext() specifically. (ChoosePixelFormat(), SetPixelFormat(), and GetPixelFormat() are gdi32 functions.) In any case, that would mean that my d3d9 test will have to link with opengl32 and call one of its functions. -Ken

Feb. 12, 2014

Re: [PATCH 4/6] wined3d: Fix the YV12 illustration

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-11 12:14, schrieb Martin Storsjo: > The comment in the description further above is correct, that the > chroma planes are ordered V, then U, while the illustration had > them swapped. This patch looks correct to me. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+4czAAoJEN0/YqbEcdMwKx8P/1J1flCobX1Z3XHptyIlEuyC gVt1OwxjQ2ayx5WwTtO8wlY//h+167HE4Ip7KFxk3QR21PKO/kvmhImmjVr2oUdm t8ZDh3q3158qSu1USNvKfTzLaBpXbXQNs10XIgvj2olHw80+CW0ZodPONAls94dU YHVAmYataxvTMkM/EXooBVJkJdF0qy80pkAcQLpN+wwpw+xZXwXq0901bm2u2LJn XuN9UDS9lViR2NRSNUkHhJKNKJiy72U6RXnKsjao83IES27zFKCpaJx8UeyvRCQY ZGCREFf4Xw9ge+Bi2tA5zfCeClVVZ5ds2gSbTvGmy7DAcjYCG4z7iYwWaUOWduH/ OGW9ASPdqvRTELjqB40x1hvtdhhFFjC2PI+UbS1ltiIpgHUQn2FZcG9qsOh1QaDt ddtyOc1cKazeE4iFFdDfNy9cJTg8n0bKAEFAfj/tUsKJjoDfbOyF0xeEsECs6MVt ayaEWUduLTD/hHq7kA/U8vzGmucJ7Ng7XvypLu3vKbH76f63e4nuUWfc8K2VpAXK SRoLvhePgmUkXkus+Y3l3ttAvN/y+HhKZiNvFIxQKUfZ07mg4gqhM1DzwO0/9Gdt byo+Nu0bK9arSyJUCi7Ah+fcBvJUCAvt47xQ1AnUvv2/2sOUfWcPxSERX4WLFPRG /RSNua7b9MRvibHxXC1G =rFkd -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: [PATCH v2 1/6] wined3d: Add support for NV12 textures

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi again! I have some more format nitpicks below. As far as the big picture is concerned there is also a software conversion path in dlls/wined3d/surface.c. Search the file for d3dfmt_converter_desc and you should find the right place. You don't have to submit a patch for that unless you know an application that needs it though; I'm just making you aware of it. Am 2014-02-11 12:14, schrieb Martin Storsjo: > + switch(textype) You're missing a space here. As far as I can see the other places in this patch are correct, but it doesn't hurt to double-check with grep or something. (I really hope the testbot can one day take care of this...) > + case GL_TEXTURE_2D: tex = "2D"; break; Please make this case GL_TEXTURE_2D: tex = "2D"; break; etc > + * When reading from rectangle textures, keep in mind that > the input y coordinates + * go from 0 to d3d_height, whereas > the opengl texture height is 1.5 * d3d_height + */ Comment closing should go next to the last line of text. Also add proper interpunctuation at the last sentence of a comment. This applies to a few more places in this patch, and most likely the other patches. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+4aPAAoJEN0/YqbEcdMwCXMQAIPeaYbrI+zC2zf6KlOdOCbe yDSbSvRS4vZWkukemQCb6jr2qFCjqoCJMHj1GpfWxlBxJ1+rOWyTdc+YG2DDzCqk YE3K8PgOaID7BnopA/Ri0gYiwRz7K2WBpMWMwgeVnjTFOUWJ8tYt1z4VmCHXgEEi JDphv1q9IDzCW/s3Pu68VtDrE4rsG/KLietRPTCgakdjX1oLvlKn1Fg5D7q78y87 szJg2SRaYOVWSXIK2D+s+A5Tvjr9gffSsDE6fgFgxeFyHsViGyq6QDJEBxCO+f+A UZ1FhidcogIt/sqSphg7lCyEUw49WojlXSXhLpdofwjrR/4griYgp21h6Y8UhtqG LzPUVGBfScvb208bIhL+LvCukQ00WnTI4LJA6khjL9AlCnrzh4nrhVo6RQDrL1A3 6V5gJLd1ZT4DepQc2XQLC0FupgYWafIJAzCcpZIpvQRjzH4MqJgeJC9m6alRzyWr TkN+Jo6yKRk2t+x7LOzee+mMPAfIT2OcHoIlG60Z8ZxK3Apu6k7/RPoqi1BWdJZZ gHA1CZLUDC+UXhPhr2pxNy4AQnD2EbIBp5GPKNHHvoqJJzXvbHPBx5TgOOaEyLnH idubGx+GLf3zXEaK+ujbMg8Ae/poGh841gBVbMLDqZguSkuTsVGpt8hjCZgWq+5d u177zpoEIMhOFIK17nSY =IHTQ -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-12 15:05, schrieb Martin Storsjö: > Anyway, I'll resend my patchset with the last fixes from > yesterday. Before you do I'll have a closer look at the stuff I didn't look at yesterday. It shouldn't take long... -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+4K8AAoJEN0/YqbEcdMw7VwP/R4pK5DjZ6Edi4kuwU4+PFty r8y6bsNih1pdedxpU4hMFsWRSqv1ZTlpth7vQ48tQIsDaBaw7kI509g94twmAhiB XFwQxIuefiZdd0BiHt/kS9354vZ3ftpCcrjI51DRERyTHl0EPnTMtKNRpLNPeDg2 W2k/oFJpOjqDTqucqeqdj7r52ORaIXy29DqJhfRoho0rQNLFOoGAgSsB48ZggWqo PhGQZPQKFuCMXCdjsLrMv9nq2eIMgS4j+wy5BJISGjqZzVWjzEZ4uweCeb1GO8BL aQwbUmNPxwQD+C5ElIYSX1dhpailinplr0wCITn0MkDHdGXwWP/Z9G8o2Iv3zFRF 9iBIU1xGJkg7gkK1jI2oyONb/v+qJtUqAf4Pys4zoTUxEzTE7Jpuytm/u6PQOVW8 3X4rEK56YQrzWrlP9vNRwWj1BixUiEfGawL28qjBa66xWpLvZxROK0lckA72Si6X XU7LwGGNFh6YkKCSvZHli3/RGTjfKaYF0asCiUqlfyAHuXhtNYe2pth5cEf+S1zR xH/m0xMBP97me3HgxMYbCcPTCueZVdr4o7sje1kRzmaM1+2t8NKSuKzbzLdqlio+ yxBBAnmvuFzXF7ZyNLGQZ7RFkvl1XB5vAFzhFkcfdz2Q6cUNikLv8hSEbnRPZLpI n+zzBnN4VvZa7FfsXldK =EPpG -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-02-12 15:05, schrieb Martin Storsjö: > I didn't really test my test properly on windows yet - how hard is > it on a scale to compile and run them there? It's not all that hard. You have 3 options: Install mingw on your linux system to cross-compile the tests with make crosstest. I've installed i686-w64-mingw32-gcc for 32 bit compiles and x86_64-pc-mingw32-gcc for 64 bit ones with Gentoo's tools. (I should probably switch the 64 bit one to mingw-w64 as well...) The other option is to install mingw and msys on Windows and compile it there. That's a bit trickier. The third option is to create an account at testbot.winehq.org. It'll allow you to upload patches and give you a cross-compiled .exe. Actually, there's a fourth option: I have a hacky visual studio build system for the d3d parts of Wine. Tell me if you're interested and I'll write more instructions. You'll need msvc 2013 and it will most likely not work out of the box. > I only tested it briefly (by ripping out the relevant parts from > visual.c and compiling that as a standalone C file without the wine > test framework) on windows so far, on a VMware VM with XP, and the > direct3d driver there doesn't support either NV12, YV12 nor I420, > only UYVY/YUY2 (this is actually my original reason for trying > anything of this in wine). Ok, I'll run your tests on my Windows boxes then. I've plenty of them for this purpose... > The D3D rendering did seem to filter the texture when stretching > though, but I chose sampling points within it that should resolve > to the right color despite that. That seems to be a common problem with YUV stretchrect. I'm using the same workaround in the YUY2 / UYVY tests. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS+4HmAAoJEN0/YqbEcdMwSi4P/0hwyFkF298blerxDwl53km+ TIL82HBqlBV/JtOWDzIod+XnXUsEGDuz+mbRcDhmEbvEgEjtU0ziO+wT8MaQu14x YqfSLww1eURQGXcEpTOHmG8CVxbGrIu9CUF/DhfQEbAK34PQvGRUTt23R7DlWmII HzgXolMTGhIs387sqb7sTutECxsRVMAedhuO+eN4iaPKz9OFH+zoIUVeHiDn/2Kh 5hriL6L8f+y9tU7GUST0eiKbBPX74tooHeLKQtYh8rPkZQonXXVSIGMbzrYGGnaz hWkC9tZ122QhrqnJio3t5aPUWPWZ34Y/mxCTA0chmGOAw0bbDXLn+VRpFGHIIbX/ oWF9spjhyO3u0dBbMSfvEnQtU2vdp3cHu6TyQ2ObLiNHESdGq+t4HPo19hhmohOO cNiRqWDzfO5NizVDgyTyoHxq0IpVXWy/czaZ0KHI7fBlixj77/doQGj5+l70Lmxp KTnnzR1UpOoQnZL9YsnGy8VlzUU0gdMOHTnhZ7FIA+LI2VpeuPvRcCd/Awbxdyni SAIrnGDP2b14+M/Vxj092/VFNAQojUlyjfg7Y5lGkFs6tuhLUF+E9Hn7mPjAgYmo qLKZ/k3XwwBRzMEz1Wm5NVFEmmzKTjIXomNsdAy7uBiP27VW77JhKeb2HF5FmwBf H5jQwN86JTAdWTQe1VSX =8wrY -----END PGP SIGNATURE-----

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Martin Storsjö

On Wed, 12 Feb 2014, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-02-11 14:23, schrieb Martin Storsjö: >> Yes - now I extended the test to use a non-power-of-two texture >> size, and if I hack out the ARB_TEXTURE_NON_POWER_OF_TWO support >> (in wined3d/directx.c) the tests fail and crash. > Alright, I guess I should have a look at it. > > On which Windows systems(Windows version, GPU) did you test your test? > I know that there are plenty of differences in YUV handling, so I'd > like to run the tests on some of my Windows installations too. I didn't really test my test properly on windows yet - how hard is it on a scale to compile and run them there? I only tested it briefly (by ripping out the relevant parts from visual.c and compiling that as a standalone C file without the wine test framework) on windows so far, on a VMware VM with XP, and the direct3d driver there doesn't support either NV12, YV12 nor I420, only UYVY/YUY2 (this is actually my original reason for trying anything of this in wine). The D3D rendering did seem to filter the texture when stretching though, but I chose sampling points within it that should resolve to the right color despite that. So unfortunately I'm not sure how much more I can test it on actual windows... Anyway, I'll resend my patchset with the last fixes from yesterday. // Martin

Feb. 12, 2014

Re: [PATCH 6/6] d3d9/tests: Add tests for different YUV texture layouts

by Martin Storsjö

On Wed, 12 Feb 2014, Stefan Dösinger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I sent two patches that should get rid of the texture_rectangle crashes. Indeed, things seem to work fine now, and my YUV layout tests do succeed with ARB_TEXTURE_NON_POWER_OF_TWO disabled. Thanks for the prompt fix! // Martin

Feb. 12, 2014