Re: [PATCH 2/4] d3d9/tests: Avoid mode changes in d3d9ex' test_lost_device.
Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=9532 Your paranoid android. === w8 (32 bit d3d9ex) === d3d9ex.c:1276: Test failed: Got unexpected hr 0. d3d9ex.c:1278: Test failed: Got unexpected hr 0. d3d9ex.c:1280: Test failed: Got unexpected hr 0. d3d9ex.c:1282: Test failed: Got unexpected hr 0.
On 15 October 2014 00:26, Marvin <testbot(a)winehq.org> wrote:
=== w8 (32 bit d3d9ex) === d3d9ex.c:1276: Test failed: Got unexpected hr 0. d3d9ex.c:1278: Test failed: Got unexpected hr 0. d3d9ex.c:1280: Test failed: Got unexpected hr 0. d3d9ex.c:1282: Test failed: Got unexpected hr 0.
If you really wanted to avoid mode changes in test_lost_device() you'd have to change reset_device() as well, but the test actually tests for return codes after a mode change. It doesn't work on the testbot because IIRC it starts at 1024x768.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-10-15 08:31, schrieb Henri Verbeet:
If you really wanted to avoid mode changes in test_lost_device() you'd have to change reset_device() as well, but the test actually tests for return codes after a mode change. It doesn't work on the testbot because IIRC it starts at 1024x768. Right, the S_PRESENT_MODE_CHANGED should have alerted me. Do you have any idea why a successful reset brings the device into this state?
Does reset_device call IDirect3DDevice9_Reset (instead of ResetEx) intentionally? The IDirect3DDevice9_ part suggests that it is unintentional, but in the context of the patch that added it (2f307a14) it makes some sense. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUPi5dAAoJEN0/YqbEcdMw1ZsP/R1OAUNjZXaOIY8QaJAoIcX4 uJ49wcqwq3hmbkGIsienoGv2FJ6Bap6QHzbTCbu4O17eBwYrr2wWi8KV2yqwi8pE HMzUpvbLDxVHlmsMkfLSFG/PBSXS1biLAd0pgYgwzS3JlKx+eTTdhyyx+UoneV4s 2aSzJXq2hsoz3FFGJAiJ6/0rl3c8aI/ZbNC4i96PoXAPiURanLtnX0TlhIc6ZZEt JKxJbxbugOlULsnIVwGRFP2suqPkLl6w4n9x9GKQSa2mSqoO/JoIg94uAkQ5DcZb PUCnz/6n/gW6SrGQqN+4oUR1gnZu/Gk3bdiyZWVYSh7tsTBJHEt1uzsGoAAa/6xp MXVM8nJzEEK6aUoDOa6QIliwrZhCLD8RKZwbtnXytWPUzSK/307D24ryRTYPqNLO QUy6l+3YXhaHYl9fHqjfl9d7K/zBfHiAtk6u9xPda6dTWoopzj3QNeifE4rmYmvc 4gSui3Hj/miCA9zcoifmK5LxgWqbcWgqTx4DT7Rxdic43MpBZMeXM5gVonPcvhOn Nl4of5VE+W5j/hv+p81ATyUM9KP+ydNQws02lEcS+747Y09Z3ubWTk98f9oKBBQP l6tuoKAWIS6skcZWc1PBX0wCcqIkaMuhe7qdoo/tJObvd11LbMwutnNg2ZANyAjD HaIh1E96ApXoB9TjGhuw =EzVW -----END PGP SIGNATURE-----
On 15 October 2014 10:20, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Am 2014-10-15 08:31, schrieb Henri Verbeet:
If you really wanted to avoid mode changes in test_lost_device() you'd have to change reset_device() as well, but the test actually tests for return codes after a mode change. It doesn't work on the testbot because IIRC it starts at 1024x768. Right, the S_PRESENT_MODE_CHANGED should have alerted me. Do you have any idea why a successful reset brings the device into this state?
I'm not entirely sure, but my guess would be that it has something to do with the order between resizing the swapchain buffers and the mode change.
Does reset_device call IDirect3DDevice9_Reset (instead of ResetEx) intentionally? The IDirect3DDevice9_ part suggests that it is unintentional, but in the context of the patch that added it (2f307a14) it makes some sense.
It was intentional, although it probably wouldn't hurt to have some more tests for ResetEx() as well.
participants (3)
-
Henri Verbeet -
Marvin -
Stefan Dösinger