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:


_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to