Jose Fonseca <jfons...@vmware.com> writes: > ----- Original Message ----- >> The 'is_branch' TGSI opcode info flag was being interpreted >> incorrectly by tgsi_text.c as if it implied that the opcode requires >> a >> label token -- that's not the case on e.g. IF, BGNLOOP or ENDLOOP. > > IF, BGNLOOP or ENDLOOP used to have a label. And some old shaders still use > it, e.g., src/gallium/tests/graw/fs-write-z.c: > > " 0: MOV OUT[0], IN[0]\n" /* front-facing: red */ > " 1: IF IN[0].xxxx :3\n" > " 2: MOV OUT[1].z, IMM[2].yyyy\n" /* red: Z = 0.4 */ > " 3: ELSE :5\n" > " 4: MOV OUT[1].z, IMM[2].xxxx\n" /* blue: Z = 0.5 */ > " 5: ENDIF\n" > " 6: END\n"; > > But now, the only opcode that requires label arguments are CAL/CALLNZ I > believe. > Oh, I had no idea this had been the case before.
>> Add a new opcode info field that marks an opcode as requiring a TGSI >> label token, and replace the incorrect usage of 'is_branch' with it. > > Actually, instead of adding this new has_label, please simply modify > tgsi_text to consume a label when the next token ':', or ignore otherwise. > That is, make labels optional everywhere. > OK, I'll leave this patch out and make the parsing of labels optional in tgsi_text instead. > And please make sure that the tests in src/gallium/tests/graw still work > > Also, could you please describe what exactly the semantics of is_branch you > think are correct? > I had the impression it referred to the ability of an instruction to alter the flow of control. I.e. an instruction whose predecessor or successor aren't necessarily the lexical ones. > Jose > >
pgpmxiqBF5R2m.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
