Am 11.02.2014 um 12:14 schrieb Martin Storsjo martin@martin.st:
+#define D3DFMT_YV12 MAKEFOURCC('Y','V','1','2') +#define D3DFMT_I420 MAKEFOURCC('I','4','2','0') +#define D3DFMT_NV12 MAKEFOURCC('N','V','1','2’)
There’s no need for global definitions. Other tests that use custom fourccs just use MAKEFOURCC in their code.
- struct
- {
DWORD color1, color2;DWORD rgb1, rgb2;- }
- test_data[] =
- {
{ 0x000000, 0xffffff, 0x00008800, 0x00ff7dff },{ 0xff0000, 0x00ffff, 0x004aff14, 0x00b800ee },{ 0x00ff00, 0xff00ff, 0x000024ee, 0x00ffe114 },{ 0x0000ff, 0xffff00, 0x00b80000, 0x004affff },{ 0xffff00, 0x0000ff, 0x004affff, 0x00b80000 },{ 0xff00ff, 0x00ff00, 0x00ffe114, 0x000024ee },{ 0x00ffff, 0xff0000, 0x00b800ee, 0x004aff14 },{ 0xffffff, 0x000000, 0x00ff7dff, 0x00008800 },- };
Please make this static const. The same applies to the formats[] table.
I’ll look at the details of the test and the other patches later today, when my headache is gone :-\ .
Oh, by the way: Were you able to test the texture rectangle codepath with your test?
Am 11.02.2014 um 13:13 schrieb Stefan Dösinger stefandoesinger@gmail.com:
Am 11.02.2014 um 12:14 schrieb Martin Storsjo martin@martin.st:
+#define D3DFMT_YV12 MAKEFOURCC('Y','V','1','2') +#define D3DFMT_I420 MAKEFOURCC('I','4','2','0') +#define D3DFMT_NV12 MAKEFOURCC('N','V','1','2’)
There’s no need for global definitions. Other tests that use custom fourccs just use MAKEFOURCC in their code.
- struct
- {
DWORD color1, color2;DWORD rgb1, rgb2;- }
- test_data[] =
- {
{ 0x000000, 0xffffff, 0x00008800, 0x00ff7dff },{ 0xff0000, 0x00ffff, 0x004aff14, 0x00b800ee },{ 0x00ff00, 0xff00ff, 0x000024ee, 0x00ffe114 },{ 0x0000ff, 0xffff00, 0x00b80000, 0x004affff },{ 0xffff00, 0x0000ff, 0x004affff, 0x00b80000 },{ 0xff00ff, 0x00ff00, 0x00ffe114, 0x000024ee },{ 0x00ffff, 0xff0000, 0x00b800ee, 0x004aff14 },{ 0xffffff, 0x000000, 0x00ff7dff, 0x00008800 },- };
Please make this static const. The same applies to the formats[] table.
I’ll look at the details of the test and the other patches later today, when my headache is gone :-\ .
On Tue, 11 Feb 2014, Stefan Dösinger wrote:
Oh, by the way: Were you able to test the texture rectangle codepath with your test?
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.
// Martin
-----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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-02-12 11:20, schrieb Stefan Dösinger:
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.
It looks like I screwed up heightscale handling with my recent surface memory management rework. YUY2 and UYVY are regular block-based formats, but YV12, NV12 and I420 are not.
The block-based properties of those 3 formats (or lack thereof) could use some tests as well. I think I didn't test YV12 when I wrote / updated test_surface_blocks and test_volume_blocks in dlls/d3d9/tests/device.c because none of my cards supported it in d3d9. Maybe that's different with I420 and NV12 - I haven't checked on Windows yet.
Ddraw has some YV12 tests in dlls/ddraw/tests/overlay.c. It shows that this format does not use a block-based offset calculation.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I sent two patches that should get rid of the texture_rectangle crashes.
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
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
-----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 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...
-
Martin Storsjö -
Stefan Dösinger