1580166 - Implement DMAbuf backend for EGL/X11

Status: RESOLVED FIXED

(Core :: Widget: Gtk, enhancement)

Description

[Martin Stránský [:stransky] (ni? me)]

Implement GPU located graphics surfaces for Mozilla Firefox X11 backend.
The GPU surfaces can be used as store of decoded video frames
and can be shared across processes. It allows to perform one or zero copy architecture as it's used in Chomium browser:

https://software.intel.com/en-us/articles/native-one-copy-texture-uploads-for-chrome-os-on-intel-architecture-enabled-by-default

This can be used with EGL or GLX backend.

Comment 1

[pasik]

I'm curious, is anyone currently working on this?

Comment 2

[Darkspirit]

This bug depends on bug 788319 which depends on bug 1474281 which awaits review.

Comment 3

[Martin Stránský [:stransky] (ni? me)]

Bug 788319 (switch X11 to EGL) can be fixed without Bug 1474281 so Bug 1474281 does not block it. Bug 1474281 just changes used EGL variant here.

Comment 4

[Darkspirit]

This pull request adds DMABUF/EGL/X11 screen capture to OBS: https://github.com/obsproject/obs-studio/pull/1758

Comment 5

[Darkspirit]

(Robert Mader [:rmader] from bug 1619523 comment 11)

I also gave this a look today and if I understand things correctly, all possibilities to go forward here require some serious effort. That is assuming the goal is shipping things enabled by default - because everything else I'd consider wasted time.

• use EGL with DMABUF: EGL facilitates things quite a bit, but what's missing is GBM support on X11. So we'd need to reimplement things that are much easier on Wayland + potential bugs in drivers IIUC. No NVidia support, i.e. we'd only target platforms that could as well use Wayland.

I'm not a developer, but I searched a bit for GBM on X11:

https://www.raspberrypi.org/forums/viewtopic.php?t=250271#p1527921

DRM supports a single client at a time. If X is running then it is the one true client, and anything else will be told permission denied. This is expected.
If you wish to run within X then you need to look at composing via EGL, not via GBM/DRM.

Legacy DRI2:
https://eleni.mutantstargoat.com/hikiko/2013/05/28/gbm-and-x-2/

To create a GBM buffer you first need to create a drm device and then use its device descriptor to create a gbm device. To do this under X you need a way to tell xserver which device you use to avoid permission issues.

I made a GitHub-wide search for above "gbm_create_device xcb_dri2_authenticate" and found an old Mozilla repository:
https://github.com/pcwalton/linux-drm-sharing-test

This is a demonstration of how to use cross-process texture sharing using DRI/DRM directly on Linux. The client process (drm-client), which is intended to have lower privileges, does not need an X connection; you can see the resources that it is using with strace.

Be warned that, because we are using DRI2, the drm-client can access all publicly accessible GPU buffers in the system. This should be fixed with DRI3, which uses file descriptors instead of global names (see [1]).

KDE, X11, Debian Testing:

$ xdpyinfo | grep DRI
    DRI2
    DRI3

XWayland is DRI3-only.

DRI3:
https://github.com/swaywm/wlroots/issues/1352

X11
Use the dri3 and present extension directly. The dri3 extension can give us the DRM render node.

https://github.com/TexasInstruments/dri3wsegl/blob/2d8f701ebe429b0625f9523778dddc65b8593e85/dri3test.c

https://github.com/iXit/wine-nine-standalone/blob/bf71ae00220265749cc6af1e1e81f5b287891e0a/d3d9-nine/dri3.c

From 2013: https://lwn.net/Articles/569701/ + https://keithp.com/~keithp/talks/xdc2013-dri3.pdf

Comment 6

[Darkspirit]

This may help to make VAAPI work even with DRI3-only XWayland:
https://github.com/intel/libva/issues/122#issuecomment-331414538

the user can just call xcb_dri3_open() themselves and pass the fd to vaGetDisplayDRM()

Edit: It seems vaGetDisplayDRM could work on Wayland as well.

Comment 7

[Martin Stránský [:stransky] (ni? me)]

Yes, I used the DRM display at Bug 1619523 WIP and seems to be working okay.