RFC: hardware accelerated bitblt using dma engine

[Enrico Weigelt, metux IT consult]

On 03.08.2016 01:12, Rob Clark wrote:

Hi,

>> Well, if it already does buffer allocation and mapping (which might
>> also involve copying around phyisical buffers), why not also add
>> copy-between-buffers ?
> 
> except "dumb" buffers exist *only* for CPU rendered content, you
> cannot assume that a gpu can accelerate anything with them.

Exactly my usecase: having no (usable) GPU at all, but a an sdma
controller - or even better: an IPU - which can do the bitblt.
(maybe even w/ colorspace conversion, rotation, etc)

There might be GPUs which can also do that - and in that case it
should be done by the GPU.

> They basically exist just for simple splash screens and fbcon

Or when you dont have an (usable) GPU at all ?

> there is a reason that there is no generic gpu cmd submission ioctl.
> It is too much hw specific, 

Sure, but I'm not going to use an GPU at all, but different hw.

> and anyway it is only used by device
> specific userspace (ie. gl driver and/or xorg ddx)

Actually, on my targets I neither have gl nor xorg, and I'd like to
keep userland generic. I'd hate to hate to have lots of hw-specific
cairo-backends when I'll have to touch the kernel anyways, in order
to use smda or ipu.


By the way: while hacking a bit on mesa (backporting to Trusty),
I came around separate hw-specific calls for retrieving the video
memory size. Seems to be a really common thing ... is there any
hw that does not have such thing ? Couldn't that be an generic
ioctl() ?

I somewhat got the strange feeling that anything that goes beyond
very trivial dumb framebuffer has hw-specific ioctl's ;-o


--mtx