[Mesa-dev] [PATCH] i965: Initialize inout_offset parameter to brw_search_cache().
Kenneth Graunke
kenneth at whitecape.org
Tue Aug 27 20:30:03 PDT 2013
On 08/27/2013 06:21 PM, Paul Berry wrote:
> On 27 August 2013 16:51, Damien Lespiau <damien.lespiau at 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
More information about the mesa-dev
mailing list