From 1fa43a4a8ec37aacac4d333a4c72987819188e69 Mon Sep 17 00:00:00 2001 From: Rob Clark Date: Fri, 21 Aug 2020 15:58:37 -0700 Subject: [PATCH] freedreno: handle case of shadowing current render target If you have a sequence where there is a single buffer associated with the current render target, and then you end up shadowing it on the 3d pipe (u_blitter), because of how we swap the new shadow and rsc before the back-blit, you could end up confusing things into thinking that the blitters framebuffer state is the same as the current framebuffer state. Re-organizing the sequence to swap after the blit is complicated when also having to deal with CPU memcpy blit path, and the batch/rsc accounting. So instead just detect this case and flush if we need to. Fixes: dEQP-GLES31.functional.stencil_texturing.render.depth24_stencil8_clear dEQP-GLES31.functional.stencil_texturing.render.depth24_stencil8_draw Cc: mesa-stable@lists.freedesktop.org Signed-off-by: Rob Clark Part-of: --- .gitlab-ci/deqp-freedreno-a630-fails.txt | 2 -- .../drivers/freedreno/freedreno_resource.c | 18 ++++++++++++++++++ 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/.gitlab-ci/deqp-freedreno-a630-fails.txt b/.gitlab-ci/deqp-freedreno-a630-fails.txt index 93887266e80..5808696ec51 100644 --- a/.gitlab-ci/deqp-freedreno-a630-fails.txt +++ b/.gitlab-ci/deqp-freedreno-a630-fails.txt @@ -1,8 +1,6 @@ # Possibly https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/2035 related dEQP-GLES2.functional.clipping.triangle_vertex.clip_three.clip_neg_x_neg_z_and_pos_x_pos_z_and_neg_x_neg_y_pos_z -dEQP-GLES31.functional.stencil_texturing.render.depth24_stencil8_clear -dEQP-GLES31.functional.stencil_texturing.render.depth24_stencil8_draw dEQP-VK.binding_model.descriptorset_random.sets4.constant.ubolimitlow.sbolimithigh.imglimithigh.noiub.uab.frag.ialimitlow.0 dEQP-VK.draw.output_location.array.b8g8r8a8-unorm-mediump-output-vec3 dEQP-VK.glsl.linkage.varying.struct.mat3x2 diff --git a/src/gallium/drivers/freedreno/freedreno_resource.c b/src/gallium/drivers/freedreno/freedreno_resource.c index ed7daaaf63a..ddc74481026 100644 --- a/src/gallium/drivers/freedreno/freedreno_resource.c +++ b/src/gallium/drivers/freedreno/freedreno_resource.c @@ -218,6 +218,9 @@ do_blit(struct fd_context *ctx, const struct pipe_blit_info *blit, bool fallback } } +static void +flush_resource(struct fd_context *ctx, struct fd_resource *rsc, unsigned usage); + /** * @rsc: the resource to shadow * @level: the level to discard (if box != NULL, otherwise ignored) @@ -235,6 +238,21 @@ fd_try_shadow_resource(struct fd_context *ctx, struct fd_resource *rsc, if (prsc->next) return false; + /* If you have a sequence where there is a single rsc associated + * with the current render target, and then you end up shadowing + * that same rsc on the 3d pipe (u_blitter), because of how we + * swap the new shadow and rsc before the back-blit, you could end + * up confusing things into thinking that u_blitter's framebuffer + * state is the same as the current framebuffer state, which has + * the result of blitting to rsc rather than shadow. + * + * Normally we wouldn't want to unconditionally trigger a flush, + * since that defeats the purpose of shadowing, but this is a + * case where we'd have to flush anyways. + */ + if (rsc->write_batch == ctx->batch) + flush_resource(ctx, rsc, 0); + /* TODO: somehow munge dimensions and format to copy unsupported * render target format to something that is supported? */ -- 2.30.2