[Mesa-dev] [PATCH 1/2] r600g: report correct flow control depth, taking hardware bugs into account

[Vadim Girlin]

On 02/01/2013 03:20 AM, Marek Olšák wrote:
> ---
>   src/gallium/drivers/r600/r600_pipe.c |    9 +++++++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/r600/r600_pipe.c b/src/gallium/drivers/r600/r600_pipe.c
> index a59578d..1698cb3 100644
> --- a/src/gallium/drivers/r600/r600_pipe.c
> +++ b/src/gallium/drivers/r600/r600_pipe.c
> @@ -640,6 +640,8 @@ static float r600_get_paramf(struct pipe_screen* pscreen,
>
>   static int r600_get_shader_param(struct pipe_screen* pscreen, unsigned shader, enum pipe_shader_cap param)
>   {
> +	struct r600_screen *rscreen = (struct r600_screen *)pscreen;
> +
>   	switch(shader)
>   	{
>   	case PIPE_SHADER_FRAGMENT:
> @@ -654,7 +656,6 @@ static int r600_get_shader_param(struct pipe_screen* pscreen, unsigned shader, e
>   		return 0;
>   	}
>
> -	/* XXX: all these should be fixed, since r600 surely supports much more! */
>   	switch (param) {
>   	case PIPE_SHADER_CAP_MAX_INSTRUCTIONS:
>   	case PIPE_SHADER_CAP_MAX_ALU_INSTRUCTIONS:
> @@ -662,7 +663,11 @@ static int r600_get_shader_param(struct pipe_screen* pscreen, unsigned shader, e
>   	case PIPE_SHADER_CAP_MAX_TEX_INDIRECTIONS:
>   		return 16384;
>   	case PIPE_SHADER_CAP_MAX_CONTROL_FLOW_DEPTH:
> -		return 8; /* XXX */
> +		/* There is a bug on certain Evergreen cards which limits
> +		 * the control flow depth. */
> +		return rscreen->chip_class == EVERGREEN &&
> +		       rscreen->family != CHIP_CYPRESS &&
> +		       rscreen->family != CHIP_HEMLOCK ? 3 : 32;

I guess we can use more strict condition regarding the affected chips if 
the bug description in the evergreen isa pdf is correct ("Chapter 4. ALU 
Clauses"):

> NOTE: For the 54xx and 55xx AMD GPU series only, the CF_INST_ALU*
> instructions do not save the active mask correctly. The branching can be wrong,
> possibly producing incorrect results and infinite loops. The three possible work-
> arounds are:
>
> a. Avoid using the CF_ALU_PUSH_BEFORE, CF_ALU_ELSE_AFTER
> CF_ALU_BREAK, and CF_ALU_CONTINUE instructions.
> b. Do not use the CF_INST_ALU* instructions when your stack depth
> exceeds three elements (not entries); for the 54XX series AMD GPUs,
> do not exceed a stack size of seven, since this GPU series has a vector
> size 32.
> c. Do not use these instructions when your non-zero stack depth mod 4 is
> 0 (or mod 8 is 0, for vector size 32).

E.g. it seems juniper isn't affected according to the doc.

Also I'm not sure how the meaning of the "max control flow depth" in 
gallium maps to the hw's meaning - I suspect each loop is counted as a 
single level, but hw uses 4 or 8 stack elements (subentries) per loop 
(EG ISA PDF, Section "3.6.5 Stack Allocation"). So it seems we can't use 
ALU_xxx instructions even in a single top-level loop on affected chips, 
if I understand it right.

Vadim


>   	case PIPE_SHADER_CAP_MAX_INPUTS:
>   		return 32;
>   	case PIPE_SHADER_CAP_MAX_TEMPS:
>