public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	igt-dev@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t 1/2] lib/igt_fb: Use cairo conversion in igt_fb_convert_with_stride, v3.
Date: Fri, 10 May 2019 17:10:02 +0200	[thread overview]
Message-ID: <2c3e93c8f8659a9050668211c751d1d5116d3516.camel@bootlin.com> (raw)
In-Reply-To: <0857cfca-743f-b83a-67f1-72d925700f2c@linux.intel.com>

Hi,

On Fri, 2019-05-10 at 16:19 +0200, Maarten Lankhorst wrote:
> Op 10-05-2019 om 15:43 schreef Paul Kocialkowski:
> > Hi,
> > 
> > It looks like I fell behind on reviewing earlier version here, sorry
> > about that.
> > 
> > On Fri, 2019-05-10 at 14:33 +0200, Maarten Lankhorst wrote:
> > > Ever since commit 3fa65f4b532bd9a5b ("fb: Add support for conversions
> > > through pixman") we can generate a valid cairo surface for any plane,
> > > use this to avoid having to implement our own conversion routine.
> > > 
> > > Instead of duplicating this functionality in igt_fb_convert_with_stride,
> > > we can simply convert this to a few cairo calls, because we now support
> > > cairo calls to any of the supported framebuffer formats.
> > I don't see how that is the case. Cairo definitely does not support our
> > tiled formats, so we can't just pipe them into it.
> > 
> > And we already use pixman for converting through the fb_convert call to
> > convert_pixman when possible. Also, my understanding is that cairo is
> > very limited format-wise, so we're much better off using pixman
> > directly (which is is what a non-accelerated cairo surface will do
> > anyway).
> > 
> > > This is required to make this function more generic, and convert from any
> > > format/modifier to any other format/modifier.
> > We've already designed it to be generic, we just need conversion
> > helpers from/to (currently only to) hardware-specific tiling modifiers.
> > 
> > We can't expect cairo or pixman to do that job and this change pretty
> > much kills support for the vc4 tiling modes we've added.
> > 
> > Unless I'm missing something, that's a NACK on my side.
> 
> You have a function that can convert a untiled fb to tiled, but not
> the other way around in igt_vc4.c

We don't need it for anything at the moment but it wouldn't be a
problem to come up with one, sure.

> If you could provide that, we could convert from any fb/modifier
> format to any fb/modifier format, even with VC4 tiling.

I don't fully get the point of that if our tests are not going to use
it, but it doesn't hurt either :)

> Our internal cairo hooks already provide helpers for conversion, see
> igt_get_cairo_surface() which calls
> create_cairo_surface__convert()

My feeling is that we should kill use of cairo formats and go with
pixman directly.

> Some conversions can only be done through cairo, converting between
> P01x and XRGB8888 cannot be done directly,
> our pixman representation for that are done in the floating point
> formats.

I'm not sure I'm following this point, but if there's a conversion that
cairo can do and pixman can't, it feels like the right thing would be
to fix pixman to support it. Is there a reason in particular why this
wouldn't work?

> The only way to convert between some framebuffer formats and
> modifiers in i915 is by using those conversion functions,
> the fact that igt_fb_convert_with_stride doesn't do those, makes a
> truly random hdmi-cmp-planes-random useless.

So it boils down to a missing format support issue, not really to an
issue with the existing flow.

> I was getting CRC mismatches because the i915 modifiers weren't
> respected. When I made sure they were being respected
> I ended up with a duplicate of the cairo context stuff. So why not
> lose a little speed and use that?

My counter-suggestion would be to do the opposite and make sure pixman
can deal with these cases on its own.

> If you write and test a detiler function, I can hook it up for you.
> :)
> If necessary I can do it myself, to move this patch forward.
> 
> Cairo shouldn't be much slower than pixman, because internally it
> already uses pixman calls for the backend.

Sure, but that's not cairo's role: cairo is about drawing, while pixman
is about pixel conversion. I think it would be best to stick to that.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

  reply	other threads:[~2019-05-10 15:10 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 12:33 [igt-dev] [PATCH i-g-t 1/2] lib/igt_fb: Use cairo conversion in igt_fb_convert_with_stride, v3 Maarten Lankhorst
2019-05-10 12:33 ` [igt-dev] [PATCH i-g-t 2/2] tests/kms_chamelium: Fix *-cmp-random and *-crc-random tests, v4 Maarten Lankhorst
2019-05-10 13:08 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/2] lib/igt_fb: Use cairo conversion in igt_fb_convert_with_stride, v3 Patchwork
2019-05-10 13:43 ` [igt-dev] [PATCH i-g-t 1/2] " Paul Kocialkowski
2019-05-10 14:19   ` Maarten Lankhorst
2019-05-10 15:10     ` Paul Kocialkowski [this message]
2019-05-10 16:02       ` Maarten Lankhorst
2019-05-14  6:34         ` Juha-Pekka Heikkila
2019-05-16 12:59           ` Maarten Lankhorst
2019-05-10 15:01 ` [igt-dev] ✓ Fi.CI.IGT: success for series starting with [i-g-t,1/2] " Patchwork
2019-05-10 16:36 ` [igt-dev] ✓ Fi.CI.BAT: success for series starting with [i-g-t,1/2] lib/igt_fb: Use cairo conversion in igt_fb_convert_with_stride, v3. (rev2) Patchwork
2019-05-10 19:05 ` [igt-dev] ✓ Fi.CI.IGT: " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2019-04-05 12:52 [igt-dev] [PATCH i-g-t 1/2] lib/igt_fb: Use cairo conversion in igt_fb_convert_with_stride, v3 Maarten Lankhorst
2019-04-05 13:54 ` Paul Kocialkowski
2019-04-05 15:38   ` Maarten Lankhorst
2019-04-08  8:50     ` Maxime Ripard
2019-04-08 11:04       ` Maarten Lankhorst
2019-04-09 14:59         ` Maxime Ripard

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=2c3e93c8f8659a9050668211c751d1d5116d3516.camel@bootlin.com \
    --to=paul.kocialkowski@bootlin.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=maarten.lankhorst@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox