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
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;
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.