# 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
}
}
+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)
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?
*/