[Mesa-dev] [PATCH 18/20] radeonsi: force the DCC enable bit off in image descriptors for writing

Marek Olšák maraeo at gmail.com
Sat Mar 19 22:35:36 UTC 2016


On Tue, Mar 15, 2016 at 7:29 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote:
> From: Nicolai Hähnle <nicolai.haehnle at amd.com>
>
> This avoids a lockup at least on Tonga.
> ---
>  src/gallium/drivers/radeonsi/si_shader.c | 53 +++++++++++++++++++++++++++-----
>  1 file changed, 45 insertions(+), 8 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c b/src/gallium/drivers/radeonsi/si_shader.c
> index 03dc496..37a27a2 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -2764,12 +2764,37 @@ static bool tgsi_is_array_image(unsigned target)
>  }
>
>  /**
> + * Given a 256-bit resource descriptor, force the DCC enable bit to off.
> + *
> + * At least on Tonga, executing image stores on images with DCC enabled and
> + * non-trivial can eventually lead to lockups. This can occur when an
> + * application binds an image as read-only but then uses a shader that writes
> + * to it. The OpenGL spec allows almost arbitrarily bad behavior (including
> + * program termination) in this case, but it doesn't cost much to be a bit
> + * nicer: disabling DCC in the shader still leads to undefined results but
> + * avoids the lockup.
> + */
> +static LLVMValueRef force_dcc_off(struct si_shader_context *ctx,
> +                                 LLVMValueRef rsrc)
> +{
> +       LLVMBuilderRef builder = ctx->radeon_bld.gallivm.builder;
> +       LLVMValueRef i32_6 = LLVMConstInt(ctx->i32, 6, 0);
> +       LLVMValueRef i32_C = LLVMConstInt(ctx->i32, C_008F28_COMPRESSION_EN, 0);
> +       LLVMValueRef tmp;
> +
> +       tmp = LLVMBuildExtractElement(builder, rsrc, i32_6, "");
> +       tmp = LLVMBuildAnd(builder, tmp, i32_C, "");
> +       return LLVMBuildInsertElement(builder, rsrc, tmp, i32_6, "");

This can just return the descriptor as-is if the chip family is SI or
CIK, which don't support DCC.

Marek


More information about the mesa-dev mailing list