public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Damien Lespiau <damien.lespiau@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: Pipe CRCs v1
Date: Wed, 16 Oct 2013 12:02:44 +0200	[thread overview]
Message-ID: <20131016100244.GH4830@phenom.ffwll.local> (raw)
In-Reply-To: <1381859742-24887-1-git-send-email-damien.lespiau@intel.com>

On Tue, Oct 15, 2013 at 06:55:26PM +0100, Damien Lespiau wrote:
> This series exposes the pipe CRCs on ivybridge through debugfs. It's based on
> the initial work from Shuang He, with some improvements to have a nice user
> space API.
> 
> There are several points in the display pipeline where CRCs can be computed
> on the bits flowing there. For instance, it's usually possible to compute
> the CRCs of the primary plane, the sprite plane or the CRCs of the bits
> after the panel fitter (collectively called pipe CRCs).
> 
> An intel-gpu-tools series will follow with helpers to use the feature from
> tests and basic testing.
> 
> Further work items:
>   * make it work on other platforms
>   * expose other CRCs than just the pipe CRCs (transcoders, ddi, ...)
>   * implement poll() for the result files

I like this and so went ahead and merged it right away. A bit of CRC
support is much better than none and the tests should make sure that
things actually work somewhat.

Polishing that imo still needs to happen:
- Roll out on other platforms. Especially vlv since there we actually want
  to have good sprite support.

- Add an "all" alias or something similar which just picks a crc source
  take takes the pixels after all sprite/cursor/plane blending, csc and
  gamma ramps have been applied. For ivb that seems to be the "pf" source.
  To make sure it works we'd need a small testcase that moves
  cursors/sprites/planes and changes gamma to make sure we cover all these
  things. Then we could finally have automated testcases for checking all
  the restore code in our resume paths (or dpms on and all that stuff).

- atomic_t is weakly ordered, even on x86 (since it doesn't even have).
  Also, writing a correct lockless ringbuffer is Damn Hard (tm). I don't
  see any need to massive performance issues with this, so we need to
  switch to normal mutex locking (with a spinlock for the ringbuffer
  itself to allow the irq handler to fill it).

- Use it all over the place in igt tests ...

Thanks a lot for doing this.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

      parent reply	other threads:[~2013-10-16 10:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-15 17:55 Pipe CRCs v1 Damien Lespiau
2013-10-15 17:55 ` [PATCH 01/16] drm/i915: Expose latest 200 CRC value for pipe through debugfs Damien Lespiau
2013-10-16 10:29   ` Ville Syrjälä
2013-10-17 11:32   ` He, Shuang
2013-10-15 17:55 ` [PATCH 02/16] drm/i915: Add a control file for pipe CRCs Damien Lespiau
2013-10-15 17:55 ` [PATCH 03/16] drm/i915: Keep the CRC values into a circular buffer Damien Lespiau
2013-10-15 17:55 ` [PATCH 04/16] drm/i915: Sample the frame counter instead of a timestamp for CRCs Damien Lespiau
2013-10-16 13:29   ` Ville Syrjälä
2013-10-16 13:51     ` Daniel Vetter
2013-10-16 13:58       ` Ville Syrjälä
2013-10-16 14:04       ` Ville Syrjälä
2013-10-15 17:55 ` [PATCH 05/16] drm/i915: Make switching to the same CRC source a no-op Damien Lespiau
2013-10-15 17:55 ` [PATCH 06/16] drm/i915: Enforce going back to none before changing CRC source Damien Lespiau
2013-10-15 17:55 ` [PATCH 07/16] drm/i915: Empty the circular buffer when asked for a new source Damien Lespiau
2013-10-15 17:55 ` [PATCH 08/16] drm/i915: Dynamically allocate the CRC circular buffer Damien Lespiau
2013-10-15 17:55 ` [PATCH 09/16] drm/i915: Generalize the CRC command format for future work Damien Lespiau
2013-10-15 17:55 ` [PATCH 10/16] drm/i915: Rename i915_pipe_crc_ctl to i915_display_crc_ctl Damien Lespiau
2013-10-15 17:55 ` [PATCH 11/16] drm/i915: Warn if we receive an interrupt after freeing the buffer Damien Lespiau
2013-10-15 17:55 ` [PATCH 12/16] drm/i915: Add log messages when CRCs collection is started/stopped Damien Lespiau
2013-10-15 17:55 ` [PATCH 13/16] drm/i915: Move drm_add_fake_info_node() higher in the file Damien Lespiau
2013-10-15 17:55 ` [PATCH 14/16] drm/i915: Implement blocking read for pipe CRC files Damien Lespiau
2013-10-15 17:55 ` [PATCH 15/16] drm/i915: Only one open() allowed on pipe CRC result files Damien Lespiau
2013-10-15 17:55 ` [PATCH 16/16] drm/i915: Enable pipe CRCs Damien Lespiau
2013-10-16 10:02 ` Daniel Vetter [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131016100244.GH4830@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=damien.lespiau@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox