[Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD
Robert Foss
robert.foss at collabora.com
Thu Mar 22 18:03:25 UTC 2018
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
>
>>
>> The one thing that mesa on a render node definitely breaks is flink/GEM names
>> which drm_gralloc uses (the Android-x86 version anyway). No flink anything
>> with render nodes; drm_gralloc would have to move to dmabuf fds.
>
> I really wonder why those are still in use...
>
>>
>> That said, it would finally get rid of the strict coupling between Mesa and
>> gralloc. Ripping out the PERFORM and drm_gralloc facsimile in gbm_gralloc
>> saves a big bunch of code:
>>
>> https://github.com/stschake/gbm_gralloc/tree/libdrm_handle_def
>>
>> With more in mesa/platform_android from the flink stuff.
>
> Nice diffstat. ;)
>
> Best regards,
> Tomasz
>
More information about the mesa-dev
mailing list