On 25 October 2013 00:47, Stefan Dösinger stefan@codeweavers.com wrote:
dlls/ddraw/tests/ddraw2.c | 26 ++++++++++++++++++++++++-- dlls/ddraw/tests/ddraw7.c | 27 ++++++++++++++++++++++++--- 2 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/dlls/ddraw/tests/ddraw2.c b/dlls/ddraw/tests/ddraw2.c index f4702f1..801135d 100644 --- a/dlls/ddraw/tests/ddraw2.c +++ b/dlls/ddraw/tests/ddraw2.c @@ -3663,6 +3663,7 @@ static void test_rt_caps(void) DWORD caps_out; HRESULT create_device_hr; HRESULT set_rt_hr;
HRESULT alternative_set_rt_hr;
This kind of construction doesn't generally make me very happy, but on the other hand I'm not sure I can come up with something that's much better either. I do think we should mark the alternative results as broken. Some of the Evergreen results in later patches in this series are a bit surprising to me. I wrote the test on Windows 7 / AMD Cayman, which should be very close to Evergreen hardware.
Am 25.10.2013 um 14:12 schrieb Henri Verbeet hverbeet@gmail.com:
This kind of construction doesn't generally make me very happy, but on the other hand I'm not sure I can come up with something that's much better either. I do think we should mark the alternative results as broken. Some of the Evergreen results in later patches in this series are a bit surprising to me. I wrote the test on Windows 7 / AMD Cayman, which should be very close to Evergreen hardware.
I was thinking about marking some of those results broken, but in the end I couldn't find an argument why the results from GPU A are more correct than the results from GPU B, especially when considering that the differences between ddraw versions on the same GPU are just as big and strange as the differences between GPUs.
On 25 October 2013 17:09, Stefan Dösinger stefandoesinger@gmail.com wrote:
I was thinking about marking some of those results broken, but in the end I couldn't find an argument why the results from GPU A are more correct than the results from GPU B, especially when considering that the differences between ddraw versions on the same GPU are just as big and strange as the differences between GPUs.
Yeah, but broken() is really more about what behaviour we want Wine to follow as opposed to some judgment about what's correct. I think it makes sense to try to be somewhat consistent there. Obviously that doesn't apply for things that depend on e.g. the hardware implementation, but this is for things that are purely in our ddraw/wined3d implementation.
-
Henri Verbeet -
Stefan Dösinger