[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