All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] RFC: pipe writeback design for i915
Date: Fri, 31 Jan 2020 13:51:59 +0200	[thread overview]
Message-ID: <20200131115159.GM13686@intel.com> (raw)
In-Reply-To: <87pnez99ou.fsf@intel.com>

On Fri, Jan 31, 2020 at 12:55:45PM +0200, Jani Nikula wrote:
> On Fri, 31 Jan 2020, "Bharadiya,Pankaj" <pankaj.laxminarayan.bharadiya@intel.com> wrote:
> > I am exploring the way of implementing the pipe writeback feature in i915 and
> > would like to get early feedback on design.
> >
> > We have a Wireless display(WD) transcoder which can be used for capturing
> > display pipe output to memory. It is generally intended for wireless display,
> > but can be used for other functions such as in validation automation where crc
> > based comparison is not feasible.
> 
> I think you should probably explore the use case and driver/igt impact
> further before embarking on the implementation.
> 
> - How much do you need to modify existing code in kernel and igt to make
>   use of writeback connectors?
> 
> - What kind of test coverage do you get? Pipe CRC is used in connection
>   with the physical encoders. In contrast, you won't have that with WD
>   transcoders. (Design wise I think this may mean you'll also need
>   "writeback encoders", instead of trying to plug it into existing
>   encoders.) So you'll only test the pipe side of things, which roughly
>   corresponds to pipe CRC coverage I guess. I guess it could speed up
>   that part of testing because you can then skip the physical
>   connectors, but you do have to test them also. So it's not a panacea.

The main benefit I'm looking forward to is for reverse engineering.
As in answwering the age old question: "let me see wtf the hw is
actually doing to my pixels?". I want this!

-- 
Ville Syrjälä
Intel
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-01-31 11:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31  6:30 [Intel-gfx] RFC: pipe writeback design for i915 Bharadiya,Pankaj
2020-01-31 10:55 ` Jani Nikula
2020-01-31 11:51   ` Ville Syrjälä [this message]
2020-02-12  5:22     ` Shankar, Uma
2020-01-31 11:57 ` Ville Syrjälä
  -- strict thread matches above, loose matches on Subject: below --
2020-02-04  8:05 Bharadiya,Pankaj
2020-02-12  5:36 ` Shankar, Uma

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=20200131115159.GM13686@intel.com \
    --to=ville.syrjala@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.