Difference between revisions of "Talk:GPU/Internal Registers"
Line 2: | Line 2: | ||
@Steveice: <s>Regarding the recent GPUREG_SH_BOOLUNIFORM confusion, I agree that your version is the more sensible variant. However, note that technically it depends on the semantics defined in [[Shader_Instruction_Set#Comparison_operator]]: Switching between your version (0=false) and the original one (1=false) is equivalent to e.g. replacing the CONDOP=0 semantic " cmp.x == REFX || cmp.y == REFY " with " !cmp.x == REFX || !cmp.y == REFY". In other words, this change implicltly changed the documented semantics of shader conditions. Hence I wonder whether the Shader Instruction Set needs any adjustments with the new documentation on GPUREG_SH_BOOLUNIFORM. </s> Actually, I mixed up stuff. What actually would need to be fixed up is the semantics of IFU, but that would yield a counterintuitive notion of conditional execution. [[User:Neobrain|Neobrain]] 19:55, 5 December 2015 (CET) | @Steveice: <s>Regarding the recent GPUREG_SH_BOOLUNIFORM confusion, I agree that your version is the more sensible variant. However, note that technically it depends on the semantics defined in [[Shader_Instruction_Set#Comparison_operator]]: Switching between your version (0=false) and the original one (1=false) is equivalent to e.g. replacing the CONDOP=0 semantic " cmp.x == REFX || cmp.y == REFY " with " !cmp.x == REFX || !cmp.y == REFY". In other words, this change implicltly changed the documented semantics of shader conditions. Hence I wonder whether the Shader Instruction Set needs any adjustments with the new documentation on GPUREG_SH_BOOLUNIFORM. </s> Actually, I mixed up stuff. What actually would need to be fixed up is the semantics of IFU, but that would yield a counterintuitive notion of conditional execution. [[User:Neobrain|Neobrain]] 19:55, 5 December 2015 (CET) | ||
+ | |||
+ | The behaviour of the ifu command actually suggests 0=true and 1=false. Earlier today, upon seeing the change in the wiki, I did tests with the command. It turned out the positive block is executed when the bit is cleared, and the negative block is executed when the bit is set; as it was previously documented. Note the wording in the Shader Instruction Set page: "If condition BOOL is true, then executes instructions until DST, then jumps to DST+NUM; else, jumps to DST." --[[User:Fincs|Fincs]] 20:15, 5 December 2015 (CET) |
Revision as of 20:15, 5 December 2015
FYI, fixed-point numbers are often denoted as "fixedX.Y", with X the non-fractional and Y the fractional bits. Also note that one wouldn't speak about "fixed-point" numbers when Y=0 (just say "X-bit integer" instead). I found the latter a bit confusing in the recent changes, since it sounded like "Z bias" was a fixed-point number with unspecified fractional bits. Neobrain 12:07, 3 December 2015 (CET)
@Steveice: Regarding the recent GPUREG_SH_BOOLUNIFORM confusion, I agree that your version is the more sensible variant. However, note that technically it depends on the semantics defined in Shader_Instruction_Set#Comparison_operator: Switching between your version (0=false) and the original one (1=false) is equivalent to e.g. replacing the CONDOP=0 semantic " cmp.x == REFX || cmp.y == REFY " with " !cmp.x == REFX || !cmp.y == REFY". In other words, this change implicltly changed the documented semantics of shader conditions. Hence I wonder whether the Shader Instruction Set needs any adjustments with the new documentation on GPUREG_SH_BOOLUNIFORM. Actually, I mixed up stuff. What actually would need to be fixed up is the semantics of IFU, but that would yield a counterintuitive notion of conditional execution. Neobrain 19:55, 5 December 2015 (CET)
The behaviour of the ifu command actually suggests 0=true and 1=false. Earlier today, upon seeing the change in the wiki, I did tests with the command. It turned out the positive block is executed when the bit is cleared, and the negative block is executed when the bit is set; as it was previously documented. Note the wording in the Shader Instruction Set page: "If condition BOOL is true, then executes instructions until DST, then jumps to DST+NUM; else, jumps to DST." --Fincs 20:15, 5 December 2015 (CET)