dumb BOs and prime

dumb BOs and prime

[Rob Herring]

I'm working on getting Android working with DRM drivers. ATM, I'm
using virtio-gpu as the driver and trying to get just KMS side working
without rendering. I have it working with stock AOSP and the emulated
fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to
get things working with native KMS using drm_gralloc and
drm_hwcomposer (now in AOSP). I've hit one problem though which I'm
not sure how to solve without hacking around it.

Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not
allowed on render nodes and drmPrimeHandleToFD is not allowed on
card0, so I'm stuck. I could open both nodes, but then I want the case
of no render node to work. After some searching, I thought it was a
matter of needing to do drmAuthMagic, but then found that is
considered obsolete[2].

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git android-4.4
[2] http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: dumb BOs and prime

[Daniel Stone]

Hi Rob,

On 4 December 2015 at 17:49, Rob Herring <robh@kernel.org> wrote:
> I'm working on getting Android working with DRM drivers. ATM, I'm
> using virtio-gpu as the driver and trying to get just KMS side working
> without rendering. I have it working with stock AOSP and the emulated
> fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to
> get things working with native KMS using drm_gralloc and
> drm_hwcomposer (now in AOSP). I've hit one problem though which I'm
> not sure how to solve without hacking around it.
>
> Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not
> allowed on render nodes and drmPrimeHandleToFD is not allowed on
> card0, so I'm stuck. I could open both nodes, but then I want the case
> of no render node to work. After some searching, I thought it was a
> matter of needing to do drmAuthMagic, but then found that is
> considered obsolete[2].

drmPrimeHandleToFD definitely is allowed on card0; does the driver set
the DRIVER_PRIME cap, and have a prime_handle_to_fd hook?

Cheers,
Daniel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: dumb BOs and prime

[Martin Peres]

On 04/12/15 19:49, Rob Herring wrote:
> I'm working on getting Android working with DRM drivers. ATM, I'm
> using virtio-gpu as the driver and trying to get just KMS side working
> without rendering. I have it working with stock AOSP and the emulated
> fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to
> get things working with native KMS using drm_gralloc and
> drm_hwcomposer (now in AOSP). I've hit one problem though which I'm
> not sure how to solve without hacking around it.
>
> Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not
> allowed on render nodes and drmPrimeHandleToFD is not allowed on
> card0, so I'm stuck. I could open both nodes, but then I want the case
> of no render node to work. After some searching, I thought it was a
> matter of needing to do drmAuthMagic, but then found that is
> considered obsolete[2].

Obsolete when using render nodes, but still necessary on usual nodes 
(/dev/dri/cardX) as far as I remember. The usual nodes can do everything 
the render nodes can do.

Authentication should help! Please make sure you are master or 
authenticated before doing anything on the usual nodes.

>
> Rob
>
> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git android-4.4
> [2] http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: dumb BOs and prime

[Benjamin Gaignard]

[-- Attachment #1.1: Type: text/plain, Size: 2665 bytes --]

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)

Benjamin


Le vendredi 4 décembre 2015, Martin Peres <martin.peres@linux.intel.com> a
écrit :

> On 04/12/15 19:49, Rob Herring wrote:
>
>> I'm working on getting Android working with DRM drivers. ATM, I'm
>> using virtio-gpu as the driver and trying to get just KMS side working
>> without rendering. I have it working with stock AOSP and the emulated
>> fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to
>> get things working with native KMS using drm_gralloc and
>> drm_hwcomposer (now in AOSP). I've hit one problem though which I'm
>> not sure how to solve without hacking around it.
>>
>> Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not
>> allowed on render nodes and drmPrimeHandleToFD is not allowed on
>> card0, so I'm stuck. I could open both nodes, but then I want the case
>> of no render node to work. After some searching, I thought it was a
>> matter of needing to do drmAuthMagic, but then found that is
>> considered obsolete[2].
>>
>
> Obsolete when using render nodes, but still necessary on usual nodes
> (/dev/dri/cardX) as far as I remember. The usual nodes can do everything
> the render nodes can do.
>
> Authentication should help! Please make sure you are master or
> authenticated before doing anything on the usual nodes.
>
>
>> Rob
>>
>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
>> android-4.4
>> [2]
>> http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>

-- 

Benjamin Gaignard

Graphic Working Group

Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs

Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>

[-- Attachment #1.2: Type: text/html, Size: 4813 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: dumb BOs and prime

[Rob Herring]

On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
<benjamin.gaignard@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

>
> Benjamin
>
>
> Le vendredi 4 décembre 2015, Martin Peres <martin.peres@linux.intel.com> a
> écrit :
>>
>> On 04/12/15 19:49, Rob Herring wrote:
>>>
>>> I'm working on getting Android working with DRM drivers. ATM, I'm
>>> using virtio-gpu as the driver and trying to get just KMS side working
>>> without rendering. I have it working with stock AOSP and the emulated
>>> fb with a few additions to the virtio-gpu driver[1]. Now I'm trying to
>>> get things working with native KMS using drm_gralloc and
>>> drm_hwcomposer (now in AOSP). I've hit one problem though which I'm
>>> not sure how to solve without hacking around it.
>>>
>>> Is prime allowed on dumb BOs? AIUI, dumb buffer allocation is not
>>> allowed on render nodes and drmPrimeHandleToFD is not allowed on
>>> card0, so I'm stuck. I could open both nodes, but then I want the case
>>> of no render node to work. After some searching, I thought it was a
>>> matter of needing to do drmAuthMagic, but then found that is
>>> considered obsolete[2].
>>
>>
>> Obsolete when using render nodes, but still necessary on usual nodes
>> (/dev/dri/cardX) as far as I remember. The usual nodes can do everything the
>> render nodes can do.
>>
>> Authentication should help! Please make sure you are master or
>> authenticated before doing anything on the usual nodes.
>>
>>>
>>> Rob
>>>
>>> [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
>>> android-4.4
>>> [2]
>>> http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/slides.pdf
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>
>
> --
>
> Benjamin Gaignard
>
> Graphic Working Group
>
> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: Facebook | Twitter | Blog
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: dumb BOs and prime

[Greg Hackmann]

On 12/04/2015 11:23 AM, Rob Herring wrote:
> On Fri, Dec 4, 2015 at 12:40 PM, Benjamin Gaignard
> <benjamin.gaignard@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.

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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: dumb BOs and prime

[Rob Herring]

On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann <ghackmann@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@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?

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

Re: dumb BOs and prime

[Stéphane Marchesin]

On Sat, Dec 5, 2015 at 3:40 PM, Rob Herring <robh@kernel.org> wrote:
> On Fri, Dec 4, 2015 at 5:48 PM, Greg Hackmann <ghackmann@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@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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel