[igt-dev] [PATCH i-g-t 1/2] lib/igt_fb: Use cairo conversion in igt_fb_convert_with_stride, v3.

[Maxime Ripard]

Hi,

On Mon, Apr 08, 2019 at 01:04:42PM +0200, Maarten Lankhorst wrote:
> Op 08-04-2019 om 10:50 schreef Maxime Ripard:
> > On Fri, Apr 05, 2019 at 05:38:32PM +0200, Maarten Lankhorst wrote:
> >> Op 05-04-2019 om 15:54 schreef Paul Kocialkowski:
> >>> Hi,
> >>>
> >>> Le vendredi 05 avril 2019 à 14:52 +0200, Maarten Lankhorst a écrit :
> >>>> 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 think this is the case: cairo *only* takes linear buffers, so
> >>> we need the explicit tiling conversion step after having converted to a
> >>> new format with fb_convert. I don't see how it could work otherwise.
> >>>
> >>> Note that in igt, we're only interested in converting from linear to
> >>> tiled, not the other way round (for now, at least), so that's the
> >>> pipeline that the helper asssumes.
> >> We have code to handle this exact conversion in i-g-t already, both
> >> ways, see igt_get_cairo_surface(). :)
> >>
> >> You should be able to extend create_cairo_surface__convert() to
> >> handle broadcom tiling as well,
> >>
> >> I didn't see a function to convert from tiled to untiled, else I
> >> would have plugged it in for you.
> > That might be a bit dumb, but why do we need to use cairo all the
> > time in the first place?
> >
> > That seems like a waste of resources when the only thing you want to
> > do is a conversion of one buffer to the other.
>
> Cairo doesn't have its own internal buffer format, it uses the same pixman
> calls that igt_fb_convert_with_stride does, so it's not less efficient.
>
> The extra trip to convert the src buffer back after it's read from, or the
> unnecessary conversion of the target buffer before it's overwritten it with
> src buffer contents might be less efficient, but I don't think it's worth
> optimizing it.

Right, but I wasn't so much talking about the number of buffers, but
more about the function calls overhead.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/igt-dev/attachments/20190409/220ea05e/attachment-0001.sig>