[PATCH 02/11] ddraw/tests: Do not mark alternative results as broken in test_rt_caps() for ddraw7.

[Paul Gofman]

On 3/5/21 21:36, Henri Verbeet wrote:
> On Wed, 3 Mar 2021 at 23:36, Paul Gofman <pgofman at codeweavers.com> wrote:
>> @@ -6419,10 +6419,8 @@ static void test_rt_caps(const GUID *device_guid)
>>              expected_caps = test_data[i].caps_out[software_device]
>>                      ? test_data[i].caps_out[software_device] : test_data[i].caps_out[0];
>>
>> -            todo_wine_if(test_data[i].caps_out[software_device]
>> -                    && surface_desc.ddsCaps.dwCaps == test_data[i].caps_out[0])
>>              ok(surface_desc.ddsCaps.dwCaps == expected_caps
>> -                    || broken(surface_desc.ddsCaps.dwCaps == test_data[i].caps_out[0]),
>> +                    || surface_desc.ddsCaps.dwCaps == test_data[i].caps_out[0],
>>                      "Got unexpected caps %#x, test %u, software_device %u.\n",
>>                      surface_desc.ddsCaps.dwCaps, i, software_device);
>>          }
> Does that mean we want Wine to return these alternative results in
> some conditions? I.e., more than making a judgement about what's right
> and proper, broken() distinguishes results we want want Wine to return
> from results we don't want Wine to return. If yes, under what
> conditions do we want Wine to return these?

I think I just marked these results as broken by mistake previously when
was extending this test for software devices. The surface output caps is
not directly influenced by the device type as surface is created before
the device. Why adding the software device test changed anything at all
here are the Z buffer selection. It was just failing previously with no
3d device present all the tests were skipped (now it doesn't when run
for software device from which the Z buffer format is selected). Then,
supported Z buffers formats may be different between software and
hardware device. The general rules for output device caps when no
explicit video or system memory are requested here are:

- if there is no hardware device at all, sysmem surface will be used;

- if there is a hardware device and surface format is supported by it
the surface will be created in video memory;

- if the format is not supported (happens with _P8 formats in this test
on most GPUs with the exception of at least AMD Evergreen) the surface
will be created in system memory.

So I think marking 'surface_desc.ddsCaps.dwCaps ==
test_data[i].caps_out[0]' as broken and todo_wine as I did initially is
just wrong, it is actually the default case when hardware device is
present. And it wasn't mark as such for other ddraw versions tests.

So Wine returns the video memory here (previously marked as broken in
ddraw7) all the time except for _P8 format, which seems to match the
most typical behaviour on Windows.

>From your comment to patch 03/11:

> Somewhat similar to 02/11, I'd expect the video memory variants if the
ddraw implementation supports video memory surfaces, and the system
memory variants if not.

Yes, this is the case as far as I could see, with the exception of
formats not supported by the hardware device.