[PATCH 0/2] MR3680: d3d9/tests: Wait longer in test_occlusion_query for software renderers.

[Stefan Dösinger (＠stefan)]

The issue can be reproduced with LIBGL_ALWAYS_SOFTWARE=1 on Mesa. The
Gitlab machines are affected.

[PATCH 1/2] d3d9/tests: Wait longer in test_occlusion_query for software renderers.

[Stefan Dösinger]

From: Stefan Dösinger

The issue can be reproduced with LIBGL_ALWAYS_SOFTWARE=1 on Mesa. The
Gitlab machines are affected.
---
 dlls/d3d9/tests/utils.h | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/dlls/d3d9/tests/utils.h b/dlls/d3d9/tests/utils.h
index 248e07eb521..1cfa97d09b4 100644
--- a/dlls/d3d9/tests/utils.h
+++ b/dlls/d3d9/tests/utils.h
@@ -27,12 +27,18 @@ static inline void wait_query_(const char *file, unsigned int line, IDirect3DQue
     unsigned int i;
     HRESULT hr;

-    for (i = 0; i < 500; ++i)
+    /* Some of the larger loops in test_occlusion_query() can take quite some time on
+     * software Mesa (i.e., the gitlab CI machines). */
+    for (i = 0; i < 1000; ++i)
     {
         if ((hr = IDirect3DQuery9_GetData(query, NULL, 0, D3DGETDATA_FLUSH)) == S_OK)
             break;
         Sleep(10);
     }
+
+    if (hr == S_OK && i >= 500)
+        trace_(file, line)("Query took %u ms to finish.\n", i * 10);
+
     ok_(file, line)(hr == S_OK, "Got unexpected hr %#lx.\n", hr);
 }

[PATCH 2/2] d3d9/tests: Reduce the empty occlusion query loop count.

[Stefan Dösinger]

From: Stefan Dösinger

---

Without this it occasionally still times out on the gitlab CI machines.
---
 dlls/d3d9/tests/device.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c
index 8ab52c7d5e4..041ede35326 100644
--- a/dlls/d3d9/tests/device.c
+++ b/dlls/d3d9/tests/device.c
@@ -6580,7 +6580,9 @@ static void test_occlusion_query(void)

hr = IDirect3DDevice9_BeginScene(device);
     ok(hr == D3D_OK, "Failed to begin scene, hr %#lx.\n", hr);
-    for (i = 0; i < 50000; ++i)
+    /* This loop can take some time on Mesa's software renderer. Don't push
+     * it too high or it might time out on Gitlab CI. */
+    for (i = 0; i < 30000; ++i)
     {
         hr = IDirect3DQuery9_Issue(query, D3DISSUE_BEGIN);
         ok(hr == D3D_OK, "Got unexpected hr %#lx.\n", hr);

[Alexandre Julliard (＠julliard)]

Alexandre Julliard (@julliard) commented about dlls/d3d9/tests/device.c:
>  hr = IDirect3DDevice9_BeginScene(device);
>  ok(hr == D3D_OK, "Failed to begin scene, hr %#lx.\n", hr);
> - for (i = 0; i < 50000; ++i)
> - /* This loop can take some time on Mesa's software renderer. Don't push
> -
> * it too high or it might time out on Gitlab CI. */
> - for (i = 0; i < 30000; ++i)

I think you should reduce it much more drastically. There's no reason to spend tens of seconds just on this test.

Or run a few hundred loops first to check if it's fast enough.

[Stefan Dösinger (＠stefan)]

On Tue Aug 29 20:02:02 2023 +0000, Alexandre Julliard wrote:
> I think you should reduce it much more drastically. There's no reason to
> spend tens of seconds just on this test.
> Or run a few hundred loops first to check if it's fast enough.

As pointed out by Zeb on !3565 there was a real bug behind this test: https://bugs.winehq.org/show_bug.cgi?id=45932 . I think the problem was accidental filling of the GPU submission queues, which usually won't be done with a few hundred loops.

The test isn't slow on proper GPUs, the 30k iterations take 0.5 seconds on my system. If we care about speed in the d3d tests we shouldn't use a software renderer.

[Alexandre Julliard (＠julliard)]

> As pointed out by Zeb on !3565 there was a real bug behind this test: https://bugs.winehq.org/show_bug.cgi?id=45932 . I think the problem was accidental filling of the GPU submission queues, which usually won't be done with a few hundred loops.

Sure, but it's not worth spending 60s on it.
> The test isn't slow on proper GPUs, the 30k iterations take 0.5 seconds on my system. If we care about speed in the d3d tests we shouldn't use a software renderer.

No, we should simply skip that test if the renderer is too slow, which is what I suggested.

[Stefan Dösinger (＠stefan)]

On Wed Aug 30 10:51:41 2023 +0000, Alexandre Julliard wrote:
> > As pointed out by Zeb on !3565 there was a real bug behind this test:
>
> https://bugs.winehq.org/show_bug.cgi?id=45932 . I think the problem was
> accidental filling of the GPU submission queues, which usually won't be
> done with a few hundred loops.
> Sure, but it's not worth spending 60s on it.
> > The test isn't slow on proper GPUs, the 30k iterations take 0.5
>
> seconds on my system. If we care about speed in the d3d tests we
> shouldn't use a software renderer.
> No, we should simply skip that test if the renderer is too slow, which
> is what I suggested.

oh, I misunderstood the "to check if its fast enough" comment - I'll see if I can time this in an appropriate manner.