[Mesa-dev] Removing GRALLOC_MODULE_PERFORM_GET_DRM_FD

[Robert Foss]

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
>