https://bugs.freedesktop.org/show_bug.cgi?id=85376
--- Comment #10 from Ilia Mirkin <imirkin at alum.mit.edu> --- Some observations (from IRC, edited): In shader 21 (from attachment 109303), we see the following: <imirkin_> MULLO_INT R5.x, [0x00000046 9.80909e-44].x, PV.x <imirkin_> MULLO_INT R5.y, [0x00000078 1.68156e-43].x, PV.x <imirkin_> that seems wrong <imirkin_> the second PV.x uses the newly computed R5.x, no? <imirkin_> instead of the previous R5.x before the mul happened <imirkin_> so the 2nd and 3rd components get the compounded multiplication factor of .x and the respective .y and .z factor <tstellar> Starting with the R5.x value returned by the ADD_INT, the caluclation is: R5.y = ((R5.x *46) * 78); R5.z = (R5.x * 46) * 0xc8 <imirkin_> 6: UMUL TEMP[1].xyz, IMM[0].yzww, TEMP[1].xxxx <imirkin_> i'm guessing the thing that splits it up into 3 instructions forgets that it's overwriting the source <imirkin_> cayman_mul_int_instr <imirkin_> cayman-specific, and doesn't do the tmp register dance vs the "regular" umul implementation (op2_trans) which will use a temp register if the dst mask has multiple dests. I wonder if all the cayman_* emit functions need this treatment. -- You are receiving this mail because: You are the assignee for the bug. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141111/d07f5e0c/attachment.html>
