[Mesa-dev] [PATCH 4/4] llvmpipe: remove no-op checks in sampler, sampler_view functions

[Jose Fonseca]

----- Original Message -----
> Am 03.04.2014 17:56, schrieb Brian Paul:
> > ---
> >  src/gallium/drivers/llvmpipe/lp_state_sampler.c |   14 --------------
> >  1 file changed, 14 deletions(-)
> > 
> > diff --git a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
> > b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
> > index db8646c..09bc928 100644
> > --- a/src/gallium/drivers/llvmpipe/lp_state_sampler.c
> > +++ b/src/gallium/drivers/llvmpipe/lp_state_sampler.c
> > @@ -77,13 +77,6 @@ llvmpipe_bind_sampler_states(struct pipe_context *pipe,
> >     assert(shader < PIPE_SHADER_TYPES);
> >     assert(start + num <= Elements(llvmpipe->samplers[shader]));
> >  
> > -   /* Check for no-op */
> > -   if (start + num <= llvmpipe->num_samplers[shader] &&
> > -       !memcmp(llvmpipe->samplers[shader] + start, samplers,
> > -               num * sizeof(void *))) {
> > -      return;
> > -   }
> > -
> >     draw_flush(llvmpipe->draw);
> >  
> >     /* set the new samplers */
> > @@ -125,13 +118,6 @@ llvmpipe_set_sampler_views(struct pipe_context *pipe,
> >     assert(shader < PIPE_SHADER_TYPES);
> >     assert(start + num <= Elements(llvmpipe->sampler_views[shader]));
> >  
> > -   /* Check for no-op */
> > -   if (start + num <= llvmpipe->num_sampler_views[shader] &&
> > -       !memcmp(llvmpipe->sampler_views[shader] + start, views,
> > -               num * sizeof(struct pipe_sampler_view *))) {
> > -      return;
> > -   }
> > -
> >     draw_flush(llvmpipe->draw);
> >  
> >     /* set the new sampler views */
> > 
> 
> There could be state trackers not using cso, hence doing this in the
> driver could still have benefits. I guess though in this case we should
> say the st is responsible for eliminating no-op changes...
> For the series:
> Reviewed-by: Roland Scheidegger <sroland at vmware.com>

Agreed. I think the series is fine as-is.

BTW, I think you might want to check that src/gallium/auxiliary/draw/draw_pipe_aaline/pstipple.c are doing the right thing too while you're at it. It looks to me they are making some dubious assumptions.

Jose