Re: [PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem

From: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
To: Daniel Stone <daniel@fooishbar.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Javier Martinez Canillas <javier@osg.samsung.com>
Subject: Re: [PATCH 00/25] Exynos DRM: new life of IPP (Image Post Processing) subsystem
Date: Thu, 12 Nov 2015 13:44:25 +0100	[thread overview]
Message-ID: <564489A9.5040709@math.uni-bielefeld.de> (raw)
In-Reply-To: <CAPj87rNz6vYrcjgV1fdSgE-ZCHnFFNfJKqskTsu2C1+KkmW_gQ@mail.gmail.com>

Hello,

Daniel Stone wrote:
> Hi Marek,
> 
> On 10 November 2015 at 13:23, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>> This patch series introduces a new life into Exynos IPP (Image Post
>> Processing) subsystem by integrating it (transparently for userspace
>> applications) with Exynos DRM core plane management. This means that all
>> CRTC drivers transparently get support for standard features of IPP
>> subsystem like rotation and scaling.
>>
>> Support for features not supported natively by CRTC drivers is
>> implemented with a help of temporary framebuffers, where image data is
>> processed by IPP subsystem before performing the scanout by a CRTC driver.
>>
>> This patchset is a first version of this 'new feature' and I would like
>> get some comments on the proposed approach. I plan to continue working
>> on enhancing Exynos DRM drivers and especially do the cleanup the IPP
>> subsystem.
>>
>> Most of the new features are added by the last 2 patches. All other
>> patches are bugfixes in various Exynos DRM subdrivers and significant
>> core rewrite - introducing a subclass of drm_plane_state was needed and
>> all drivers have been converted to use it. Some initial cleanups in IPP
>> subsystem were also needed to let Exynos core to call it internally from
>> the driver core. This part will be cleaned even more in the future.
> 
> Hm, interesting. The RPi has a similar setup - VC4 can work either
> online (realtime scanout) or offline (mem2mem). Once the scene crosses
> a certain complexity boundary, it can no longer be composed in
> realtime and must fall back to mem2mem before it can be displayed.
> 
> There was talk of having the fallback handled transparently in KMS for
> VC4 - similar to this - but the conclusion seemed to be that it was an
> inappropriate level of hidden complexity for KMS, and instead would
> best be handled by something like HWComposer directing it. Using HWC
> would then let you more intelligently split the scene from userspace
> (e.g. flatten some components but retain others as active planes).
I would be intererested in the performance implications of this
abstraction as well.

I'd like to use the Exynos FIMC for CSC and scaling, but this operation
of course takes some time.

I wonder how this interacts with page flipping. If I queue a pageflip
event with a buffer that needs to go through the IPP for display, where
does the delay caused by the operation factor it? If I understand this
correctly drmModePageFlip() still is going to return immediately, but I
might miss the next vblank period because the FIMC is still working on
the buffer.

My problem here is that this abstraction would take too much control
from the user.

Correct me if I have this wrong!

With best wishes,
Tobias

> 
> Dan V, Eric - thoughts?
> 
> Cheers,
> Daniel
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel