[Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Tomasz Figa]

On Fri, Mar 23, 2018 at 3:03 AM, Robert Foss <robert.foss at collabora.com> wrote:
> Hey Tomasz,
>
>
> On 03/22/2018 09:27 AM, Tomasz Figa wrote:
>>
>> Hi Stefan,
>>
>> On Thu, Mar 22, 2018 at 8:42 AM, Stefan Schake <stschake at gmail.com> wrote:
>>>
>>> Hey Robert,
>>>
>>> On Wed, Mar 21, 2018 at 4:16 PM, Robert Foss <robert.foss at collabora.com>
>>> wrote:
>>>>
>>>> Hey,
>>>>
>>>> I've started looking into removing the gralloc method
>>>> GRALLOC_MODULE_PERFORM_GET_DRM_FD.
>>>>
>>>> The issues around this seems to be two parts:
>>>> 1) Finding the right device to open
>>>> 2) Sharing the device between components
>>>>
>>>> Sharing the device between components
>>>> -------------------------------------
>>>>
>>>> Currently the device is used by drm_hwc, gbm_gralloc and mesa.
>>>>
>>>> drm_hwc opens the *primary* node in DrmResources::Init() and creates an
>>>> internal model of what properties/components the device has.
>>>>
>>>> gbm_gralloc uses the *render* node during in gbm_dev_create().
>>>>
>>>> Mesa uses uses the *render* node during dri_screen creation in
>>>> dri2_create_screen() and for loading the driver in
>>>> dri2_initialize_android().
>>>>
>>>> However, problematically, drm_hwc uses OpenGL composition as a fallback
>>>> method, and when doing so mesa has to be able to import buffers, which
>>>> means
>>>> mesa has to use a *primary* node.
>>>>
>>>> The way this is currently worked around in production systems seems to
>>>> be to
>>>> disable drm master authentication. This is at least what ChromeOS &
>>>> Intel
>>>> are doing as far as I understand it.
>>>>
>>>
>>> Thanks for kicking this off.
>>>
>>> I've done a few tests on 2) with VC4 and 8.1.0_r18. With drm_hwc the
>>> primary
>>> or master on card0 and gbm_gralloc & Mesa each getting their own fd from
>>> render128, I didn't need any of the DRM authentication hacks in the
>>> kernel
>>> anymore. That's with full overlay composition, everything forced to hwui
>>> GL
>>> composition or everything done through my hacked up ES2 version of
>>> glworker
>>> in drm_hwc (well it made it to launcher until succumbing to a resource
>>> leak).
>>> So I don't think mesa would need a master node and could make do with
>>> render.
>>
>>
>> Thanks for checking this. It seems to match my assumptions, which I
>> described in my reply to Rob's email.
>
>
> Alright, so some kind of probing seems to be the way forward then.
> What I'm wondering is what kind of properties of a render node would be the
> best
> to match against.
>
> For a quick reference of what information is available through
> drmGetDevices2, ran drmdevice[1], which gave this output:
>
> Opening device 0 node /dev/dri/renderD129
> device[0]
>         available_nodes 0005
>         nodes
>                 nodes[0] /dev/dri/card1
>                 nodes[2] /dev/dri/renderD129
>         bustype 0000
>         businfo
>                 pci
>                         domain  0000
>                         bus     00
>                         dev     02
>                         func    0
>         deviceinfo
>                 pci
>                         vendor_id       8086
>                         device_id       191b
>                         subvendor_id    1028
>                         subdevice_id    06e4
>                         revision_id     06
>
>
> [1] https://github.com/grate-driver/libdrm/blob/master/tests/drmdevice.c

Perhaps we could try to use drmOpenWithType() [2]. We could have one
property that would be passed as "name" argument and another property
for "busid" argument. I assume "type" would be always RENDER?

[2] https://cgit.freedesktop.org/mesa/drm/tree/xf86drm.c#n733

Best regards,
Tomasz