On Mon, 9 Mar 2020 at 18:45, Paul Gofman <gofmanp(a)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".)