v3d: take into account separate_stencil when checking if stencil should be cleared

In most cases this is not needed because the usual is that when a
separate stencil is written, the parent resource is also written.

This is needed if we have a separate stencil, no depth buffer, and the
source and destination is the same, as in that case the stencil can be
updated, but not the parent source (like if you are blitting only the
stencil buffer). On that situation, the following access to the
stencil buffer would clear the stencil buffer (so overwritting the
previous blitting) cleared because the parent source has
v3d_resource.writes to 0.

As far as I see, that situation only happens with the
GL_DEPTH32F_STENCIL8 format.

Note that one alternative would consider that if the separate_stencil
has been written, the parent should also be considered written (and
update its "writes" field accordingly). But I found this patch more
natural.

Fixes the following piglit tests:
   spec/arb_depth_buffer_float/fbo-stencil-gl_depth32f_stencil8-blit
   spec/arb_depth_buffer_float/fbo-stencil-gl_depth32f_stencil8-copypixels

the latter regressed when internally glCopyPixels implementation
started to use blitting. So:

Fixes: 131d40cfc9 ("st/mesa: accelerate glCopyPixels(STENCIL)")

Reviewed-by: Eric Anholt <eric@anholt.net>

src/gallium/drivers/v3d/v3d_job.c

@@ -384,7 +384,13 @@ v3d_get_job_for_fbo(struct v3d_context *v3d)
         if (zsbuf) {
                 struct v3d_resource *rsc = v3d_resource(zsbuf->texture);
                 if (!rsc->writes)
-                        job->clear |= PIPE_CLEAR_DEPTH | PIPE_CLEAR_STENCIL;
+                        job->clear |= PIPE_CLEAR_DEPTH;
+
+                if (rsc->separate_stencil)
+                        rsc = rsc->separate_stencil;
+
+                if (!rsc->writes)
+                        job->clear |= PIPE_CLEAR_STENCIL;
         }
 
         job->draw_tiles_x = DIV_ROUND_UP(v3d->framebuffer.width,