From eb746a80e5e99bafd3957a1cb2d9db8548a1a6be Mon Sep 17 00:00:00 2001 From: Francisco Jerez Date: Fri, 2 Sep 2016 13:53:13 -0700 Subject: [PATCH] i965/ir: Update several stale comments. Reviewed-by: Iago Toral Quiroga --- src/mesa/drivers/dri/i965/brw_defines.h | 2 +- src/mesa/drivers/dri/i965/brw_fs.cpp | 18 +++++++----------- src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp | 12 ++++++------ .../drivers/dri/i965/brw_schedule_instructions.cpp | 8 ++++---- src/mesa/drivers/dri/i965/brw_vec4.cpp | 8 ++++---- 5 files changed, 22 insertions(+), 26 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h index c142d42..c4e0f27 100644 --- a/src/mesa/drivers/dri/i965/brw_defines.h +++ b/src/mesa/drivers/dri/i965/brw_defines.h @@ -1010,7 +1010,7 @@ enum opcode { * For example, parameters for a send-from-GRF message. Or, updating * channels of a size 4 VGRF used to store vec4s such as texturing results. * - * This will be lowered into MOVs from each source to consecutive reg_offsets + * This will be lowered into MOVs from each source to consecutive offsets * of the destination VGRF. * * src[0] may be BAD_FILE. If so, the lowering pass skips emitting the MOV, diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index c691b2b..c858f44 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -172,12 +172,12 @@ fs_visitor::VARYING_PULL_CONSTANT_LOAD(const fs_builder &bld, * be any component of a vector, and then we load 4 contiguous * components starting from that. * - * We break down the const_offset to a portion added to the variable - * offset and a portion done using reg_offset, which means that if you - * have GLSL using something like "uniform vec4 a[20]; gl_FragColor = - * a[i]", we'll temporarily generate 4 vec4 loads from offset i * 4, and - * CSE can later notice that those loads are all the same and eliminate - * the redundant ones. + * We break down the const_offset to a portion added to the variable offset + * and a portion done using fs_reg::offset, which means that if you have + * GLSL using something like "uniform vec4 a[20]; gl_FragColor = a[i]", + * we'll temporarily generate 4 vec4 loads from offset i * 4, and CSE can + * later notice that those loads are all the same and eliminate the + * redundant ones. */ fs_reg vec4_offset = vgrf(glsl_type::uint_type); bld.ADD(vec4_offset, varying_offset, brw_imm_ud(const_offset & ~0xf)); @@ -2062,7 +2062,7 @@ fs_visitor::assign_constant_locations() stage_prog_data->nr_params = num_push_constants; stage_prog_data->nr_pull_params = num_pull_constants; - /* Up until now, the param[] array has been indexed by reg + reg_offset + /* Up until now, the param[] array has been indexed by reg + offset * of UNIFORM registers. Move pull constants into pull_param[] and * condense param[] to only contain the uniforms we chose to push. * @@ -3166,10 +3166,6 @@ fs_visitor::insert_gen4_send_dependency_workarounds() bool progress = false; - /* Note that we're done with register allocation, so GRF fs_regs always - * have a .reg_offset of 0. - */ - foreach_block_and_inst(block, fs_inst, inst, cfg) { if (inst->mlen != 0 && inst->dst.file == VGRF) { insert_gen4_pre_send_dependency_workarounds(block, inst); diff --git a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp index a6c98e3..c449672 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_live_variables.cpp @@ -41,12 +41,12 @@ using namespace brw; * but we currently do not. It is easier for the consumers of this * information to work with whole VGRFs. * - * However, we internally track use/def information at the per-component - * (reg_offset) level for greater accuracy. Large VGRFs may be accessed - * piecemeal over many (possibly non-adjacent) instructions. In this case, - * examining a single instruction is insufficient to decide whether a whole - * VGRF is ultimately used or defined. Tracking individual components - * allows us to easily assemble this information. + * However, we internally track use/def information at the per-GRF level for + * greater accuracy. Large VGRFs may be accessed piecemeal over many + * (possibly non-adjacent) instructions. In this case, examining a single + * instruction is insufficient to decide whether a whole VGRF is ultimately + * used or defined. Tracking individual components allows us to easily + * assemble this information. * * See Muchnick's Advanced Compiler Design and Implementation, section * 14.1 (p444). diff --git a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp index 98e08d7..28d1e90 100644 --- a/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp +++ b/src/mesa/drivers/dri/i965/brw_schedule_instructions.cpp @@ -1489,10 +1489,10 @@ fs_instruction_scheduler::choose_instruction_to_schedule() if (v->devinfo->gen < 7) { fs_inst *chosen_inst = (fs_inst *)chosen->inst; - /* We use regs_written > 1 as our test for the kind of send - * instruction to avoid -- only sends generate many regs, and a - * single-result send is probably actually reducing register - * pressure. + /* We use size_written > 4 * exec_size as our test for the kind + * of send instruction to avoid -- only sends generate many + * regs, and a single-result send is probably actually reducing + * register pressure. */ if (inst->size_written <= 4 * inst->exec_size && chosen_inst->size_written > 4 * chosen_inst->exec_size) { diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp b/src/mesa/drivers/dri/i965/brw_vec4.cpp index e5d6c2f..28e753a 100644 --- a/src/mesa/drivers/dri/i965/brw_vec4.cpp +++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp @@ -1321,10 +1321,10 @@ vec4_visitor::eliminate_find_live_channel() * Splits virtual GRFs requesting more than one contiguous physical register. * * We initially create large virtual GRFs for temporary structures, arrays, - * and matrices, so that the dereference visitor functions can add reg_offsets - * to work their way down to the actual member being accessed. But when it - * comes to optimization, we'd like to treat each register as individual - * storage if possible. + * and matrices, so that the visitor functions can add offsets to work their + * way down to the actual member being accessed. But when it comes to + * optimization, we'd like to treat each register as individual storage if + * possible. * * So far, the only thing that might prevent splitting is a send message from * a GRF on IVB. -- 2.7.4