Matt Turner <matts...@gmail.com> writes:
> On Fri, Feb 6, 2015 at 6:42 AM, Francisco Jerez <curroje...@riseup.net> wrote:
>> ---
>> src/mesa/drivers/dri/i965/brw_vec4.cpp | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> index c3f68e6..aaa4873 100644
>> --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
>> @@ -437,7 +437,8 @@ vec4_visitor::opt_reduce_swizzle()
>> bool progress = false;
>>
>> foreach_block_and_inst_safe(block, vec4_instruction, inst, cfg) {
>> - if (inst->dst.file == BAD_FILE || inst->dst.file == HW_REG)
>> + if (inst->dst.file == BAD_FILE || inst->dst.file == HW_REG ||
>> + inst->is_send_from_grf())
>> continue;
>>
>> int swizzle[4];
>> --
>> 2.1.3
>
> Like the last patch, I totally believe this is a problem, I just want
> a little more explanation for how it was uncovered.The problem is that it's not safe for opt_reduce_swizzle() to assume that there is a one-to-one correspondence between vec4 channels of its sources and its destination for send instructions. For example, the message may include a header which has an effect on all channels. For example: | mov vgrf31.0:UD, 0D | mov vgrf31.0.w:UD, 17D | typed_surface_read vgrf33.0.x:UD, vgrf31.xyzw:UD, vgrf32.xxxx:UD, 1U will get incorrectly reduced to: | mov vgrf31.0:UD, 0D | mov vgrf31.0.w:UD, 17D | typed_surface_read vgrf33.0.x:UD, vgrf31.xxxx:UD, vgrf32.xxxx:UD, 1U now subsequent optimization passes will assume that only the x component of vgrf31 is used and will simplify the above code to: | mov vgrf31.0.x:UD, 0D | typed_surface_read vgrf33.0.x:UD, vgrf31.xxxx:UD, vgrf32.xxxx:UD, 1U
pgpbayODW9xsk.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
