While most align16 instructions only support a SubRegNum of 0 or 4
(using swizzling to control the other channels), 3-src instructions
actually support arbitrary SubRegNums. When the RepCtrl bit is set,
we believe it ignores the swizzle and uses the equivalent of a <0,1,0>
region from the subnr.
In the past, we adopted a vec4-centric approach of specifying subnr of
0 or 4 and a swizzle, then having brw_eu_emit.c convert that to a proper
SubRegNum. This isn't a great fit for the scalar backend, where we
don't set swizzles at all, and happily set subnrs in the range [0, 7].
This patch changes brw_eu_emit.c to use subnr and swizzle directly,
relying on the higher levels to set them sensibly.
This should fix problems where scalar sources get copy propagated into
3-src instructions in the FS backend. I've only observed this with
TES push model inputs, but I suppose it could happen in other cases.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Matt Turner <mattst88@gmail.com>
static int
get_3src_subreg_nr(struct brw_reg reg)
{
- if (reg.vstride == BRW_VERTICAL_STRIDE_0) {
- assert(brw_is_single_value_swizzle(reg.swizzle));
- return reg.subnr / 4 + BRW_GET_SWZ(reg.swizzle, 0);
- } else {
- return reg.subnr / 4;
- }
+ /* Normally, SubRegNum is in bytes (0..31). However, 3-src instructions
+ * use 32-bit units (components 0..7). Since they only support F/D/UD
+ * types, this doesn't lose any flexibility, but uses fewer bits.
+ */
+ return reg.subnr / 4;
}
static brw_inst *
case ATTR:
unreachable("not reached");
}
+
src = reg;
}
+ if (inst->is_3src()) {
+ /* 3-src instructions with scalar sources support arbitrary subnr,
+ * but don't actually use swizzles. Convert swizzle into subnr.
+ */
+ for (int i = 0; i < 3; i++) {
+ if (inst->src[i].vstride == BRW_VERTICAL_STRIDE_0) {
+ assert(brw_is_single_value_swizzle(inst->src[i].swizzle));
+ inst->src[i].subnr += 4 * BRW_GET_SWZ(inst->src[i].swizzle, 0);
+ }
+ }
+ }
+
dst_reg &dst = inst->dst;
struct brw_reg reg;