[Mesa-dev] [PATCH 27/30] r600g: calculate a better value for array_size

Grigori Goronzy greg at chown.ath.cx
Tue Feb 4 15:19:00 CET 2014


On 04.02.2014 00:53, Dave Airlie wrote:
> From: Dave Airlie <airlied at redhat.com>
>
> attempt to calculate a better value for array size to avoid breaking apps.
>
> 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 8fa7054..f0e980b 100644
> --- a/src/gallium/drivers/r600/r600_shader.c
> +++ b/src/gallium/drivers/r600/r600_shader.c
> @@ -1416,7 +1416,7 @@ static int emit_gs_ring_writes(struct r600_shader_ctx *ctx, bool ind)
>
>   		if (ind) {
>   			output.array_base = ring_offset >> 2; /* in dwords */
> -			output.array_size = 0xff
> +			output.array_size = ctx->shader->gs_max_out_vertices * 4;

array_size is 12 bits in size. It overflows when gs_max_out_vertices is 
set to 1024, and no vertices will be written at all. I don't believe 
it's safe to assume a fixed output size per vertex either. This easily 
breaks GSVS writes in case there are many vertex attributes.

Is there anything wrong with just setting array_size to the maximum, 
0xfff? streamout does the same thing.

>   			output.index_gpr = ctx->gs_export_gpr_treg;
>   		} else
>   			output.array_base = ring_offset >> 2; /* in dwords */
>



More information about the mesa-dev mailing list