[Mesa-dev] [PATCH] i965/fs: Strip trailing contant zeroes in sample messages
Neil Roberts
neil at linux.intel.com
Fri Apr 24 17:15:46 PDT 2015
Matt Turner <mattst88 at gmail.com> writes:
>> + foreach_block_and_inst(block, fs_inst, inst, cfg) {
>> + if ((inst->opcode == SHADER_OPCODE_TEX ||
>> + inst->opcode == SHADER_OPCODE_TXF) &&
>> + !inst->shadow_compare) {
>> + fs_inst *load_payload = (fs_inst *) inst->prev;
>> +
>> + if (load_payload->is_head_sentinel() ||
>> + load_payload->opcode != SHADER_OPCODE_LOAD_PAYLOAD)
>> + continue;
>
> We can't guarantee that the load_payload isn't used by another texture
> later in the program, and since you need to change the texture
> operation's mlen, I think you need to check that the load_payload
> isn't used after this texture operation.
>
> To do that, (1) add an ip variable and initialize it to -1, (2) add
> ip++ as the first statement in the foreach_block_and_inst loop, (3)
> add some code to this check similar to in
> brw_fs_saturate_propagation.cpp using this->live_intervals.
Hrm, I'm not modifying the LOAD_PAYLOAD instruction, only the
SHADRE_OPCODE_TEX/TXF instruction. If there is a later instruction that
is using the LOAD_PAYLOAD, won't that end up making it's own dependency
on the MOV instructions so they won't get removed?
>> + OPT(opt_zero_samples);
>
> I think you're probably right that this can be done after the
> optimization loop. I guess it's possible that we might trim a texture
> payload down and it'll then be the same as an existing payload and we
> can then CSE them. I'd be interested to see if putting it inside the
> optimization loop improves anything.
Hrm, it might be worth trying. However, as I mentioned above, I'm not
modifying the LOAD_PAYLOAD instruction so it probably won't hit the
example you mentioned.
Thanks for the review.
Regards,
- Neil
More information about the mesa-dev
mailing list