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

[Henri Verbeet]

On Tue, 10 Mar 2020 at 12:15, Paul Gofman <gofmanp at gmail.com> wrote:
> On 3/10/20 11:11, Henri Verbeet wrote:
> > 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.
>
> An extra wined3d_texture_load_location() for requested destintation
> location was introduced in the first version when resolve was in
> texture2d_blt_fbo(), but I thought one of the reasons it is actually
> better to do in fbo_blitter_blit() is that we can avoid that. Doesn't
> dst_location returned from blitter have the purpose to give us some
> flexibility to leave the different dst_location?
>
Somewhat, the original idea was that it allows the blitter to return
additional locations that ended up being validated as a result of the
blit, so that the caller can avoid invalidating those.

> > 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".)
>
> I am not sure I fully understand. Currently fbo blitter thinks it can
> always handle that, just does it wrong when the destination texture is
> also multisampled. GLSL blitter does not support support source
> multisampled textures, but should be fine with multisampled destination.
> Do you mean to just do not support scaled resolves in FBO blitter, or do
> not support if EXT_framebuffer_multisample_blit_scaled is not available
> (if it is available, we still need to resolve destination texture)?
>
In texture2d_blt(), we use "texture->resource.draw_binding" as
source/destination location for textures with
WINED3D_RESOURCE_ACCESS_GPU, but we don't necessarily have to do that.
If we instead used WINED3D_LOCATION_RB_RESOLVED in the appropriate
cases, the blitters wouldn't need to deal with scaled resolves. Using
EXT_framebuffer_multisample_blit_scaled when available may still be
advantageous, particularly when using ARB_texture_multisample, but
blitter support for scaled resolves would be optional in that case.

> As a separate question, if no blitter is decided to be able to handle
> scaled resolve, should texture2d_blt() do the resolve first and then
> scaled blit?
>
Where needed, resolves would happen implicitly by using
WINED3D_LOCATION_RB_RESOLVED as source/destination locations.