On 3/5/21 21:36, Henri Verbeet wrote:
On Wed, 3 Mar 2021 at 23:36, Paul Gofman pgofman@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.