gallium/u_blitter: clean up texcoords ZW when filling up just XY

To avoid a scenario like this:
  * One blit needed the four components => XYZW filled up with 4 values
  * Following blit needing two components => ZW uses the previous values

We detected this using the v3d driver with the
arb_framebuffer_srgb-blit test, specifically:

  ./bin/arb_framebuffer_srgb-blit texture linear_to_srgb msaa enabled render -auto -fbo

The main linear to srgb with msaa (not doing the resolve yet) blit
requires the four components.

At the end (after a resolve copy), the test uses glReadPixels, and
internally it uses the blitter with two components, but the shader
still uses lod on the texel fetch, so it gets the one used for the
main blit, when it should be zero.

Right now v3d works fine even with that wrong value, and I assume that
any other driver too. But we can't ensure that would keep happening on
the future, so let's use correct values.

Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13753>
This commit is contained in:
Alejandro Piñeiro 2021-11-11 13:04:36 +01:00
parent 59860d4873
commit fef9ef48dd
1 changed files with 9 additions and 1 deletions

View File

@ -1424,8 +1424,16 @@ void util_blitter_draw_rectangle(struct blitter_context *blitter,
ctx->vertices[i][1][2] = attrib->texcoord.z;
ctx->vertices[i][1][3] = attrib->texcoord.w;
}
FALLTHROUGH;
set_texcoords_in_vertices(attrib, &ctx->vertices[0][1][0], 8);
break;
case UTIL_BLITTER_ATTRIB_TEXCOORD_XY:
/* We clean-up the ZW components, just in case we used before XYZW,
* to avoid feeding in the shader with wrong values (like on the lod)
*/
for (i = 0; i < 4; i++) {
ctx->vertices[i][1][2] = 0;
ctx->vertices[i][1][3] = 0;
}
set_texcoords_in_vertices(attrib, &ctx->vertices[0][1][0], 8);
break;