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

Henri Verbeet hverbeet at gmail.com
Tue Oct 5 10:13:15 CDT 2021


On Wed, 29 Sept 2021 at 21:43, Stefan Dösinger <stefan at codeweavers.com> 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"



More information about the wine-devel mailing list