Bug 25654

Summary:	glsl ifelse BranchTargets seem off
Product:	Mesa	Reporter:	Andre Maasikas <amaasikas>
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium
Version:	git
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Andre Maasikas 2009-12-15 01:33:39 UTC

For example: ./vp-tris -f ifelse.glsl
compiles to:
# Vertex Program/Shader 3
  0: MOV TEMP[1], INPUT[0];
  1: SLT.C TEMP[0].x, INPUT[0].xxxx, CONST[0].xxxx;
  2: IF (NE.xxxx); # (if false, goto 5);
  3:    MOV OUTPUT[1], CONST[1];
  4: ELSE; # (goto 8)
  5:    MOV OUTPUT[1], INPUT[3];
  6: ENDIF;
  7: MOV OUTPUT[0], TEMP[1];
  8: END

Seems if points one past the else statement and else points to
program end?
Also nestedifs.glsl shows somewhat similar behaviour.
r600 currently tries to emit a bit different code when no else
present and uses inst[BranchTarget] to determine presence.
Andre

Comment 1 Andre Maasikas 2009-12-15 02:31:56 UTC

Actually for r600 it was my problem, I used 
_mesa_init_instructions + _mesa_copy_instructions for rewrite
without adjusting branch targets and got inconsistent results.
Using _mesa_insert_instructions which does it correctly
seems to work ok for r600 for it's purposes.

Leaving as NEW though as it's a bit inconsistent in general
e'g for if-only the output is correct/logical :
  3: IF (NE.xxxx); # (if false, goto 5);
  4:    MOV OUTPUT[1], CONST[1];
  5: ENDIF;

Comment 2 Brian Paul 2009-12-22 13:25:51 UTC

OK, I've fixed this issue in Mesa/master, commit 428d81c8b78f5919b42debd9215c40d05a42cba0

Example:
 27: IF TEMP[0].zzzz;  # (if false, goto 29);
 28:    MOV OUTPUT[1], CONST[4];
 29: ELSE; # (goto 31)
 30:    MOV OUTPUT[1], CONST[5];
 31: ENDIF;

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.