RFC: hardware accelerated bitblt using dma engine

Dave Airlie airlied at gmail.com
Wed Aug 3 03:47:54 UTC 2016


On 3 August 2016 at 13:33, Enrico Weigelt, metux IT consult
<enrico.weigelt at gr13.net> wrote:
> 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

The thing isstuff looks generic until you go to use it, just abstract
it in userspace.

Because no hw is the same once you go beyond that.

Video memory size means what? VRAM, GPU accessible system RAM,
amount of CPU visible VRAM?

Dave.


More information about the dri-devel mailing list