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@xxxxxxxxxxxxxxx wrote: > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > 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@xxxxxxxxxxxxxxx> > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
