RFC: hardware accelerated bitblt using dma engine

[Enrico Weigelt, metux IT consult]

On 04.08.2016 09:50, Daniel Vetter wrote:

Hi,

> One problem with 2d blitters is that there's no common userspace
> interface, but many: Xrender, hwc, old X drawing api, various attempts by
> khronos to standardize something, cairo, ... 

We're talking about userland APIs, not kernel->userland interfaces.
For userland APIs, I'm right now primarily interested in cairo
(using it for my tiny widget toolkit) ... but I'm also thinking about
setting X ontop of someting cairo-alike some day - or making gallium
that layer.

> It's probably worse than video decoding even, and definitely not like
> on the 3d side where there's GL (and now vulkan) and that's it.

On video side we have v4l for the kernel interface and gst as userland
framework ... looks like a good compromise to me.

> So you you'll end up with tons of glue code everywhere anyway. 

Actually, I'd like to get the glue code smaller. Putting both cairo
and X onto the common driver base (something that's somewhere between
xorg video drivers and cairo surface backends) seems a good way to go,
even though there'll be a lot of work to do for that.

> Adding yet another kernel uapi doesn't help, but forcing it to be generic
> will make sure it's inefficient. Which means someone else then will
> create another one.

hmm, I'm not yet convinced that it necessarily will be inefficient.

To clarify the scope: I'm talking only about _dedicated_ units, which
are completely orthogonal to complex gpus (basicly, just specialized
dma controllers).

I personally don't care so much whether it's in DRM, V4L or whatever.
DRM just seemed to be a good place to me.

By the way: as the number of such controllers increases, for dozens
of different things, eg. IO, crypto, etc., and in many cases they're
able to directly access the same memory, I got the feeling that we
should generalize gems even further, so that they could be any kind
of buffer that may be passed to any kind of device. (hmm, reminds me
on some ancient mainframe concepts).

> If the blitter is always attached to the display block just add a few gem
> based ioctls there (like with desktop gpus) for submitting blit workloads.
> Otherwise new driver I guess.

hmm, can I use gems outside DRM ?
eg. would it be possible to write an storage controller driver that
directly accesses an some gem (eg. let the controller write out an
gem object) ?


--mtx