[Mesa-dev] [PATCH] i965: Always enable VF statistics

[Ben Widawsky]

On Thu, Nov 13, 2014 at 09:47:10AM -0800, Eric Anholt wrote:
> Kenneth Graunke <kenneth at whitecape.org> writes:
> 
> > On Wednesday, November 12, 2014 06:54:31 PM Ben Widawsky wrote:
> >> Every other unit in the geometry pipeline automatically enables
> >> statistics gathering. This part of the pipe has been controlled by the
> >> DEBUG_STATS variable, but this is asymmetric. This dates back to the
> >> original implementation, and I am not sure if there is a reason for it.
> >> 
> >> I need access to these stats to implement ARB_pipeline_statistics_query.
> >> 
> >> Eric wrote it, and Ken touched it last. Do you have any opposition?
> >> 
> >> Cc: Eric Anholt <eric at anholt.net>
> >> Cc: Kenneth Graunke <kenneth at whitecape.org>
> >> Signed-off-by: Ben Widawsky <ben at bwidawsk.net>
> >> ---
> >>  src/mesa/drivers/dri/i965/brw_misc_state.c | 3 +--
> >>  1 file changed, 1 insertion(+), 2 deletions(-)
> >> 
> >> diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c 
> > b/src/mesa/drivers/dri/i965/brw_misc_state.c
> >> index 99fcddc..2c40814 100644
> >> --- a/src/mesa/drivers/dri/i965/brw_misc_state.c
> >> +++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
> >> @@ -929,8 +929,7 @@ brw_upload_invariant_state(struct brw_context *brw)
> >>     const uint32_t _3DSTATE_VF_STATISTICS =
> >>        is_965 ? GEN4_3DSTATE_VF_STATISTICS : GM45_3DSTATE_VF_STATISTICS;
> >>     BEGIN_BATCH(1);
> >> -   OUT_BATCH(_3DSTATE_VF_STATISTICS << 16 |
> >> -	     (unlikely(INTEL_DEBUG & DEBUG_STATS) ? 1 : 0));
> >> +   OUT_BATCH(_3DSTATE_VF_STATISTICS << 16 | 1);
> >>     ADVANCE_BATCH();
> >>  }
> >
> > My only complaint about this patch is that it doesn't go far enough.  I'm 100% 
> > for removing DEBUG_STATS completely.  I've never seen any performance penalty 
> > for enabling statistics.  I think we should leave them on except when there's 
> > some reason to turn them off (i.e. brw->meta_in_progress flag in the clipper, 
> > which prevents us from counting i.e. glClear).
> 
> Presumably there's some tiny power cost.  I don't know if it's a relevat
> amount of power, though.

It would totally be blown away by the PS stats I assume. So not taking
that as a NAK.

BTW, also:
buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86145


-- 
Ben Widawsky, Intel Open Source Technology Center