dumb BOs and prime

[Daniel Vetter]

On Fri, Dec 04, 2015 at 03:48:26PM -0800, Greg Hackmann wrote:
> On 12/04/2015 11:23 AM, Rob Herring wrote:
> >On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
> ><benjamin.gaignard at linaro.org> wrote:
> >>Hi Rob,
> >>
> >>I got the same problem today with sti drm/kms driver and dumb Bo.
> >>The issue comes become hwcomposer because is the master and authenticated on
> >>/dev/dri/cardX
> >>Dumb allocation is done by gralloc which does a new open (so it is not
> >>authenticated) on drm node the consequence is that we can't use prime
> >>functions...
> >>If you use render node you won't be able to call dumb functions.
> >>
> >>To get out of this I think I will implement additional helpers in gem_cma to
> >>have ioctl like DRM_GEM_CMA_CREATE and DRM_GEM_CMA_MMAP
> >>and call them instead of dumb so be able to use render node.
> >>Of course it is only for drivers which already use gem_cma helpers (like
> >>sti)
> >
> >That's only marginally better than per driver BO calls which is the
> >whole thing I'm trying to avoid. There should be some way to pass the
> >auth token to gralloc?
> >
> >Rob
> 
> Frankly, you probably want to approach this by allocating dma-bufs using
> something external to DRM (probably ion) and then have your hwcomposer
> import them into DRM when they're passed to the display.
> 
> Backing gralloc allocations with dumb BOs doesn't really fit the way gralloc
> is designed: like dma-buf, it's built around passing buffers between
> different hardware blocks, and some of those buffers may never even touch
> the display hardware.  You'll also run up against other (deliberate)
> limitations of dumb BOs like not being able to allocate YUV buffers.
> 
> Unfortunately this currently means adding some shim driver code to create
> the ion device.  (Device-Tree bindings for ion are on my long, long backlog
> of things to do.) It's not a lot of code, especially if all you need is a
> CMA heap, but it's still non-zero.

Yeah at plumbers in seattle we discussed this and pretty much all agreed
that for these kind of embedded cases ION makes tons of sense as the
backing allocator. Trying to use dumb buffers for everything really isn't
how it's meant to be, and it shows in all the hacks added and hoops you
still need to jump through.

As Greg says there's some polish left to do for really neat ION
integration, but we captured that in drivers/staging/android/TODO.

> Note that supporting dumb BOs in your KMS driver is still useful, since the
> recovery console in AOSP has KMS support now.  In that case it's a single
> privileged process software-rendering everything, so it bypasses
> gralloc/hwcomposer and calls directly into libdrm.

Yeah, dumb buffers is for emergency consoles and for boot splash (where
loading GL is either not yet possible or too expensive). Anything else
will result in sizeable amounts of hurt.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch