[Mesa-dev] [PATCH 46/57] i965/ir: Update several stale comments.
Francisco Jerez
currojerez at riseup.net
Thu Sep 8 01:49:13 UTC 2016
---
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 6d4303c..a5ba903 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 c7f24d4..a64feeb 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.9.0
More information about the mesa-dev
mailing list