On 08/27/2013 06:21 PM, Paul Berry wrote:
On 27 August 2013 16:51, Damien Lespiau <damien.lesp...@intel.com> wrote:On Wed, Jul 24, 2013 at 10:02:22AM -0700, Kenneth Graunke wrote: > On 07/24/2013 09:33 AM, Paul Berry wrote: > >Two callers of brw_search_cache() weren't initializing that function's > >inout_offset parameter: brw_blorp_const_color_params::get_wm_prog() > >and brw_blorp_const_color_params::get_wm_prog(). > > > >That's a benign problem, since the only effect of not initializing > >inout_offset prior to calling brw_search_cache() is that the bit > >corresponding to cache_id in brw->state.dirty.cache may not be set > >reliably. This is ok, since the cache_id's used by > >brw_blorp_const_color_params::get_wm_prog() and > >brw_blorp_blit_params::get_wm_prog() (BRW_BLORP_CONST_COLOR_PROG and > >BRW_BLORP_BLIT_PROG, respectively) correspond to dirty bits that are > >not used. > > > >However, failing to initialize this parameter causes valgrind to > >complain. So let's go ahead and fix it to reduce valgrind noise. > > > >Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66779 Can we have this commit in the 9.2 branch? It was added in the release blocker bug but never cherry-picked for 9.2. Thanks! -- Damien Is there a reason for wanting this cherry-picked to 9.2 other than to follow procedure? As the commit message notes it's a benign problem--all it does is cause false positives from valgrind. I'd rather not mess with 9.2 if there's not going to be any benefit to users.
People working on GL programs want to be able to use valgrind to debug their own code. They don't want to see driver issues - not only is it confusing, it also means extra things to skip over every time they run valgrind on their program.
So, I'm strongly in favor of cherry-picking it. --Ken _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
