[PATCH 1/3] wined3d: Don't shift geometry for d3d10/11.

List overview All Threads

newer

older

[PATCH 1/5] winebus.sys: Return...

[PATCH v2 1/5] wined3d: Don't...

Stefan Dösinger

5 Aug 2021 5 Aug '21

5:56 p.m.

This fixes stay lines in World of Tanks' GameFace UI parts. The Metal backend doesn't have an offset like this either.

Signed-off-by: Stefan Dösinger stefan@codeweavers.com

---

Other than fixing the todo_wine in test_fractional_viewport, this also fixes a failure in d3d11's test_depth_bias that happens when viewport_array is not supported.

I am not entirely sure what the -1 / 64 in get_projection_matrix was meant for. AFAIU get_projection_matrix isn't called for d3d10+, so the path will be entered for d3d9 when we have ARB_CLIP_CONTROL. In this case we don't need to account for the half pixel offset (hence not setting it to 63/64), and I also don't see a reason to nudge for filling rules in the proj matrix and not by adjusting the values in viewport_miscpart_cc. --- dlls/d3d11/tests/d3d11.c | 1 - dlls/wined3d/state.c | 2 +- dlls/wined3d/utils.c | 2 +- dlls/wined3d/wined3d_private.h | 2 +- 4 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/dlls/d3d11/tests/d3d11.c b/dlls/d3d11/tests/d3d11.c index 6073fae26d9..1f797da1646 100644 --- a/dlls/d3d11/tests/d3d11.c +++ b/dlls/d3d11/tests/d3d11.c @@ -28153,7 +28153,6 @@ static void test_fractional_viewports(void) ok(compare_float(v->x, expected.x, 0) && compare_float(v->y, expected.y, 0), "Got fragcoord {%.8e, %.8e}, expected {%.8e, %.8e} at (%u, %u), offset %.8e.\n", v->x, v->y, expected.x, expected.y, x, y, viewport_offsets[i]); - todo_wine ok(compare_float(v->z, expected.z, 2) && compare_float(v->w, expected.w, 2), "Got texcoord {%.8e, %.8e}, expected {%.8e, %.8e} at (%u, %u), offset %.8e.\n", v->z, v->w, expected.z, expected.w, x, y, viewport_offsets[i]); diff --git a/dlls/wined3d/state.c b/dlls/wined3d/state.c index 8316269afcf..b94c04a79b4 100644 --- a/dlls/wined3d/state.c +++ b/dlls/wined3d/state.c @@ -4233,7 +4233,7 @@ static void viewport_miscpart_cc(struct wined3d_context *context, const struct wined3d_gl_info *gl_info = wined3d_context_gl(context)->gl_info; /* See get_projection_matrix() in utils.c for a discussion about those values. */ float pixel_center_offset = context->d3d_info->wined3d_creation_flags - & WINED3D_PIXEL_CENTER_INTEGER ? 63.0f / 128.0f : -1.0f / 128.0f; + & WINED3D_PIXEL_CENTER_INTEGER ? 63.0f / 128.0f : 0.0f; struct wined3d_viewport vp[WINED3D_MAX_VIEWPORTS]; GLdouble depth_ranges[2 * WINED3D_MAX_VIEWPORTS]; GLfloat viewports[4 * WINED3D_MAX_VIEWPORTS]; diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c index 4019dd4d812..69c6f073e96 100644 --- a/dlls/wined3d/utils.c +++ b/dlls/wined3d/utils.c @@ -5555,7 +5555,7 @@ void get_projection_matrix(const struct wined3d_context *context, const struct w if (!clip_control && d3d_info->wined3d_creation_flags & WINED3D_PIXEL_CENTER_INTEGER) center_offset = 63.0f / 64.0f; else - center_offset = -1.0f / 64.0f; + center_offset = 0.0f;

