Re: [PATCH 2/4] wined3d: Test if a nudge is needed to get the correct filling convention (v2).

[Henri Verbeet]

On Wed, 29 Sept 2021 at 21:43, Stefan Dösinger  wrote:
> diff --git a/dlls/wined3d/adapter_gl.c b/dlls/wined3d/adapter_gl.c
> index bba728e2fb5..386d26828dc 100644
> --- a/dlls/wined3d/adapter_gl.c
> +++ b/dlls/wined3d/adapter_gl.c
> @@ -5134,6 +5134,7 @@ static void wined3d_adapter_gl_init_d3d_info(struct wined3d_adapter_gl *adapter_
>      d3d_info->scaled_resolve = !!gl_info->supported[EXT_FRAMEBUFFER_MULTISAMPLE_BLIT_SCALED];
>      d3d_info->pbo = !!gl_info->supported[ARB_PIXEL_BUFFER_OBJECT];
>      d3d_info->feature_level = feature_level_from_caps(gl_info, &shader_caps, &fragment_caps);
> - d3d_info->filling_convention_nudge = gl_info->filling_convention_nudge;

"filling_convention_offset", perhaps.
> +static float wined3d_adapter_find_fill_nudge(struct wined3d_caps_gl_ctx *ctx)
> +{
> - static const float test_array[] =
> - {
> -
>    0.0f,
> -
>    -1.0f / 1024.0f,
> -
>    -1.0f / 512.0f,
> -
>    -1.0f / 256.0f,
> -
>    -1.0f / 128.0f,
> -
>    -1.0f / 64.0f
> - };
> - unsigned int good = ARRAY_SIZE(test_array), bad = 0, test;
> - float value;
> -
> - if (wined3d_settings.offscreen_rendering_mode != ORM_FBO)
> -
>    goto end;
> -
> - while (good != bad)
> - {
> -
>    test = (good + bad) / 2;
> -
>    value = test_array[test];
> -
>    TRACE("Good %u bad %u, test %u.\n", good, bad, test);
> -
>    if (wined3d_caps_gl_ctx_test_filling_convention(ctx, value))
> -
>        good = test;
> -
>    else
> -
>        bad = test + 1;
> - }
> -

I generally prefer something along the lines of "upper"/"lower" for
these. Not in the least because in some cases "bad" is the value we
actually end up using.
> - if (good < ARRAY_SIZE(test_array))
> - {
> -
>    value = test_array[good];
> -
>    if (value)
> -
>        WARN("Using a filling convention fixup nudge of -1/%f.\n", -1.0f / value);
> -
>    else
> -
>        TRACE("No need for a filling convetion nudge.\n");
> -

"convention"
> - /* Like GL, Vulkan doesn't explicitly specify a filling convention and only mandates that a
> -
> * shared edge of two adjacent triangles generate a fragment for exactly one of the triangles.
> -
> * vktRasterizationTests.cpp from the vulkan CTS tests this by drawing two triangles with a
> -
> * shared edge with additive blending.
> -
> *

I don't think the bit about the CTS is especially pertinent.
> -
> * However, every Vulkan implementation we have seen so far uses a top-left rule. Hardware
> -
> * that differs either predates Vulkan (d3d9 class HW, GeForce 9xxx) or behaves the way we
> -
> * want in Vulkan (MacOS Radeon driver through MoltenVK). */
> - d3d_info->filling_convention_nudge = 0.0;
> -

"0.0f"
> - /* This is a very simple test to find out how GL handles polygon edges:
> -
> * Draw a quad exactly through 4 pixel centers in an 8x8 viewport and see
> -
> * which pixel it ends up in. So far we've seen top left and bottom

The first time I read this, my thought was "shouldn't that be
'pixels'?". The trick of course is that we're drawing a 1x1 quad
through 4 adjacent pixel centres.
> - /* One pixel was drawn, check if it is the expect one */
> - return readback[3][3] == 0xffff0000;

"expected"