RFC: hardware accelerated bitblt using dma engine

[Enrico Weigelt, metux IT consult]

On 02.08.2016 16:04, Daniel Vetter wrote:

> If you mean "add a generic hw-accelerated bitblt operation": This is not
> hw drm works. The generic kms stuff is about display only, with just very
> basic (hence "dumb") buffer allocation support in a generic way.

Well, if it already does buffer allocation and mapping (which might
also involve copying around phyisical buffers), why not also add
copy-between-buffers ?

> If you mean "expose the dma engine I have here to userspace in
> driver-private ioctls with the trade-off logic between that, kms
> compositing using the display block and memcpy in userspace", then go
> ahead ;-) But if you do that, pls don't don't forget that for any uapi the
> drm subsytem requires correspoding open source userspace (in a real
> app/compositor, not just some toy test or something similar).

I dont intent to add yet another specific driver and driver-specific
ioctl()s, but instead a generic interface. Such stuff needs kernel
support and kernel configuration anyways, so I'd like to keep it out
of userland's business.


--mtx