On Fri, 2014-12-12 at 09:36 -0800, Matt Turner wrote: > 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.
Thanks Matt, I'll do this and send a new version. Iago _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