if (context->last_was_rhw) { diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index 86eae149306..0bf9e01ba42 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -5662,7 +5662,7 @@ static inline void shader_get_position_fixup(const struct wined3d_context *conte if (context->d3d_info->wined3d_creation_flags & WINED3D_PIXEL_CENTER_INTEGER) center_offset = 63.0f / 64.0f; else - center_offset = -1.0f / 64.0f; + center_offset = 0.0f;

for (i = 0; i < fixup_count; ++i) {

-- 2.31.1

Show replies by date

Stefan Dösinger

5 Aug 5 Aug

5:56 p.m.

New subject: [PATCH 2/3] d3d11/tests: Fix a gcc -Wmisleading-indentation warning.

Because the ID3D11Asynchronous_Release(query) line is indented 4 spaces more than the if condition gcc thinks the code is misleading.

Signed-off-by: Stefan Dösinger stefan@codeweavers.com

---

../../src/wine/dlls/d3d11/tests/d3d11.c: In function 'test_occlusion_query': ../../src/wine/dlls/d3d11/tests/d3d11.c:5857:1: warning: this 'if' clause does not guard... [-Wmisleading-indentation] 5857 | if (0) | ^~ ../../src/wine/dlls/d3d11/tests/d3d11.c:5861:5: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if' 5861 | ID3D11Asynchronous_Release(query); | ^~~~~~~~~~~~~~~~~~~~~~~~~~

$ i686-w64-mingw32-gcc --version i686-w64-mingw32-gcc (Gentoo 11.2.0 p1) 11.2.0 --- dlls/d3d11/tests/d3d11.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/dlls/d3d11/tests/d3d11.c b/dlls/d3d11/tests/d3d11.c index 1f797da1646..e08408b4884 100644 --- a/dlls/d3d11/tests/d3d11.c +++ b/dlls/d3d11/tests/d3d11.c @@ -5856,9 +5856,11 @@ static void test_occlusion_query(void)

get_query_data(context, query, &data, sizeof(data)); /* This test occasionally succeeds with CSMT enabled because of a race condition. */ -if (0) - todo_wine ok(data.dword[0] == 0x1000 && !data.dword[1], - "Got unexpected query result 0x%08x%08x.\n", data.dword[1], data.dword[0]); + if (0) + { + todo_wine ok(data.dword[0] == 0x1000 && !data.dword[1], + "Got unexpected query result 0x%08x%08x.\n", data.dword[1], data.dword[0]); + }

ID3D11Asynchronous_Release(query); ID3D11RenderTargetView_Release(rtv);

-- 2.31.1

Marvin

6:28 p.m.

New subject: [PATCH 2/3] d3d11/tests: Fix a gcc -Wmisleading-indentation warning.

Hi,

While running your changed tests, 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=95120

Your paranoid android.

=== w1064v1809 (32 bit report) ===

d3d11: d3d11.c:5920: Test failed: Got unexpected IAVertices count: 0. d3d11.c:5921: Test failed: Got unexpected IAPrimitives count: 0. d3d11.c:5922: Test failed: Got unexpected VSInvocations count: 0. d3d11.c:5925: Test failed: Got unexpected CInvocations count: 0. d3d11.c:5926: Test failed: Got unexpected CPrimitives count: 0.

=== w1064 (32 bit report) ===

d3d11: d3d11.c:5765: Test failed: Got unexpected query result 0x0000000000000000. d3d11.c:5920: Test failed: Got unexpected IAVertices count: 0. d3d11.c:5921: Test failed: Got unexpected IAPrimitives count: 0. d3d11.c:5922: Test failed: Got unexpected VSInvocations count: 0. d3d11.c:5925: Test failed: Got unexpected CInvocations count: 0. d3d11.c:5926: Test failed: Got unexpected CPrimitives count: 0.

=== debiant2 (32 bit report) ===

d3d11: d3d11.c:27975: Test failed: Got depth 4.99374978e-003, expected 4.99999994e-003. d3d11.c:27975: Test failed: Got depth 4.99374978e-003, expected 4.99999994e-003. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27975: Test failed: Got depth 7.48750009e-003, expected 7.49999994e-003. d3d11.c:27975: Test failed: Got depth 7.48750009e-003, expected 7.49999994e-003. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27975: Test failed: Got depth 1.24749998e-002, expected 1.24999999e-002. d3d11.c:27975: Test failed: Got depth 1.24749998e-002, expected 1.24999999e-002. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27975: Test failed: Got depth 6.40899956e-001, expected 6.42500000e-001. d3d11.c:27975: Test failed: Got depth 6.40899956e-001, expected 6.42500000e-001. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27983: Test failed: Got value 0x14745 (4.99373704e-003), expected 0x147ae (4.99999553e-003). d3d11.c:27983: Test failed: Got value 0x14745 (4.99373704e-003), expected 0x147ae (4.99999553e-003). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27983: Test failed: Got value 0x1eab3 (7.48747632e-003), expected 0x1eb85 (7.49999329e-003). d3d11.c:27983: Test failed: Got value 0x1eab3 (7.48747632e-003), expected 0x1eb85 (7.49999329e-003). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27983: Test failed: Got value 0x33190 (1.24750145e-002), expected 0x33333 (1.24999888e-002). d3d11.c:27983: Test failed: Got value 0x33190 (1.24750145e-002), expected 0x33333 (1.24999888e-002). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27983: Test failed: Got value 0xa41204 (6.40899935e-001), expected 0xa47ae1 (6.42500022e-001). d3d11.c:27983: Test failed: Got value 0xa41204 (6.40899935e-001), expected 0xa47ae1 (6.42500022e-001). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27992: Test failed: Got value 0x28e (9.97940032e-003), expected 0x290 (1.00099184e-002). d3d11.c:27992: Test failed: Got value 0x28e (9.97940032e-003), expected 0x290 (1.00099184e-002). d3d11.c:27992: Test failed: Got value 0x331 (1.24666209e-002), expected 0x334 (1.25123980e-002). d3d11.c:27992: Test failed: Got value 0x331 (1.24666209e-002), expected 0x334 (1.25123980e-002). d3d11.c:27992: Test failed: Got value 0x476 (1.74258030e-002), expected 0x47b (1.75020981e-002). d3d11.c:27992: Test failed: Got value 0x476 (1.74258030e-002), expected 0x47b (1.75020981e-002). d3d11.c:27992: Test failed: Got value 0xa411 (6.40894179e-001), expected 0xa47a (6.42496376e-001). d3d11.c:27992: Test failed: Got value 0xa411 (6.40894179e-001), expected 0xa47a (6.42496376e-001).

=== debiant2 (32 bit Arabic:Morocco report) ===

=== debiant2 (32 bit German report) ===

=== debiant2 (32 bit French report) ===

=== debiant2 (32 bit Hebrew:Israel report) ===

=== debiant2 (32 bit Hindi:India report) ===

=== debiant2 (32 bit Japanese:Japan report) ===

=== debiant2 (32 bit Chinese:China report) ===

=== debiant2 (32 bit WoW report) ===

=== debiant2 (64 bit WoW report) ===

d3d11: d3d11.c:27975: Test failed: Got depth 4.99374978e-003, expected 4.99999989e-003. d3d11.c:27975: Test failed: Got depth 4.99374978e-003, expected 4.99999989e-003. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27975: Test failed: Got depth 7.48750009e-003, expected 7.49999983e-003. d3d11.c:27975: Test failed: Got depth 7.48750009e-003, expected 7.49999983e-003. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27975: Test failed: Got depth 1.24749998e-002, expected 1.24999997e-002. d3d11.c:27975: Test failed: Got depth 1.24749998e-002, expected 1.24999997e-002. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27975: Test failed: Got depth 6.40899956e-001, expected 6.42499986e-001. d3d11.c:27975: Test failed: Got depth 6.40899956e-001, expected 6.42499986e-001. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27975: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27983: Test failed: Got value 0x14745 (4.99373721e-003), expected 0x147ae (4.99999570e-003). d3d11.c:27983: Test failed: Got value 0x14745 (4.99373721e-003), expected 0x147ae (4.99999570e-003). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27983: Test failed: Got value 0x1eab3 (7.48747634e-003), expected 0x1eb85 (7.49999331e-003). d3d11.c:27983: Test failed: Got value 0x1eab3 (7.48747634e-003), expected 0x1eb85 (7.49999331e-003). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27983: Test failed: Got value 0x33190 (1.24750147e-002), expected 0x33333 (1.24999890e-002). d3d11.c:27983: Test failed: Got value 0x33190 (1.24750147e-002), expected 0x33333 (1.24999890e-002). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27983: Test failed: Got value 0xa41204 (6.40899956e-001), expected 0xa47ae0 (6.42499983e-001). d3d11.c:27983: Test failed: Got value 0xa41204 (6.40899956e-001), expected 0xa47ae0 (6.42499983e-001). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27983: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27992: Test failed: Got value 0x28e (9.97940078e-003), expected 0x290 (1.00099184e-002). d3d11.c:27992: Test failed: Got value 0x28e (9.97940078e-003), expected 0x290 (1.00099184e-002). d3d11.c:27992: Test failed: Got value 0x331 (1.24666207e-002), expected 0x334 (1.25123980e-002). d3d11.c:27992: Test failed: Got value 0x331 (1.24666207e-002), expected 0x334 (1.25123980e-002). d3d11.c:27992: Test failed: Got value 0x476 (1.74258035e-002), expected 0x47b (1.75020974e-002). d3d11.c:27992: Test failed: Got value 0x476 (1.74258035e-002), expected 0x47b (1.75020974e-002). d3d11.c:27992: Test failed: Got value 0xa411 (6.40894175e-001), expected 0xa47a (6.42496347e-001). d3d11.c:27992: Test failed: Got value 0xa411 (6.40894175e-001), expected 0xa47a (6.42496347e-001).

Henri Verbeet

6 Aug 6 Aug

2:02 p.m.

New subject: [PATCH 2/3] d3d11/tests: Fix a gcc -Wmisleading-indentation warning.

Signed-off-by: Henri Verbeet hverbeet@codeweavers.com

Stefan Dösinger

5 Aug 5 Aug

5:56 p.m.

New subject: [PATCH 3/3] wined3d: Emulate fractional viewports when viewport_array is not supported.

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 stefan@codeweavers.com

---

I am a bit surprised it works as well as it does. AFAIU there are still some shortcomings with this emulation, e.g. test that combines test_depth_bias with test_fractional_viewports would presumably fail. --- dlls/wined3d/adapter_gl.c | 1 + dlls/wined3d/adapter_vk.c | 1 + dlls/wined3d/wined3d_private.h | 13 ++++++++++--- 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/dlls/wined3d/adapter_gl.c b/dlls/wined3d/adapter_gl.c index 902b9620f30..7f3d2512676 100644 --- a/dlls/wined3d/adapter_gl.c +++ b/dlls/wined3d/adapter_gl.c @@ -5129,6 +5129,7 @@ static void wined3d_adapter_gl_init_d3d_info(struct wined3d_adapter_gl *adapter_ d3d_info->clip_control = !!gl_info->supported[ARB_CLIP_CONTROL]; d3d_info->full_ffp_varyings = !!(shader_caps.wined3d_caps & WINED3D_SHADER_CAP_FULL_FFP_VARYINGS); d3d_info->scaled_resolve = !!gl_info->supported[EXT_FRAMEBUFFER_MULTISAMPLE_BLIT_SCALED]; + d3d_info->subpixel_viewport = !!gl_info->supported[ARB_VIEWPORT_ARRAY]; d3d_info->feature_level = feature_level_from_caps(gl_info, &shader_caps, &fragment_caps);

if (gl_info->supported[ARB_TEXTURE_MULTISAMPLE]) diff --git a/dlls/wined3d/adapter_vk.c b/dlls/wined3d/adapter_vk.c index c7da02865ea..31f2b677b5f 100644 --- a/dlls/wined3d/adapter_vk.c +++ b/dlls/wined3d/adapter_vk.c @@ -2172,6 +2172,7 @@ static void wined3d_adapter_vk_init_d3d_info(struct wined3d_adapter_vk *adapter_ d3d_info->full_ffp_varyings = !!(shader_caps.wined3d_caps & WINED3D_SHADER_CAP_FULL_FFP_VARYINGS); d3d_info->scaled_resolve = false; d3d_info->feature_level = feature_level_from_caps(&shader_caps); + d3d_info->subpixel_viewport = true;

d3d_info->multisample_draw_location = WINED3D_LOCATION_TEXTURE_RGB; } diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index 0bf9e01ba42..6976ef90904 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -239,6 +239,7 @@ struct wined3d_d3d_info uint32_t clip_control : 1; uint32_t full_ffp_varyings : 1; uint32_t scaled_resolve : 1; + uint32_t subpixel_viewport : 1; enum wined3d_feature_level feature_level;

DWORD multisample_draw_location; @@ -5656,7 +5657,7 @@ static inline BOOL shader_is_scalar(const struct wined3d_shader_register *reg) static inline void shader_get_position_fixup(const struct wined3d_context *context, const struct wined3d_state *state, unsigned int fixup_count, float *position_fixup) { - float center_offset; + float center_offset, x = 0.0f, y = 0.0f; unsigned int i;

if (context->d3d_info->wined3d_creation_flags & WINED3D_PIXEL_CENTER_INTEGER) @@ -5668,8 +5669,14 @@ static inline void shader_get_position_fixup(const struct wined3d_context *conte { position_fixup[4 * i ] = 1.0f; position_fixup[4 * i + 1] = 1.0f; - position_fixup[4 * i + 2] = center_offset / state->viewports[i].width; - position_fixup[4 * i + 3] = -center_offset / state->viewports[i].height; + if (!context->d3d_info->subpixel_viewport) + { + double dummy; + x = modf(state->viewports[i].x, &dummy) * 2.0f; + y = modf(state->viewports[i].y, &dummy) * 2.0f; + } + position_fixup[4 * i + 2] = (center_offset + x) / state->viewports[i].width; + position_fixup[4 * i + 3] = -(center_offset + y) / state->viewports[i].height;

if (context->render_offscreen) {

-- 2.31.1

Henri Verbeet

6 Aug 6 Aug

2:02 p.m.

New subject: [PATCH 3/3] wined3d: Emulate fractional viewports when viewport_array is not supported.

On Thu, 5 Aug 2021 at 19:57, Stefan Dösinger stefan@codeweavers.com wrote:

...

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.

@@ -5129,6 +5129,7 @@ static void wined3d_adapter_gl_init_d3d_info(struct wined3d_adapter_gl *adapter_ d3d_info->clip_control = !!gl_info->supported[ARB_CLIP_CONTROL]; d3d_info->full_ffp_varyings = !!(shader_caps.wined3d_caps & WINED3D_SHADER_CAP_FULL_FFP_VARYINGS); d3d_info->scaled_resolve = !!gl_info->supported[EXT_FRAMEBUFFER_MULTISAMPLE_BLIT_SCALED];

d3d_info->subpixel_viewport = !!gl_info->supported[ARB_VIEWPORT_ARRAY]; d3d_info->feature_level = feature_level_from_caps(gl_info, &shader_caps, &fragment_caps);

Should this be conditional on GL_VIEWPORT_SUBPIXEL_BITS having a reasonable value, similar to what we do for clip control?

Marvin

5 Aug 5 Aug

6:14 p.m.

Hi,

While running your changed tests, 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=95119

Your paranoid android.

=== w1064v1809 (32 bit report) ===

d3d11: d3d11.c:5918: Test failed: Got unexpected IAVertices count: 0. d3d11.c:5919: Test failed: Got unexpected IAPrimitives count: 0. d3d11.c:5920: Test failed: Got unexpected VSInvocations count: 0. d3d11.c:5923: Test failed: Got unexpected CInvocations count: 0. d3d11.c:5924: Test failed: Got unexpected CPrimitives count: 0.

=== w1064 (32 bit report) ===

d3d11: d3d11.c:5765: Test failed: Got unexpected query result 0x0000000000000000. d3d11.c:5918: Test failed: Got unexpected IAVertices count: 0. d3d11.c:5919: Test failed: Got unexpected IAPrimitives count: 0. d3d11.c:5920: Test failed: Got unexpected VSInvocations count: 0. d3d11.c:5923: Test failed: Got unexpected CInvocations count: 0. d3d11.c:5924: Test failed: Got unexpected CPrimitives count: 0.

=== w1064_tsign (32 bit report) ===

=== debiant2 (32 bit report) ===

d3d11: d3d11.c:9768: Test failed: d3d11.c:15129: Test marked todo: Got hr 0 for WRITE. d3d11.c:27973: Test failed: Got depth 4.99374978e-003, expected 4.99999994e-003. d3d11.c:27973: Test failed: Got depth 4.99374978e-003, expected 4.99999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 7.48750009e-003, expected 7.49999994e-003. d3d11.c:27973: Test failed: Got depth 7.48750009e-003, expected 7.49999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 1.24749998e-002, expected 1.24999999e-002. d3d11.c:27973: Test failed: Got depth 1.24749998e-002, expected 1.24999999e-002. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 6.40899956e-001, expected 6.42500000e-001. d3d11.c:27973: Test failed: Got depth 6.40899956e-001, expected 6.42500000e-001. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27981: Test failed: Got value 0x14745 (4.99373704e-003), expected 0x147ae (4.99999553e-003). d3d11.c:27981: Test failed: Got value 0x14745 (4.99373704e-003), expected 0x147ae (4.99999553e-003). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x1eab3 (7.48747632e-003), expected 0x1eb85 (7.49999329e-003). d3d11.c:27981: Test failed: Got value 0x1eab3 (7.48747632e-003), expected 0x1eb85 (7.49999329e-003). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x33190 (1.24750145e-002), expected 0x33333 (1.24999888e-002). d3d11.c:27981: Test failed: Got value 0x33190 (1.24750145e-002), expected 0x33333 (1.24999888e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0xa41204 (6.40899935e-001), expected 0xa47ae1 (6.42500022e-001). d3d11.c:27981: Test failed: Got value 0xa41204 (6.40899935e-001), expected 0xa47ae1 (6.42500022e-001). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27990: Test failed: Got value 0x28e (9.97940032e-003), expected 0x290 (1.00099184e-002). d3d11.c:27990: Test failed: Got value 0x28e (9.97940032e-003), expected 0x290 (1.00099184e-002). d3d11.c:27990: Test failed: Got value 0x331 (1.24666209e-002), expected 0x334 (1.25123980e-002). d3d11.c:27990: Test failed: Got value 0x331 (1.24666209e-002), expected 0x334 (1.25123980e-002). d3d11.c:27990: Test failed: Got value 0x476 (1.74258030e-002), expected 0x47b (1.75020981e-002). d3d11.c:27990: Test failed: Got value 0x476 (1.74258030e-002), expected 0x47b (1.75020981e-002). d3d11.c:27990: Test failed: Got value 0xa411 (6.40894179e-001), expected 0xa47a (6.42496376e-001). d3d11.c:27990: Test failed: Got value 0xa411 (6.40894179e-001), expected 0xa47a (6.42496376e-001).

=== debiant2 (32 bit Arabic:Morocco report) ===

=== debiant2 (32 bit German report) ===

d3d11: d3d11.c:27973: Test failed: Got depth 4.99374978e-003, expected 4.99999994e-003. d3d11.c:27973: Test failed: Got depth 4.99374978e-003, expected 4.99999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 7.48750009e-003, expected 7.49999994e-003. d3d11.c:27973: Test failed: Got depth 7.48750009e-003, expected 7.49999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 1.24749998e-002, expected 1.24999999e-002. d3d11.c:27973: Test failed: Got depth 1.24749998e-002, expected 1.24999999e-002. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 6.40899956e-001, expected 6.42500000e-001. d3d11.c:27973: Test failed: Got depth 6.40899956e-001, expected 6.42500000e-001. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27981: Test failed: Got value 0x14745 (4.99373704e-003), expected 0x147ae (4.99999553e-003). d3d11.c:27981: Test failed: Got value 0x14745 (4.99373704e-003), expected 0x147ae (4.99999553e-003). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x1eab3 (7.48747632e-003), expected 0x1eb85 (7.49999329e-003). d3d11.c:27981: Test failed: Got value 0x1eab3 (7.48747632e-003), expected 0x1eb85 (7.49999329e-003). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x33190 (1.24750145e-002), expected 0x33333 (1.24999888e-002). d3d11.c:27981: Test failed: Got value 0x33190 (1.24750145e-002), expected 0x33333 (1.24999888e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0xa41204 (6.40899935e-001), expected 0xa47ae1 (6.42500022e-001). d3d11.c:27981: Test failed: Got value 0xa41204 (6.40899935e-001), expected 0xa47ae1 (6.42500022e-001). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27990: Test failed: Got value 0x28e (9.97940032e-003), expected 0x290 (1.00099184e-002). d3d11.c:27990: Test failed: Got value 0x28e (9.97940032e-003), expected 0x290 (1.00099184e-002). d3d11.c:27990: Test failed: Got value 0x331 (1.24666209e-002), expected 0x334 (1.25123980e-002). d3d11.c:27990: Test failed: Got value 0x331 (1.24666209e-002), expected 0x334 (1.25123980e-002). d3d11.c:27990: Test failed: Got value 0x476 (1.74258030e-002), expected 0x47b (1.75020981e-002). d3d11.c:27990: Test failed: Got value 0x476 (1.74258030e-002), expected 0x47b (1.75020981e-002). d3d11.c:27990: Test failed: Got value 0xa411 (6.40894179e-001), expected 0xa47a (6.42496376e-001). d3d11.c:27990: Test failed: Got value 0xa411 (6.40894179e-001), expected 0xa47a (6.42496376e-001).

=== debiant2 (32 bit French report) ===

=== debiant2 (32 bit Hebrew:Israel report) ===

=== debiant2 (32 bit Hindi:India report) ===

=== debiant2 (32 bit Japanese:Japan report) ===

d3d11: d3d11.c:9768: Test failed: d3d11.c:15151: Test marked todo: Test 60: Got unexpected color 0xffffff00 at (3, 0). d3d11.c:9768: Test failed: d3d11.c:15129: Test marked todo: Got hr 0 for WRITE. d3d11.c:9768: Test failed: Got hr 0 for WRITE_DISCARD. d3d11.c:27973: Test failed: Got depth 4.99374978e-003, expected 4.99999994e-003. d3d11.c:27973: Test failed: Got depth 4.99374978e-003, expected 4.99999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 7.48750009e-003, expected 7.49999994e-003. d3d11.c:27973: Test failed: Got depth 7.48750009e-003, expected 7.49999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 1.24749998e-002, expected 1.24999999e-002. d3d11.c:27973: Test failed: Got depth 1.24749998e-002, expected 1.24999999e-002. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 6.40899956e-001, expected 6.42500000e-001. d3d11.c:27973: Test failed: Got depth 6.40899956e-001, expected 6.42500000e-001. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27981: Test failed: Got value 0x14745 (4.99373704e-003), expected 0x147ae (4.99999553e-003). d3d11.c:27981: Test failed: Got value 0x14745 (4.99373704e-003), expected 0x147ae (4.99999553e-003). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x1eab3 (7.48747632e-003), expected 0x1eb85 (7.49999329e-003). d3d11.c:27981: Test failed: Got value 0x1eab3 (7.48747632e-003), expected 0x1eb85 (7.49999329e-003). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x33190 (1.24750145e-002), expected 0x33333 (1.24999888e-002). d3d11.c:27981: Test failed: Got value 0x33190 (1.24750145e-002), expected 0x33333 (1.24999888e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0xa41204 (6.40899935e-001), expected 0xa47ae1 (6.42500022e-001). d3d11.c:27981: Test failed: Got value 0xa41204 (6.40899935e-001), expected 0xa47ae1 (6.42500022e-001). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097461e-002), expected 0x85293 (3.25099845e-002). d3d11.c:27990: Test failed: Got value 0x28e (9.97940032e-003), expected 0x290 (1.00099184e-002). d3d11.c:27990: Test failed: Got value 0x28e (9.97940032e-003), expected 0x290 (1.00099184e-002). d3d11.c:27990: Test failed: Got value 0x331 (1.24666209e-002), expected 0x334 (1.25123980e-002). d3d11.c:27990: Test failed: Got value 0x331 (1.24666209e-002), expected 0x334 (1.25123980e-002). d3d11.c:27990: Test failed: Got value 0x476 (1.74258030e-002), expected 0x47b (1.75020981e-002). d3d11.c:27990: Test failed: Got value 0x476 (1.74258030e-002), expected 0x47b (1.75020981e-002). d3d11.c:27990: Test failed: Got value 0xa411 (6.40894179e-001), expected 0xa47a (6.42496376e-001). d3d11.c:27990: Test failed: Got value 0xa411 (6.40894179e-001), expected 0xa47a (6.42496376e-001).

=== debiant2 (32 bit Chinese:China report) ===

=== debiant2 (32 bit WoW report) ===

=== debiant2 (64 bit WoW report) ===

d3d11: d3d11.c:9768: Test failed: d3d11.c:15129: Test marked todo: Got hr 0 for WRITE. d3d11.c:27973: Test failed: Got depth 4.99374978e-003, expected 4.99999989e-003. d3d11.c:27973: Test failed: Got depth 4.99374978e-003, expected 4.99999989e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 7.48750009e-003, expected 7.49999983e-003. d3d11.c:27973: Test failed: Got depth 7.48750009e-003, expected 7.49999983e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 1.24749998e-002, expected 1.24999997e-002. d3d11.c:27973: Test failed: Got depth 1.24749998e-002, expected 1.24999997e-002. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 6.40899956e-001, expected 6.42499986e-001. d3d11.c:27973: Test failed: Got depth 6.40899956e-001, expected 6.42499986e-001. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27973: Test failed: Got depth 2.50997487e-003, expected 2.50999994e-003. d3d11.c:27981: Test failed: Got value 0x14745 (4.99373721e-003), expected 0x147ae (4.99999570e-003). d3d11.c:27981: Test failed: Got value 0x14745 (4.99373721e-003), expected 0x147ae (4.99999570e-003). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27981: Test failed: Got value 0x1eab3 (7.48747634e-003), expected 0x1eb85 (7.49999331e-003). d3d11.c:27981: Test failed: Got value 0x1eab3 (7.48747634e-003), expected 0x1eb85 (7.49999331e-003). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27981: Test failed: Got value 0x33190 (1.24750147e-002), expected 0x33333 (1.24999890e-002). d3d11.c:27981: Test failed: Got value 0x33190 (1.24750147e-002), expected 0x33333 (1.24999890e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27981: Test failed: Got value 0xa41204 (6.40899956e-001), expected 0xa47ae0 (6.42499983e-001). d3d11.c:27981: Test failed: Got value 0xa41204 (6.40899956e-001), expected 0xa47ae0 (6.42499983e-001). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27981: Test failed: Got value 0x8528f (3.25097479e-002), expected 0x85293 (3.25099863e-002). d3d11.c:27990: Test failed: Got value 0x28e (9.97940078e-003), expected 0x290 (1.00099184e-002). d3d11.c:27990: Test failed: Got value 0x28e (9.97940078e-003), expected 0x290 (1.00099184e-002). d3d11.c:27990: Test failed: Got value 0x331 (1.24666207e-002), expected 0x334 (1.25123980e-002). d3d11.c:27990: Test failed: Got value 0x331 (1.24666207e-002), expected 0x334 (1.25123980e-002). d3d11.c:27990: Test failed: Got value 0x476 (1.74258035e-002), expected 0x47b (1.75020974e-002). d3d11.c:27990: Test failed: Got value 0x476 (1.74258035e-002), expected 0x47b (1.75020974e-002). d3d11.c:27990: Test failed: Got value 0xa411 (6.40894175e-001), expected 0xa47a (6.42496347e-001). d3d11.c:27990: Test failed: Got value 0xa411 (6.40894175e-001), expected 0xa47a (6.42496347e-001).

Henri Verbeet

6 Aug 6 Aug

2:01 p.m.

On Thu, 5 Aug 2021 at 19:57, Stefan Dösinger stefan@codeweavers.com wrote:

...

This fixes stay lines in World of Tanks' GameFace UI parts. The Metal backend doesn't have an offset like this either.

There is no Metal backend in upstream Wine ;)

...

Other than fixing the todo_wine in test_fractional_viewport, this also fixes a failure in d3d11's test_depth_bias that happens when viewport_array is not supported.

I am not entirely sure what the -1 / 64 in get_projection_matrix was meant for. AFAIU get_projection_matrix isn't called for d3d10+, so the path will be entered for d3d9 when we have ARB_CLIP_CONTROL. In this case we don't need to account for the half pixel offset (hence not setting it to 63/64), and I also don't see a reason to nudge for filling rules in the proj matrix and not by adjusting the values in viewport_miscpart_cc.

This may have been a mistake in commit a5d2b3622b7b4f731075d9cd62c76c64c468666b; originally this only checked for WINED3D_PIXEL_CENTER_INTEGER.

It seems a little awkward to tie this to WINED3D_PIXEL_CENTER_INTEGER. Would it make sense to instead detect the filling convention during adapter initialisation, so that we can get rid of this for d3d9 and before as well if possible? We could then just store the filling convention offset in the wined3d_d3d_info structure.

Matteo Bruni

2:19 p.m.

On Fri, Aug 6, 2021 at 4:02 PM Henri Verbeet hverbeet@gmail.com wrote:

...

On Thu, 5 Aug 2021 at 19:57, Stefan Dösinger stefan@codeweavers.com wrote:

...
This fixes stay lines in World of Tanks' GameFace UI parts. The Metal backend doesn't have an offset like this either.

There is no Metal backend in upstream Wine ;)

...
Other than fixing the todo_wine in test_fractional_viewport, this also fixes a failure in d3d11's test_depth_bias that happens when viewport_array is not supported.

I am not entirely sure what the -1 / 64 in get_projection_matrix was meant for. AFAIU get_projection_matrix isn't called for d3d10+, so the path will be entered for d3d9 when we have ARB_CLIP_CONTROL. In this case we don't need to account for the half pixel offset (hence not setting it to 63/64), and I also don't see a reason to nudge for filling rules in the proj matrix and not by adjusting the values in viewport_miscpart_cc.

This may have been a mistake in commit a5d2b3622b7b4f731075d9cd62c76c64c468666b; originally this only checked for WINED3D_PIXEL_CENTER_INTEGER.

I can't be sure now but I suspect that I meant to make the whole thing conditional on !clip_control (i.e. set center_offset to 0 for the clip_control case).

...

It seems a little awkward to tie this to WINED3D_PIXEL_CENTER_INTEGER. Would it make sense to instead detect the filling convention during adapter initialisation, so that we can get rid of this for d3d9 and before as well if possible? We could then just store the filling convention offset in the wined3d_d3d_info structure.

FWIW I like this idea a lot.

Stefan Dösinger

7 Aug 7 Aug

7 a.m.

Am Freitag, 6. August 2021, 17:01:48 EAT schrieb Henri Verbeet:

...

There is no Metal backend in upstream Wine ;)

Woops, all that mac work has brain damaged me :-)

...

It seems a little awkward to tie this to WINED3D_PIXEL_CENTER_INTEGER. Would it make sense to instead detect the filling convention during adapter initialisation, so that we can get rid of this for d3d9 and before as well if possible? We could then just store the filling convention offset in the wined3d_d3d_info structure.

Yeah I played with the thought of detecting it at adapter init, but for that I'd need a card that has different behavior. Otherwise I am just shooting blind. The ones I tested (AMD Radeon 560; Geforce 650M; Intel HD 4000; Intel HD graphics 615; Apple M1; - the last 3 only on MacOS, the others Mac and Linux) behaved uniformly. I remember back in the Geforce 7/8 days we had GPU specific issues. Unfortunately my Geforce 7s all died and my r500 card is a long distance away.

Afaics we have no test that tests if we are doing the right thing in d3d9 and earlier. I'll add one, that should hopefully give some clues if the 63.0/128.0 is still correct on today's GPUs or if we need a flat 1.0/2.0 on some. If it's the former - and I am not aware of any d3d <= 9 games that have any pixel boundary issues right now - there might be some d3d9/d3d10 difference.

Henri Verbeet

9 Aug 9 Aug

3:47 p.m.

On Sat, 7 Aug 2021 at 09:00, Stefan Dösinger stefan@codeweavers.com wrote:

...

...
It seems a little awkward to tie this to WINED3D_PIXEL_CENTER_INTEGER. Would it make sense to instead detect the filling convention during adapter initialisation, so that we can get rid of this for d3d9 and before as well if possible? We could then just store the filling convention offset in the wined3d_d3d_info structure.

Yeah I played with the thought of detecting it at adapter init, but for that I'd need a card that has different behavior. Otherwise I am just shooting blind. The ones I tested (AMD Radeon 560; Geforce 650M; Intel HD 4000; Intel HD graphics 615; Apple M1; - the last 3 only on MacOS, the others Mac and Linux) behaved uniformly. I remember back in the Geforce 7/8 days we had GPU specific issues. Unfortunately my Geforce 7s all died and my r500 card is a long distance away.

Being able to detect the convention correctly would probably be a good start. (And note that originally part of the issue was that the filling convention ended up being different for onscreen and offscreen render targets due to the y-flip; "AlwaysOffscreen" got rid of at least that part of the issue.) I still have a NVIDIA Tesla I would be able to test this on, although I don't remember for sure whether it was originally affected by this issue. Perhaps others like e.g. Matteo would also be able to help with testing.

...

Afaics we have no test that tests if we are doing the right thing in d3d9 and earlier. I'll add one, that should hopefully give some clues if the 63.0/128.0 is still correct on today's GPUs or if we need a flat 1.0/2.0 on some. If it's the former - and I am not aware of any d3d <= 9 games that have any pixel boundary issues right now - there might be some d3d9/d3d10 difference.

Yeah, we don't have existing tests for this.

Stefan Dösinger

10 Aug 10 Aug

7:22 a.m.

Am Montag, 9. August 2021, 18:47:18 EAT schrieb Henri Verbeet:

...

On Sat, 7 Aug 2021 at 09:00, Stefan Dösinger stefan@codeweavers.com wrote:

...
Afaics we have no test that tests if we are doing the right thing in d3d9 and earlier. I'll add one, that should hopefully give some clues if the 63.0/128.0 is still correct on today's GPUs or if we need a flat 1.0/2.0 on some. If it's the former - and I am not aware of any d3d <= 9 games that have any pixel boundary issues right now - there might be some d3d9/d3d10 difference.

Yeah, we don't have existing tests for this.

Actually, d3d9's test_viewport is sensitive enough that it starts failing on Radeon-MacOS when I change the d3d9 offset to 1.0 (64.0 / 64.0, half a pixel thanks to the -1 to 1 NDC). On Linux with the same HW 1.0 is ok. Same things apply to the clip control version of viewport_miscpart.

So far all HW/OS combinations I tested pass the d3d9 test with the current 63/64 or 63/128 in the CC case, but need a flat 0.0 shift for d3d11's test (and World of Tanks). However, I now have two differently behaving drivers to try to detect some behavior difference. Not sure though if the difference matters for the bug I am trying to solve.

...

(And note that originally part of the issue was that the filling convention ended up being different for onscreen and offscreen render targets due to the y-flip; "AlwaysOffscreen" got rid of at least that part of the issue.)

Why did we use the not-quite-0.5-pixels shift in the X direction? We don't flip that one.

I remember the bug we tried to solve was Spore generating broken maps. It used to work on dx9 cards, broken on dx10 ones, then we fixed dx10 but broke dx9, and the 63/64 construct made both happy. I think we blamed it on some drivers implicitly rendering upside down in FBOs (and thus reverting our flip) while others did not do that. Sadly d3d9's visual.c readback is broken with backbuffer rendering, so I couldn't (yet) check if the y-flip still matters.

...

I still have a NVIDIA Tesla I would be able to test this on, although I don't remember for sure whether it was originally affected by this issue. Perhaps others like e.g. Matteo would also be able to help with testing.

I have one of those available too, and at least Windows and MacOS El Capitan. Not sure about the state of my Linux system on it, presumably I'll struggle with the EOL driver. What I don't have right now is a d3d9 or earlier GPU to compare to - my GeForce 7 died a while ago and my Radeon X1600 and Radeon 9000 Mobility are in Vienna.

Henri Verbeet

12:09 p.m.

On Tue, 10 Aug 2021 at 09:22, Stefan Dösinger stefan@codeweavers.com wrote:

...

Am Montag, 9. August 2021, 18:47:18 EAT schrieb Henri Verbeet:

...
On Sat, 7 Aug 2021 at 09:00, Stefan Dösinger stefan@codeweavers.com wrote:

...
Afaics we have no test that tests if we are doing the right thing in d3d9 and earlier. I'll add one, that should hopefully give some clues if the 63.0/128.0 is still correct on today's GPUs or if we need a flat 1.0/2.0 on some. If it's the former - and I am not aware of any d3d <= 9 games that have any pixel boundary issues right now - there might be some d3d9/d3d10 difference.

Yeah, we don't have existing tests for this.

Actually, d3d9's test_viewport is sensitive enough that it starts failing on Radeon-MacOS when I change the d3d9 offset to 1.0 (64.0 / 64.0, half a pixel thanks to the -1 to 1 NDC). On Linux with the same HW 1.0 is ok. Same things apply to the clip control version of viewport_miscpart.

So far all HW/OS combinations I tested pass the d3d9 test with the current 63/64 or 63/128 in the CC case, but need a flat 0.0 shift for d3d11's test (and World of Tanks). However, I now have two differently behaving drivers to try to detect some behavior difference. Not sure though if the difference matters for the bug I am trying to solve.

...
(And note that originally part of the issue was that the filling convention ended up being different for onscreen and offscreen render targets due to the y-flip; "AlwaysOffscreen" got rid of at least that part of the issue.)

Why did we use the not-quite-0.5-pixels shift in the X direction? We don't flip that one.

For the "left" part of "top-left"; we don't flip the x-axis, but we still want to make sure we get the convention Direct3D applications expect.

...

I remember the bug we tried to solve was Spore generating broken maps. It used to work on dx9 cards, broken on dx10 ones, then we fixed dx10 but broke dx9, and the 63/64 construct made both happy. I think we blamed it on some drivers implicitly rendering upside down in FBOs (and thus reverting our flip) while others did not do that. Sadly d3d9's visual.c readback is broken with backbuffer rendering, so I couldn't (yet) check if the y-flip still matters.

I think Everquest was also affected at some point.

...

...
I still have a NVIDIA Tesla I would be able to test this on, although I don't remember for sure whether it was originally affected by this issue. Perhaps others like e.g. Matteo would also be able to help with testing.

I have one of those available too, and at least Windows and MacOS El Capitan. Not sure about the state of my Linux system on it, presumably I'll struggle with the EOL driver. What I don't have right now is a d3d9 or earlier GPU to compare to - my GeForce 7 died a while ago and my Radeon X1600 and Radeon 9000 Mobility are in Vienna.

I'm running mine on Nouveau, for what it's worth. (Apple hardware, so it needs hacks for GPU switching, but it works.)

Matteo Bruni

12:41 p.m.

On Tue, Aug 10, 2021 at 2:10 PM Henri Verbeet hverbeet@gmail.com wrote:

...

On Tue, 10 Aug 2021 at 09:22, Stefan Dösinger stefan@codeweavers.com wrote:

...
Am Montag, 9. August 2021, 18:47:18 EAT schrieb Henri Verbeet:

...
On Sat, 7 Aug 2021 at 09:00, Stefan Dösinger stefan@codeweavers.com wrote:

...
Afaics we have no test that tests if we are doing the right thing in d3d9 and earlier. I'll add one, that should hopefully give some clues if the 63.0/128.0 is still correct on today's GPUs or if we need a flat 1.0/2.0 on some. If it's the former - and I am not aware of any d3d <= 9 games that have any pixel boundary issues right now - there might be some d3d9/d3d10 difference.

Yeah, we don't have existing tests for this.

Actually, d3d9's test_viewport is sensitive enough that it starts failing on Radeon-MacOS when I change the d3d9 offset to 1.0 (64.0 / 64.0, half a pixel thanks to the -1 to 1 NDC). On Linux with the same HW 1.0 is ok. Same things apply to the clip control version of viewport_miscpart.

So far all HW/OS combinations I tested pass the d3d9 test with the current 63/64 or 63/128 in the CC case, but need a flat 0.0 shift for d3d11's test (and World of Tanks). However, I now have two differently behaving drivers to try to detect some behavior difference. Not sure though if the difference matters for the bug I am trying to solve.

...
(And note that originally part of the issue was that the filling convention ended up being different for onscreen and offscreen render targets due to the y-flip; "AlwaysOffscreen" got rid of at least that part of the issue.)

Why did we use the not-quite-0.5-pixels shift in the X direction? We don't flip that one.

For the "left" part of "top-left"; we don't flip the x-axis, but we still want to make sure we get the convention Direct3D applications expect.

...
I remember the bug we tried to solve was Spore generating broken maps. It used to work on dx9 cards, broken on dx10 ones, then we fixed dx10 but broke dx9, and the 63/64 construct made both happy. I think we blamed it on some drivers implicitly rendering upside down in FBOs (and thus reverting our flip) while others did not do that. Sadly d3d9's visual.c readback is broken with backbuffer rendering, so I couldn't (yet) check if the y-flip still matters.

I think Everquest was also affected at some point.

Yeah, it was Everquest 2 the "trigger" for the AlwaysOffscreen setting.

WRT readback with backbuffer ORM, I have some patches around. I sent them a while back (https://www.winehq.org/pipermail/wine-devel/2021-March/182929.html the main one), they weren't quite proper but I could have another go at it.

...

...
...
I still have a NVIDIA Tesla I would be able to test this on, although I don't remember for sure whether it was originally affected by this issue. Perhaps others like e.g. Matteo would also be able to help with testing.

I have one of those available too, and at least Windows and MacOS El Capitan. Not sure about the state of my Linux system on it, presumably I'll struggle with the EOL driver. What I don't have right now is a d3d9 or earlier GPU to compare to - my GeForce 7 died a while ago and my Radeon X1600 and Radeon 9000 Mobility are in Vienna.

I'm running mine on Nouveau, for what it's worth. (Apple hardware, so it needs hacks for GPU switching, but it works.)

In theory I could run tests on a GeForce 4 Go (which is basically a GeForce 2 MX, fixed function only) on XP and Linux. Assuming it still works...

Stefan Dösinger

12:51 p.m.

...

Am 10.08.2021 um 15:09 schrieb Henri Verbeet hverbeet@gmail.com:

For the "left" part of "top-left"; we don't flip the x-axis, but we still want to make sure we get the convention Direct3D applications expect.

My head is flipping upside down every time I think too much about coordinate systems, but I think that's wrong. We aren't rotating everything by 180 degrees around z - we're flipping around the x axis, swapping front and back. As evidence, we have to adjust the winding order based on yflip.

If you twist a clock in such a way that it now runs counterclockwise and 6 is at the top and 12 at the bottom, then 9 will still be on the left and 3 on the right. Or like a mirror on the floor you are standing on. Your left and right will be alright, but suddenly your up and down are flipped and the watch will still run counterclockwise in the reflection. In the situation you are thinking of (6 top, 12 bottom, 3 left, 9 right) the clock still runs clockwise.

Am I missing something? I am sure that even if my thinking is right I've got some part of the explanation wrong...

Henri Verbeet

2:18 p.m.

On Tue, 10 Aug 2021 at 14:51, Stefan Dösinger stefan@codeweavers.com wrote:

...

...
Am 10.08.2021 um 15:09 schrieb Henri Verbeet hverbeet@gmail.com: For the "left" part of "top-left"; we don't flip the x-axis, but we still want to make sure we get the convention Direct3D applications expect.

My head is flipping upside down every time I think too much about coordinate systems, but I think that's wrong. We aren't rotating everything by 180 degrees around z - we're flipping around the x axis, swapping front and back. As evidence, we have to adjust the winding order based on yflip.

If you twist a clock in such a way that it now runs counterclockwise and 6 is at the top and 12 at the bottom, then 9 will still be on the left and 3 on the right. Or like a mirror on the floor you are standing on. Your left and right will be alright, but suddenly your up and down are flipped and the watch will still run counterclockwise in the reflection. In the situation you are thinking of (6 top, 12 bottom, 3 left, 9 right) the clock still runs clockwise.

Am I missing something? I am sure that even if my thinking is right I've got some part of the explanation wrong...

I don't think it's quite that complicated, but it probably helps to conceptually separate the half-pixel offset from the filling-convention offset. I.e., there are two translations involved (only considering d3d9 and the x-axis for now):

- We translate by 1/2 pixel to the right to account for pre-d3d10 pixel centres. - We translate by ε to the left, so that a triangle covering the right half of a pixel from top to bottom exactly through the pixel centre ends up generating a fragment for that pixel, and a triangle covering the left half of that pixel doesn't.

The total translation is then (1/2 - ε) to the right, independent of anything we do to the y-axis. Without WINED3D_PIXEL_CENTER_INTEGER the 1/2 pixel offset goes away, and we end up with just -ε. Now if we can detect that the OpenGL implementation already uses the Direct3D filling convention, we can instead simply use 1/2 as offset with WINED3D_PIXEL_CENTER_INTEGER, and 0 without.

Stefan Dösinger

12 Aug 12 Aug

4:55 p.m.

Am Dienstag, 10. August 2021, 17:18:31 EAT schrieb Henri Verbeet:

...

We translate by ε to the left, so that a triangle covering the

right half of a pixel from top to bottom exactly through the pixel centre ends up generating a fragment for that pixel, and a triangle covering the left half of that pixel doesn't.

Because we don't know what OpenGL is doing, i.e. it might generate a fragment if the pixel center is on a right edge of a triangle, either due to underspecification or driver bugs?

I was under the impression that GL guarantees a top-left filling rule (pixel is on a top edge OR on a left edge of a triangle -> generate fragment), but on further research the only place that states that (that I could find) is https://docs.microsoft.com/th-th/windows/win32/direct3d9/rasterization-rules , which isn't exactly an authoritative source on GL.

The rest of your explanation makes perfect sense to me.

The attached filling.c file is an attempt at detecting what the GL implementation does when rendering into an FBO. It correctly picks up the difference of the radeon driver on MacOS (radeon.png) - the only driver that doesn't pass the d3d9 viewport test with a precise 0.5 pixel shift. Other cards I tested result in the same output (intel.png, linux-noflip.png).

Sadly, while it does match up with with the d3d9 test, it doesn't match up with SPORE nor World of Tanks. World of Tanks wants no nudge everywhere, even the radeon card. SPORE is broken on MacOS regardless of what I try to do, but works on Linux-Radeon either with or without the nudge. I can deliberately break it everywhere by removing the half pixel offset, but that doesn't tell us anything we didn't already know.

So something else must be going on. My suspicions are that it has something to do with shaders vs fixed function or core vs legacy context. It is also possible that the issue is entirely unrelated, at least in World of Tanks.

The filling.c program also shows one place where the x nudge makes a difference when inverting the geometry: It flips the diagonal pixels back to the red triangle. The y nudge is (understandably) necessary to place the quad correctly nearer to the top of the texture rather than the bottom. I haven't yet found a card that generates a fragment when the center is on the right triangle edge.

Henri Verbeet

5:32 p.m.

On Thu, 12 Aug 2021 at 18:56, Stefan Dösinger stefan@codeweavers.com wrote:

...

Am Dienstag, 10. August 2021, 17:18:31 EAT schrieb Henri Verbeet:

...

We translate by ε to the left, so that a triangle covering the

right half of a pixel from top to bottom exactly through the pixel centre ends up generating a fragment for that pixel, and a triangle covering the left half of that pixel doesn't.

Because we don't know what OpenGL is doing, i.e. it might generate a fragment if the pixel center is on a right edge of a triangle, either due to underspecification or driver bugs?

I was under the impression that GL guarantees a top-left filling rule (pixel is on a top edge OR on a left edge of a triangle -> generate fragment), but on further research the only place that states that (that I could find) is https://docs.microsoft.com/th-th/windows/win32/direct3d9/rasterization-rules , which isn't exactly an authoritative source on GL.

Perhaps Windows imposes additional restrictions on GL, but as far as I'm aware the only thing the GL spec requires in this regard is the following:

Special treatment is given to a fragment whose center lies on a polygon edge. In such a case we require that if two polygons lie on either side of a common edge (with identical endpoints) on which a fragment center lies, then exactly one of the polygons results in the production of the fragment during rasterization.

(From 14.6.1 "Basic Polygon Rasterization" in the 4.6 spec.)

...

Sadly, while it does match up with with the d3d9 test, it doesn't match up with SPORE nor World of Tanks. World of Tanks wants no nudge everywhere, even the radeon card. SPORE is broken on MacOS regardless of what I try to do, but works on Linux-Radeon either with or without the nudge. I can deliberately break it everywhere by removing the half pixel offset, but that doesn't tell us anything we didn't already know.

So something else must be going on. My suspicions are that it has something to do with shaders vs fixed function or core vs legacy context. It is also possible that the issue is entirely unrelated, at least in World of Tanks.

Are we using shader offsets or ARB_clip_control/viewport offsets in the broken case? I wouldn't be entirely surprised if some drivers don't handle fractional viewport offsets entirely correctly. If possible, it may be worth trying to switch to the shader offset implementation to see if it makes any difference. Is there any multi-sampling or sample shading involved?

Note that I don't personally remember the Spore bug being about the filling convention; I remember the bug, but if you told me it was about the half-pixel offset instead I'd believe you.

Stefan Dösinger

8:01 p.m.

Am Donnerstag, 12. August 2021, 20:32:22 EAT schrieb Henri Verbeet:

...

Perhaps Windows imposes additional restrictions on GL, but as far as I'm aware the only thing the GL spec requires in this regard is the following:

<snip>

Ya, makes a lot more sense now why we have the x nudge too.

...

Are we using shader offsets or ARB_clip_control/viewport offsets in the broken case? I wouldn't be entirely surprised if some drivers don't handle fractional viewport offsets entirely correctly. If possible, it may be worth trying to switch to the shader offset implementation to see if it makes any difference. Is there any multi-sampling or sample shading involved?

I haven't made much sense of it yet. I tested both ways of applying the offset, so far I can't tell a difference. That said, on MacOS we disable clip_control because our test that checks for broken fractional viewport offset fails. (I think; I have to re-check why we don't have clip control, but for whatever reason, we don't have clip control on mac). Forcing clip control off on Linux doesn't break the game.

...

Note that I don't personally remember the Spore bug being about the filling convention; I remember the bug, but if you told me it was about the half-pixel offset instead I'd believe you.

It was both, I think. The way I remember it (and it's 13 years ago, so I might remember wrong): It used to work on Geforce 7 cards (and probably r500), but was broken on Geforce 8 cards. You added the half pixel offset thing to fix it (or added it for offscreen rendering, or something). That fixed it on geforce 8, but broke it on geforce 7. Adding the nudge some time later fixed it on both, or so we thought: https://bugs.winehq.org/show_bug.cgi?id=43708 says it still happens somewhere.

1230

Age (days ago)

1237

Last active (days ago)

wine-devel@winehq.org

18 comments

5 participants

tags (0)

participants (5)

Henri Verbeet
Henri Verbeet
Marvin
Matteo Bruni
Stefan Dösinger