dumb BOs and prime

[Stéphane Marchesin]

On Sat, Dec 5, 2015 at 3:40 PM, Rob Herring <robh at kernel.org> wrote:
> On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann <ghackmann at google.com> 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.
>
> Yes, I realize dumb BO are not the long term nor production solution.
> ATM, I'm just looking for getting things working on new platforms
> without the need for lots of userspace changes. Perhaps I could just
> use fb emulation, but having DRM code paths tested is valuable IMO.
>
>> 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.
>
> Laura is working on that. I'm still a bit skeptical about what should
> go in DT though.
>
>> 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.
>
> I've not seen that. Where does that live?

https://android.googlesource.com/platform/bootable/recovery/+/1a92c4458dcc983f624a60fb75f9679c213e6814

Stéphane

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