On Thu, Dec 11, 2014 at 2:34 PM, Eduardo Lima Mitev <el...@igalia.com> wrote: > From: Iago Toral Quiroga <ito...@igalia.com> > > For code such as this in a vertex or fragment shader: > > uniform float in0; > flat out float out0; > ... > out0 = ceil(in0) > > We generate this IR: > > (assign (x) (var_ref packed:out0) > (expression int bitcast_f2i > (expression float ceil (var_ref in0) ) ) ) > > In i965, this would eventually become: > > rndd(8) g14<1>.xF -g3<0,4,1>.xF > mov(8) g6<1>.xD -g14<4,4,1>.xD > mov(8) g116<1>D g6<4,4,1>D > > which does not produce the expected result. > > The problem has to do with the second instruction, that changes the > type to D at the same time it does the negate. For this to work we > need to negate first with the original type, then change the type > to the bitcast destination so we produce code like this instead: > > rndd(8) g14<1>.xF -g3<0,4,1>.xF > mov(8) g6<1>.xF -g14<4,4,1>.xF > mov(8) g116<1>D g6<4,4,1>D
I found and fixed a problem (in commit 0ae9ca12a8) last year where we would put move the source modifiers out of the bitcast_*(...). In that commit, I just emit a MOV to do the source modifier as a separate step, and then let copy propagation handle getting rid of it when possible. It looks like I didn't notice that ceil also does the in place op[0].negate = !op[0].negate. Instead of special casing the bit cast functions, we should just emit the extra MOV in ceil and let copy propagation clean it up when possible. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
