mirror of https://gitlab.freedesktop.org/mesa/mesa
intel/fs: Don't allow 0 stride on MOV destination
Outside SIMD1 instructions, a destination stride of zero doesn't make any sense. When such strides exist, they would be fixed by the FS generator. Currently the only place that intentionally generates such a stride is setup_barrier_message_payload_gfx125, and this commit changes that. The existence of a zero stride that won't really be a zero stride causes a variety of problems with other optimization passes. Those passes don't know that 0 actually means 1, and they make incorrect assumptions about sizes written, etc. The assertion helped catch many bugs in some other work in progress that tries to store convergent values in SIMD8 registers regardless of the dispatch width. That code would accidentally generate destination strides of zero. v2: Check stride differently depending on register file. Suggested by Caio. Reviewed-by: Caio Oliveira <caio.oliveira@intel.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28256>
This commit is contained in:
parent
d10b546776
commit
671745b616
|
@ -550,6 +550,9 @@ namespace brw {
|
|||
fs_inst * \
|
||||
op(const fs_reg &dst, const fs_reg &src0) const \
|
||||
{ \
|
||||
assert(_dispatch_width == 1 || \
|
||||
(dst.file >= VGRF && dst.stride != 0) || \
|
||||
(dst.file < VGRF && dst.hstride != 0)); \
|
||||
return emit(BRW_OPCODE_##op, dst, src0); \
|
||||
}
|
||||
|
||||
|
|
|
@ -2854,7 +2854,7 @@ setup_barrier_message_payload_gfx125(const fs_builder &bld,
|
|||
assert(bld.shader->devinfo->verx10 >= 125);
|
||||
|
||||
/* From BSpec: 54006, mov r0.2[31:24] into m0.2[31:24] and m0.2[23:16] */
|
||||
fs_reg m0_10ub = component(retype(msg_payload, BRW_REGISTER_TYPE_UB), 10);
|
||||
fs_reg m0_10ub = horiz_offset(retype(msg_payload, BRW_REGISTER_TYPE_UB), 10);
|
||||
fs_reg r0_11ub =
|
||||
stride(suboffset(retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_UB), 11),
|
||||
0, 1, 0);
|
||||
|
|
Loading…
Reference in New Issue