RFC: hardware accelerated bitblt using dma engine

[Rob Clark]

On Tue, Aug 2, 2016 at 5:43 PM, Enrico Weigelt, metux IT consult
<enrico.weigelt at gr13.net> wrote:
> 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 ?

except "dumb" buffers exist *only* for CPU rendered content, you
cannot assume that a gpu can accelerate anything with them.

They basically exist just for simple splash screens and fbcon

>> 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.

there is a reason that there is no generic gpu cmd submission ioctl.
It is too much hw specific, and anyway it is only used by device
specific userspace (ie. gl driver and/or xorg ddx)

BR,
-R

>
> --mtx
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel