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

[Paul Gofman]

On 3/10/20 12:16, Henri Verbeet wrote:
> 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.

So I suggest I do the following:

1. Use _LOCATION_RB_RESOLVED instead of draw_binding in texture2d_blt()
if otherwise it would result in scaled resolve, and maybe also when we
have blit operation other than WINED3D_BLIT_OP_COLOR_BLIT;

2. Introduce d3d_info->scaled_resolve, base it on
EXT_framebuffer_multisample_blit_scaled in GL adapter, and adjust the
condition in 1 if scaled_resolve is available.