On Wed, Apr 23, 2014 at 10:55 PM, Kenneth Graunke <kenn...@whitecape.org> wrote:
> On 04/18/2014 11:56 AM, Matt Turner wrote:
>> Clean up with with register_coalesce()/dead_code_eliminate().
>> ---
>> src/mesa/drivers/dri/i965/brw_fs.cpp | 37
>> ++++++++++++++++++++++++++++++++++++
>> src/mesa/drivers/dri/i965/brw_fs.h | 1 +
>> 2 files changed, 38 insertions(+)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> index e963ee8..602fc4a 100644
>> --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
>> +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
>> @@ -2635,6 +2635,38 @@ fs_visitor::lower_uniform_pull_constant_loads()
>> }
>> }
>>
>> +bool
>> +fs_visitor::lower_load_payload()
>> +{
>> + bool progress = false;
>> +
>> + foreach_list_safe(node, &instructions) {
>> + fs_inst *inst = (fs_inst *)node;
>> +
>> + if (inst->opcode == SHADER_OPCODE_LOAD_PAYLOAD) {
>> + fs_reg dst = inst->dst;
>> +
>
> It would be great to have a comment here such as:
>
> /* src[0] represents the (optional) message header. */
>
> It might also be worth adding a comment above the opcode definition in
> the previous patch explaining that src[0] is reserved for an optional
> message header, and could be BAD_FILE, while the rest of the parameters
> follow in src[1..n]. Notably, this is the first opcode where you can
> have a BAD_FILE early, and real parameters later (AFAIK).
Yeah. Another problem this causes is dump_instructions() stops
printing the arguments following BAD_FILE.
I could special-case that code, but I wonder if it'd be more clear to
use a new enum type ("MSG_HEADER")?
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
