| Message ID | 1450110229-30450-4-git-send-email-ville.syrjala@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Dec 14, 2015 at 06:23:42PM +0200, ville.syrjala@linux.intel.com wrote: > From: Ville Syrjälä <ville.syrjala@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@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. -Daniel > --- > drivers/gpu/drm/i915/i915_debugfs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c > index 24318b79bcfc..96d6e5de0811 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -3518,7 +3518,7 @@ i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count, > pipe_crc->tail = (pipe_crc->tail + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1); > > bytes_read += snprintf(buf, PIPE_CRC_BUFFER_LEN, > - "%8u %8x %8x %8x %8x %8x\n", > + "%8x %8x %8x %8x %8x %8x\n", > entry->frame, entry->crc[0], > entry->crc[1], entry->crc[2], > entry->crc[3], entry->crc[4]); > -- > 2.4.10 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
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@linux.intel.com wrote: > > From: Ville Syrjälä <ville.syrjala@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@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). > -Daniel > > > --- > > drivers/gpu/drm/i915/i915_debugfs.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c > > index 24318b79bcfc..96d6e5de0811 100644 > > --- a/drivers/gpu/drm/i915/i915_debugfs.c > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > > @@ -3518,7 +3518,7 @@ i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count, > > pipe_crc->tail = (pipe_crc->tail + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1); > > > > bytes_read += snprintf(buf, PIPE_CRC_BUFFER_LEN, > > - "%8u %8x %8x %8x %8x %8x\n", > > + "%8x %8x %8x %8x %8x %8x\n", > > entry->frame, entry->crc[0], > > entry->crc[1], entry->crc[2], > > entry->crc[3], entry->crc[4]); > > -- > > 2.4.10 > > > > _______________________________________________ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
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@linux.intel.com wrote: > > > From: Ville Syrjälä <ville.syrjala@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@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
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 24318b79bcfc..96d6e5de0811 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3518,7 +3518,7 @@ i915_pipe_crc_read(struct file *filep, char __user *user_buf, size_t count, pipe_crc->tail = (pipe_crc->tail + 1) & (INTEL_PIPE_CRC_ENTRIES_NR - 1); bytes_read += snprintf(buf, PIPE_CRC_BUFFER_LEN, - "%8u %8x %8x %8x %8x %8x\n", + "%8x %8x %8x %8x %8x %8x\n", entry->frame, entry->crc[0], entry->crc[1], entry->crc[2], entry->crc[3], entry->crc[4]);