Comment # 10
on bug 85376
from Ilia Mirkin
Some observations (from IRC, edited):
In shader 21 (from attachment 109303 [details]), 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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
