diff options
authorKenneth Graunke <>2014-10-13 12:14:16 -0700
committerKenneth Graunke <>2015-01-10 19:24:04 -0800
commit0ae71b48a12b61222d9c7d44f54bbd3c71d2bbbf (patch)
parent355156d2f75ffb5fae90dd6583ae3cf465ba40b4 (diff)
i965: Initialize grf_used in fs_visitor::emit_repclear_shader().
fs_visitor::grf_used is used to calculate prog_data->reg_blocks_16, which was getting populated with an uninitialized value. Normally, grf_used is set by the register allocator, but emit_repclear_shader bypasses that; it must set grf_used directly. This bug was well hidden: reg_blocks and reg_blocks_16 are unused on Gen6+. However, when uploading programs, we look for an existing entry in the cache. If we find a potential hit, we memcmp the two prog_data structures, including the uninitialized reg_blocks_16 field. Of course, this only happens if we upload the repclear shader twice - which only happens if the precompile guesses the program key incorrectly. On Gen6+, precompile guesses the program key for the repclear shader correctly, so this bug ought to remain untriggered. However, on Gen5, we make more mistakes when guessing the key, which is how I spotted the bug. It is reproducible on Haswell by making precompile choose daft values for fields. v2: Program a correct value. I originally programmed 0 based on a misreading of the trivial register allocator. Cc: Jason Ekstrand <> Signed-off-by: Kenneth Graunke <>
1 files changed, 4 insertions, 0 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 9dfb7b7343..8bb2893dc9 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2655,6 +2655,7 @@ void
brw_wm_prog_key *key = (brw_wm_prog_key*) this->key;
+ brw_wm_prog_data *wm_prog_data = (brw_wm_prog_data *) prog_data;
int base_mrf = 1;
int color_mrf = base_mrf + 2;
@@ -2685,6 +2686,9 @@ fs_visitor::emit_repclear_shader()
+ grf_used = ALIGN(payload.num_regs + prog_data->curb_read_length +
+ wm_prog_data->num_varying_inputs * 2, 2);