[Bug 52090] New: New failures in d3d11:d3d11 in Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52090

Bug ID: 52090
           Summary: New failures in d3d11:d3d11 in Wine
           Product: Wine
           Version: unspecified
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: directx-d3d
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Running d3d11:d3d11 on the TestBot debiant2 VM used to consistently produce 70
failures. But on 2021-11-04 the failure mix changed and the count increased to
a steady 77 failures.

The new failures happen in void test_fractional_viewports() and
test_negative_viewports().
In typical unified diff style:

-d3d11.c:5926: Test failed: Got unexpected CPrimitives count: 3.
-d3d11.c:5943: Test failed: Got unexpected CPrimitives count: 3.
+d3d11.c:28242: Test failed: Got 0xffffffff, expected 0xff00ff00 at (639, 479,
0), sub-resource 0.
+d3d11.c:28242: Test succeeded inside todo block: Got 0xffffffff, expected
0xffffffff at (640, 480, 1), sub-resource 0.
+d3d11.c:28251: Test failed: Got 0xffffffff, expected 0xff00ff00 at (639, 479,
0), sub-resource 0.
+d3d11.c:28251: Test succeeded inside todo block: Got 0xffffffff, expected
0xffffffff at (640, 480, 1), sub-resource 0.
+d3d11.c:28188: Test failed: Got texcoord {8.43750119e-001, 1.56249881e-001},
expected {8.43750000e-001, 1.56250000e-001} at (3, 3), offset 1.25000000e-001.
+d3d11.c:28242: Test failed: Got 0xffffffff, expected 0xff00ff00 at (639, 479,
0), sub-resource 0.
+d3d11.c:28188: Test failed: Got texcoord {8.71093690e-001, 1.28906310e-001},
expected {8.71093750e-001, 1.28906250e-001} at (3, 3), offset 1.56250000e-002.
+d3d11.c:28251: Test failed: Got 0xffffffff, expected 0xff00ff00 at (639, 479,
0), sub-resource 0.
+d3d11.c:28188: Test failed: Got texcoord {7.51953065e-001, 2.48046935e-001},
expected {7.51953125e-001, 2.48046875e-001} at (3, 3), offset 4.92187500e-001.

https://test.winehq.org/data/patterns.html#d3d11:d3d11

A bisect shows that the new failures started with the commit below:

commit 26a53f674c234aaba4a85ec36bae48384899b705
Author: Stefan Dösinger 
Date:   Wed Nov 3 20:15:30 2021 +0300

wined3d: Emulate fractional viewports if GL doesn't support them.

This allows test_fractional_viewports to pass regardless of GL capabilies.
    I don't think we can get rid of WINED3D_PIXEL_CENTER_INTEGER (and add +0.5
    in the client libs) due to vpos in d3d9 shaders.

Signed-off-by: Stefan Dösinger 
    Signed-off-by: Henri Verbeet 
    Signed-off-by: Alexandre Julliard

[Bug 52090] New failures in d3d11:d3d11 in Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52090

François Gouget  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
    Regression SHA1|                            |26a53f674c234aaba4a85ec36ba
                   |                            |e48384899b705
           Keywords|                            |regression, source,
                   |                            |testcase

[Bug 52090] New failures in d3d11:d3d11 in Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52090

Stefan Dösinger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #1 from Stefan Dösinger  ---
This one is curious. llvmpipe sets GL_VIEWPORT_SUBPIXEL_BITS=0 but apparently
supports subpixel offsets anyway.

Before 26a53f67 we gladly forwarded the d3d11 fractional viewport to GL, and it
worked for this driver even though the driver it can't do that. So the test
passed between 044f5e10 and 26a53f67. Before the former patch it was marked
todo_wine and was failing for other reasons.

Now we don't give the driver something it says it doesn't support and modify
the vertex transforms instead. That was supposed to work (and it does on other
drivers), but I guess then we run into some precision issue that I suspect is
behind bug 52089.

I'll have a look at the Mesa code and see why GL_VIEWPORT_SUBPIXEL_BITS=0. We
could do the reverse of match_broken_viewport_subpixel_bits and detect
llvmpipe's behaviour, but that seems ugly.

[Bug 52090] New failures in d3d11:d3d11 in Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52090

--- Comment #2 from Stefan Dösinger  ---
Changing GL_VIEWPORT_SUBPIXEL_BITS in llvmpipe is easy and it fixes those new
test failures, but it introduces new ones. Apparently GL_ARB_clip_control has
its own issues in llvmpipe. GL_VIEWPORT_SUBPIXEL_BITS=8 makes wined3d use
ARB_clip_control, breaking some other tests in d3d11 and d2d1 (and maybe even
more, I didn't test other modules yet).

[Bug 52090] New failures in d3d11:d3d11 in Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52090

--- Comment #3 from Stefan Dösinger  ---
I submitted https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13994 to
Mesa about the GL_VIEWPORT_SUBPIXEL_BITS part of this. This will fix the errors
in this patch, but bring up other previously hidden problems that are a result
of using clip_control.

[Bug 52090] New failures in d3d11:d3d11 in Wine

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=52090

Stefan Dösinger  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |NOTOURBUG

--- Comment #4 from Stefan Dösinger  ---
According to a comment by Erik Faye-Lund on the above pull request, llvmpipe
has known problems with sub-pixel viewports and exposing the functionality is
not correct at this point.

I'll mark this as resolved for now.