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