On Tue, 10 Mar 2020 at 12:15, Paul Gofman gofmanp@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.