[Mesa-dev] [PATCH] r600g: fix regression since UCMP change

Roland Scheidegger sroland at vmware.com
Mon Dec 8 21:44:31 PST 2014


Am 09.12.2014 um 02:31 schrieb Dave Airlie:
> From: Dave Airlie <airlied at redhat.com>
> 
> Since d8da6deceadf5e48201d848b7061dad17a5b7cac where the
> state tracker started using UCMP on cayman a number of tests
> regressed.
> 
> this seems to be r600g is doing CNDGE_INT for UCMP which is >= 0,
> we should be doing CNDE_INT with reverse arguments.
> 
> Signed-off-by: Dave Airlie <airlied at redhat.com>
> ---
>  src/gallium/drivers/r600/r600_shader.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/gallium/drivers/r600/r600_shader.c b/src/gallium/drivers/r600/r600_shader.c
> index 0b988df..28137e1 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -6082,7 +6082,7 @@ static int tgsi_ucmp(struct r600_shader_ctx *ctx)
>  			continue;
>  
>  		memset(&alu, 0, sizeof(struct r600_bytecode_alu));
> -		alu.op = ALU_OP3_CNDGE_INT;
> +		alu.op = ALU_OP3_CNDE_INT;
>  		r600_bytecode_src(&alu.src[0], &ctx->src[0], i);
>  		r600_bytecode_src(&alu.src[1], &ctx->src[2], i);
>  		r600_bytecode_src(&alu.src[2], &ctx->src[1], i);
> 

Oh, the state tracker used UCMP before (for triop_csel), which is also
why I didn't even think about checking drivers if they do the right
thing... But possibly only with true booleans, so you'd have got only 0
and -1 as input (though I have no idea again if you'd actually see such
ops at all from glsl). So maybe it was the optimization to try to avoid
the extra comparison if it was a equal/not equal comparison against 0
which caused this indeed :-).

Looks good in any case.

Roland



More information about the mesa-dev mailing list