RFC: hardware accelerated bitblt using dma engine

Marek Szyprowski m.szyprowski at samsung.com
Wed Aug 3 09:24:37 UTC 2016


Hi Enrico,


On 2016-08-02 15:21, Enrico Weigelt, metux IT consult wrote:
> I'm currently thinking about adding an hw-accelerated bitblt operation.
> The idea goes like this:
>
> * we add some bitblt ioctl which copies rects between bo's.
>    (it also handles memory layouts, pixfmt conversion, etc)
> * the driver can decide to let the GPU or IPU do that, if available
> * if we have an suitable DMA engine (maybe only the more complex ones
>    which can handle lines on their own ...) we'll use that
> * as fallback, resort to memcpy().
>
>
> Whether an dma engine can/should be used might be highly hw specific,
> so that probably would be configured in DT.
>
> To use that feature, userland could actually allocate two BO's,
> one that's mapped as a framebuffer to some crtc, another one just
> a memory buffer. It could then render to the fast memory buffer and
> tell the DRM to only copy over the changed regions to the graphics
> memory via DMA (or whatever is best on that particular hw platform).
>
>
> What do you think about that idea ?

I'm working now on something similar, but more generic. There is already
a framework for picture processing (converting, scaling, blitting, rotating)
in Exynos DRM. It is called IPP (Image Post Processing), but its user
interface is really ugly and limited, so I plan to rewrite it and make
it really generic. Some discussion on it were already in the following
thread:
http://thread.gmane.org/gmane.linux.kernel.samsung-soc/49743

I plan to propose an API based on DRM object/properties, which will be
similar to KMS atomic API. I will let you know when I have it ready for
presenting in public.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland



More information about the dri-devel mailing list