[v2 PATCH 2/3] wined3d: Handle scale with multisampled destination in fbo_blitter_blit().

[Henri Verbeet]

On Mon, 9 Mar 2020 at 18:45, Paul Gofman <gofmanp at gmail.com> wrote:
> @@ -938,12 +938,17 @@ static DWORD fbo_blitter_blit(struct wined3d_blitter *blitter, enum wined3d_blit
>      {
>          TRACE("Colour blit.\n");
>
> -        /* Resolve the source surface first if needed. */
> -        if (wined3d_texture_gl_is_multisample_location(wined3d_texture_gl(src_texture), src_location)
> -                && (src_texture->resource.format->id != dst_texture->resource.format->id
> +        /* Resolve the source and destination surfaces if needed. */
> +        if (src_texture->resource.format->id != dst_texture->resource.format->id
>                  || abs(src_rect->bottom - src_rect->top) != abs(dst_rect->bottom - dst_rect->top)
> -                || abs(src_rect->right - src_rect->left) != abs(dst_rect->right - dst_rect->left)))
> -            src_location = WINED3D_LOCATION_RB_RESOLVED;
> +                || abs(src_rect->right - src_rect->left) != abs(dst_rect->right - dst_rect->left))
> +        {
> +            if (wined3d_texture_gl_is_multisample_location(wined3d_texture_gl(dst_texture), dst_location))
> +                dst_location = WINED3D_LOCATION_RB_RESOLVED;
> +
What initially bothered me about this is that it breaks the blitter
interface a little; i.e., a caller asking for a blit to
WINED3D_LOCATION_RB_MULTISAMPLE can potentially end up not getting a
an up-to-date WINED3D_LOCATION_RB_MULTISAMPLE. I think that still
works out in practice for all current callers, but it seems
undesirable in the long term. It would be easy enough to avoid that by
adding a wined3d_texture_load_location() call with the requested
destination location, but then that would introduce a potentially
redundant extra blit.

After giving it some more thought though, I'm wondering whether
perhaps the best option would be for texture2d_blt() to not request
scaled multi-sample blits in the first place, unless it knows that at
least one blitter can handle those. (I.e., introducing something like
"d3d_info->scaled_resolve".)