Kenneth Graunke <kenn...@whitecape.org> writes:
> On 02/06/2013 05:29 PM, Eric Anholt wrote:
>> In 2 of our checks, we were missing BREAK and CONTINUE.
>>
>> NOTE: Candidate for the stable branches.
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.cpp | 33
>> +++++++++++---------
>> src/mesa/drivers/dri/i965/brw_fs.h | 1 +
>> .../dri/i965/brw_fs_schedule_instructions.cpp | 9 +-----
>> 3 files changed, 21 insertions(+), 22 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> index 8e57eb0..fdccd75 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> @@ -328,6 +328,23 @@ fs_inst::is_math()
>> }
>>
>> bool
>> +fs_inst::is_flow_control()
>> +{
>> + switch (opcode) {
>> + case BRW_OPCODE_DO:
>> + case BRW_OPCODE_WHILE:
>> + case BRW_OPCODE_IF:
>> + case BRW_OPCODE_ELSE:
>> + case BRW_OPCODE_ENDIF:
>> + case BRW_OPCODE_BREAK:
>> + case BRW_OPCODE_CONTINUE:
>> + return true;
>> + default:
>> + return false;
>> + }
>> +}
>
> Shouldn't BRW_OPCODE_HALT be counted as a flow control instruction too?Right now we're not using HALT in a way that matters for the callers asking about control flow -- for any channels that are discarded, what happens in those channels doesn't matter from then on (since they are only turned on right before the EOT send). If we end up using HALT as part of function calls or switch statements or something, then we may need to add it in, but for now it would make us miss optimization opportunities across discards I think.
pgpgKrN6wt5MV.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
