Re: RFC: hardware accelerated bitblt using dma engine

[Daniel Vetter <daniel@ffwll.ch>]

On Fri, Aug 05, 2016 at 01:16:55AM +0200, Enrico Weigelt, metux IT consult wrote:
> 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) ?

Of course. In drm you can export/import gem buffers from to dma-buf. See

https://dri.freedesktop.org/docs/drm/gpu/drm-mm.html#prime-buffer-sharing

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel