On Fri, Mar 23, 2018 at 3:03 AM, Robert Foss <[email protected]> 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 <[email protected]> wrote: >>> >>> Hey Robert, >>> >>> On Wed, Mar 21, 2018 at 4:16 PM, Robert Foss <[email protected]> >>> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
