Re: [igt-dev] [HAX 3/5] lib/igt_fb: Use rendercopy for rendering into compressed buffers

Ville Syrjälä
2019-02-22T18:55:03Z

On Fri, Feb 22, 2019 at 10:37:40AM -0800, Dhinakaran Pandiyan wrote:
> On Fri, 2019-02-22 at 19:26 +0200, Ville Syrjälä wrote:
> > On Thu, Feb 21, 2019 at 03:20:35PM -0800, Dhinakaran Pandiyan wrote:
> > > On Thu, 2019-02-21 at 16:06 +0200, Ville Syrjälä wrote:
> > > > On Wed, Feb 20, 2019 at 06:41:21PM -0800, Dhinakaran Pandiyan
> > > > wrote:
> > > > > @@ -2397,8 +2523,10 @@ cairo_surface_t
> > > > > *igt_get_cairo_surface(int
> > > > > fd, struct igt_fb *fb)
> > > > > ((f->cairo_id == CAIRO_FORMAT_INVALID) &&
> > > > > (f->pixman_id != PIXMAN_invalid)))
> > > > > create_cairo_surface__convert(fd, fb);
> > >
> > > All BGR formats will take this path and it somehow results in Yf-
> > > CCS
> > > tests specifically failing.
> >
> > Hmm. Should be a matter of
> >
> > if (...
> > + is_ccs) {
> > setup_linear_mapping();
> > } else {
> > ...
> >
> > no? Or was that already in there?
> >
> > It is slightly suboptimal since in theory we could just use
> > rendercopy to do the full conversion for us, skipping the expensive
> > software step. IIRC I briefly mentioned this option when Maarten
> > was adding the !32bpp support to rendercopy. Anyways, we could
> > consider doing that in the future if we are willing to expand
> > our use of rendercopy. The counter argument is that it's one
> > more extra thing that could fail.
>
> Didn't quite get why rendercopy would have a higher chance of failing.
> Personally, the problem I have is I don't fully understand the
> rendercopy code yet :) And, I am not sure how easy it is to extend
> support for new platforms from a display IGT development point of view.

It all depends how much the hw people feel the need to change. Hopefully
not too much, and that someone has the energy to find out which new
magic bits are needed to make it work.

Also if the GT side is having major issues we can't rely on rendercopy
obviously. Just one more thing to worry about, at least during early
testing/development.

> I guess the library is not backward compatible either.

In what sense?

--
Ville Syrjälä
Intel