[Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Tomasz Figa]

Hi Rob,

On Thu, Mar 22, 2018 at 12:16 AM, Robert Foss <robert.foss at collabora.com> wrote:
> Hey,
>
> I've started looking into removing the gralloc method
> GRALLOC_MODULE_PERFORM_GET_DRM_FD.

Thanks a lot for looking into this.

>
> The issues around this seems to be two parts:
> 1) Finding the right device to open
> 2) Sharing the device between components
>
>
> Finding the right device to open
> --------------------------------
>
> Using a static path for the device is problematic if an image is used on
> more than a single HW revision, since no static device <-> device path
> mapping can be guaranteed.
>
> For a single HW revision the device <-> device path mapping will probably be
> the same, but it is still dependent on the order of devices being probed
> during initialization.
>
> Previously I've hacked up a solution for selecting the device path from an
> Android property. This property still has to be set somewhere, and I ended
> up having the bootloader provide it since it was device specific anyway. But
> it was hardly a neat solution, and I don't see any other static solutions
> that are all that much more neat. But suggestions are welcome.
>
> So that leaves probing, I'm not sure what a good probing solution would look
> at this point.

One idea I suggested in another thread[1], and which apparently didn't
run into too much opposition, was having a property to force matching
with given DRM driver name or bus ID, but if one is not present, just
use the first node that matches any existing driver.

[1] https://lists.freedesktop.org/archives/mesa-dev/2018-February/186400.html

>
>
> 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.

Hmm, I don't see why Mesa in drm_hwc process couldn't open a render
node. IMHO drm_hwc already uses DMA-buf, so there shouldn't be any
problem with imports on either side.

>
> 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.

We don't have such problem in Chrome OS, but we don't use drm_hwc
there either. Android-side uses render nodes only and our hwcomposer
defers composition to Chrome (by sharing DMA-buf FDs and metadata of
the layers), which uses master node, but it does so only in the
single, isolated GPU process, so there is no authentication needed.

Best regards,
Tomasz