[Intel-gfx] [PATCH 03/10] drm/i915: Write out crc frame counts in hex

[Daniel Vetter]

On Wed, Dec 16, 2015 at 12:58:33PM +0200, Ville Syrjälä wrote:
> On Wed, Dec 16, 2015 at 11:23:54AM +0100, Daniel Vetter wrote:
> > On Mon, Dec 14, 2015 at 06:23:42PM +0200, ville.syrjala at linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > The crc code assumes that the printed frame counter value takes
> > > exactly 8 characters. The counter is a 32bit value, so to fit
> > > it into 8 characters we need to print it in hex, in decimal it
> > > would take 10 characters.
> > > 
> > > This obviously needs a corresponding change in intel-gpu-tools.
> > > 
> > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > 
> > ugh, and we hardcode the same %8u on the igt side. What about instead
> > changing igt to just parse for an %u, push that, then change the kernel to
> > dump a %u without length? With a few months in between.
> > 
> > At least some backwards compat must be there, otherwise bisecting will be
> > slightly painful.
> 
> So the other idea I had was to limit the counter to 24 bits always. That
> would avoid having to change the printf format string at all, and it
> would gives us a consistent wraparound behaviour (since gen3/4 frame
> counter is only 24 bits).

Still a mess imo. I thik the real problem is that userspace doesn't know
what the wraparound max is, so impossible to handle that. I guess we could
spec that its 24 (or 20) bits or whatever, but that doesn't feel like a
great idea long-term. Especially since some folks have ideas about making
crc capture cross-vendor. If we need to redo this, might be better to dump
max_vblank_count too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch