[Intel-gfx] RFC: pipe writeback design for i915

[Shankar, Uma]

> -----Original Message-----
> From: Syrjala, Ville <ville.syrjala at intel.com>
> Sent: Friday, January 31, 2020 5:22 PM
> To: Jani Nikula <jani.nikula at linux.intel.com>
> Cc: Laxminarayan Bharadiya, Pankaj <pankaj.laxminarayan.bharadiya at intel.com>;
> daniel at ffwll.ch; Deak, Imre <imre.deak at intel.com>; Vivi, Rodrigo
> <rodrigo.vivi at intel.com>; intel-gfx at lists.freedesktop.org; Shankar, Uma
> <uma.shankar at intel.com>
> Subject: Re: RFC: pipe writeback design for i915
> 
> On Fri, Jan 31, 2020 at 12:55:45PM +0200, Jani Nikula wrote:
> > On Fri, 31 Jan 2020, "Bharadiya,Pankaj"
> <pankaj.laxminarayan.bharadiya at 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!

This will be useful even for all color validation and various other tests where due to pipe precision
and interpolation we don't have exact matches wrt crc's. Currently Chamelium comes as a savior,
but this limits to boards where we have this external hardware. This will help make things
not depend on availability of Chamelium in CI.
From IGT side, changes will be needed to enable this and migrate the respective tests, make them
use writeback dumps and compare.

Another advantage will be definitely in debugging, root causing the real culprits. If things are going
bad at port or pipe itself. In all this, we do get the real thing working i.e. a wireless display 😊 (rest of the stack
will need to be enabled but display side we will get our stuff enabled)

Regards,
Uma Shankar


> --
> Ville Syrjälä
> Intel