Re: [RFC 0/2] New feature: Framebuffer processors

[Dave Airlie <airlied@gmail.com>]

On 22 August 2016 at 19:44, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> Dear all,
>
> This is the initial proposal for extending DRM API with generic support for
> hardware modules, which can be used for processing image data from the one
> memory buffer to another. Typical memory-to-memory operations are:
> rotation, scaling, colour space conversion or mix of them. In this proposal
> I named such hardware modules a framebuffer processors.
>
> Embedded SoCs are known to have a number of hardware blocks, which perform
> such operations. They can be used in paralel to the main GPU module to
> offload CPU from processing grapics or video data. One of example use of
> such modules is implementing video overlay, which usually requires color
> space conversion from NV12 (or similar) to RGB32 color space and scaling to
> target window size.
>
> Till now there was no generic, hardware independent API for performing such
> operations. Exynos DRM driver has its own custom extension called IPP
> (Image Post Processing), but frankly speaking, it is over-engineered and not
> really used in open-source. I didn't indentify similar API in other DRM
> drivers, besides those which expose complete support for the whole GPU.

So I'm with the others in that it's a road we've travelled and learned from,
generic accel API don't work very well long term.

What will happen is the next generation exynos will have a command queue
for it's dma engine or whatever and someone will shoehorn that into this API
because this API exists, even if it isn't suitable.

What are the requirements for having this API, what userspace feature is driving
it, compositors?, toolkit rendering?

Dave.