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 <stsch...@gmail.com> wrote:
Hey Robert,
On Wed, Mar 21, 2018 at 4:16 PM, Robert Foss <robert.f...@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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
