I see. Fair point. Marek
On Thu, Apr 4, 2013 at 7:32 PM, Roland Scheidegger <srol...@vmware.com>wrote: > Well if the condition is just "any bit set" then it doesn't matter if > the input is a float or int or whatever (of course, for floats, that > definition is different than != zero, as it doesn't hold for negative > zero). > That would be the same as for instance the bitwise instructions which > also don't have a "U" or "I" prefix. > > Roland > > Am 04.04.2013 18:49, schrieb Marek Olšák: > > FWIW, I think UCMP is a misleading name. Whatever the name will be, it > > should be prefixed with "I" or "U", because it's not a floating-point > > opcode. How about UCND? :D > > > > Marek > > > > > > On Thu, Apr 4, 2013 at 6:23 PM, Jose Fonseca <jfons...@vmware.com > > <mailto:jfons...@vmware.com>> wrote: > > > > There might be some value in renaming UCMP to be MOVC though. I > > think everybody here can agree that UCMP, though semantically > > correct, is misleading. > > > > Jose > > > > ----- Original Message ----- > > > Hah, yea, I'm sorry, that's a good point. So movc is a bitcast to > > unsigned > > > followed by ucmp. Alright, I'm withdrawing the patch. > > > > > > z > > > > > > ----- Original Message ----- > > > > > > > > > > > > ----- Original Message ----- > > > > > > > Erm, unsigned < 0 doesn't make sense. > > > > > > > > > > > > Ah indeed! > > > > > > > > > > > > > Definitely what the description says: > > > > > > > static void > > > > > > > micro_ucmp(union tgsi_exec_channel *dst, > > > > > > > const union tgsi_exec_channel *src0, > > > > > > > const union tgsi_exec_channel *src1, > > > > > > > const union tgsi_exec_channel *src2) > > > > > > > { > > > > > > > dst->u[0] = src0->u[0] ? src1->u[0] : src2->u[0]; > > > > > > > dst->u[1] = src0->u[1] ? src1->u[1] : src2->u[1]; > > > > > > > dst->u[2] = src0->u[2] ? src1->u[2] : src2->u[2]; > > > > > > > dst->u[3] = src0->u[3] ? src1->u[3] : src2->u[3]; > > > > > > > } > > > > > > > > > > > > > > or > > > > > > > > > > > > > > case TGSI_OPCODE_UCMP: > > > > > > > case TGSI_OPCODE_CMP: > > > > > > > FOR_EACH_DST_ENABLED_CHANNEL(0, c, tgsi) { > > > > > > > src0 = fetchSrc(0, c); > > > > > > > src1 = fetchSrc(1, c); > > > > > > > src2 = fetchSrc(2, c); > > > > > > > if (src1 == src2) > > > > > > > mkMov(dst0[c], src1); > > > > > > > else > > > > > > > mkCmp(OP_SLCT, (srcTy == TYPE_F32) ? > > CC_LT(less than 0) : > > > > > > > CC_NE(not equal 0), > > > > > > > srcTy, dst0[c], src1, src2, src0); > > > > > > > } > > > > > > > > > > > > > > > > > > > But odd enough, the implementations I happend to look at > > seemed to do > > > > > > "foo > > > > > > >= > > > > > > 0": > > > > > > > > > > Yea, like I mentioned it's pretty broken. Sometimes it's > > implemented as > > > > > UCMP, > > > > > sometimes it's implemented as MOVC. > > > > > It seems to be used only as MOVC. > > > > > It feels silly writing this, but we should probably make UCMP > > act like > > > > > UCMP > > > > > and add MOVC and use it when we need a MOVC. > > > > > > > > Zack, I believe Christoph has a point when he says that UCMP is > > > > semantically > > > > the same as MOVC. > > > > > > > > Because for unsigned integers, "foo > 0" is the same as "foo != > 0", > > > > therefore > > > > having UCMP defined as > > > > > > > > dst = src0 > 0 ? src1 : src2 > > > > > > > > or a MOVC as > > > > > > > > dst = src0 != 0 ? src1 : src2 > > > > > > > > is pretty much the same. > > > > > > > > Jose > > > > > > > > > > > > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org <mailto: > mesa-dev@lists.freedesktop.org> > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > > > > > > > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
