Add EGLStreams support for DRM backend

[danvd]

Supported:

1. Damage tracking
2. EGLStreams buffer allocator
3. VT switching, sleep/wakeup restoring
4. Client's wayland GL texture import
5. Multi-out

Known issues

1. Absence of Multi-GPU support. Due to lack of dma-buf (Nvidia's WIP)
2. Screenshots through dma-buf (the same reason). TODO with another
   approach if possible
3. XWayland acceleration support (Nvidia's WIP)
4. mpv with gpu -vo produces no output. Use wlshm

Note: All dma-buf extensions are disabled for EGLStreams mode.
Else chrome/chromium and other apps relying on them fail to start.

TIP: run mozilla with MOZ_ENABLE_WAYLAND=1, for chrome enable ozone with
wayland.

EGLStreams concepts are much like MacOS IOSurfaces.
The latter is proved to be reliable solution for frame buffer sharing/streaming.

Last note:
I'm aware about linux graphics devs politics regarding EGLStreams and have no illusion about the fate of this PR.
This is mainly for those who, like me, want to shake off dust from a stale nvidia GPUs.

P.S. I'm open to any issues and will try to add support for missing features if the proposed functionality will be merged.

[AdrianVovk]

When you mention the fate of the PR, do you intend on maintaining this as a patch if it doesn't get merged? Even if it does get merged: are you going to maintain the EGLStreams support? Because I'm sure the contributors here aren't going to want to do that

[danvd]

I use sway in my everyday activity and currently have no plans to change GPU at an early date (I'm not a gamer of any kind), so in terms of patch maintaining regular rebases are going to be done.
Not sure about new functionality requested by others in that case. This looks interesting only in mainstream case.

[L-as]

Wouldn't the future pure Vulkan backend support Nvidia too? Or am I misunderstanding how it works?

[ascent12]

Lets get it out of the way and say that this is definitely not going to be merged. Our policy for going out of our way for proprietary drivers is clear.

But even putting that aside, EGLStreams are incompatible with future plans we have for wlroots. Even now, this PR contains what I would consider dirty hacks, and the hacks are only going to get dirtier and more hacky as wlroots changes. There is obviously nothing stopping you from maintaining your own fork; it's free and open source software after all, but I do believe it's not going to be an easy job if you're going to track upstream.

[L-as]

@ascent12 Could you please elaborate on what the future plans are?

[danvd]

@ascent12 Fair point. The only credit I ask for is not to close this PR but mark it with some label, i.e. 'wont merge' or whatever that suits better, so it could be easily found if someone's interested.
Though i don't insist on that.

[mesufesu]

@danvd Where to properly report issues? For example, I haven't been able to produce output in Firefox and SDL fails, same things do work in respective Plasma/GNOME Wayland sessions.

[danvd]

@mesufesu You can open an issue in my fork

[solarkraft]

First of all: That's pretty cool. I thought it'd need Erik Kurzinger or someone else sponsored by Nvidia.

• Does "Absence of Multi-GPU support" mean the PRIME setup present on most laptops isn't supported?
• Do you plan to maintain this as a fork, something like wlroots-eglstreams or wlroots-nvidia?
• Is there a better place for questions and discussion than this thread?

Thanks!

[danvd]

@solarkraft
I'd suggest https://github.com/danvd/wlroots/issues as the place for discussions.

As for two other questions:

• Actually I have little knowledge about PRIME. Try if you have one. I guess it uses some kind of GPU sticking/switching around common shared memory area and is not true mgpu setup.
• About maintenance: As long as I'm using sway at home/work constant rebasing upon origin/master is likely to happen. Besides that, after smooth wayland experience it's really hard to go back to X11's tearing.

[emersion]

Thanks for your work. Sorry, I'm going to close this PR for the following reasons:

• This adds 1.5k lines of code for a single driver-specific API. There are a lot of places where the code-paths are doubled with an if (eglstreams). Also, there are quite a few workarounds in your patch.
• The driver happens to be closed-source. Closed-source drivers are hard to support because we can't look at their source code and fix them (something I do regularly with i915, amdgpu, nouveau and their shared code). Trying to understand why something goes wrong blind-folded is more time-consuming and encourages adding workarounds instead of properly fixing bugs.
• As @ascent12 explained, EGLStreams doesn't fit wlroots' design, and it's not going to improve. The EGLStreams allocator already relies on DRM backend details (planes). In the future the backends will stop allocating buffers (Move primary wlr_swapchain handling out of backends #2505), instead the allocator will have no knowledge of what buffers will be used for at allocation time. This is just one example of something that will cause issues, there are more (e.g. the renderer leaking into the backend).
• EGLStreams has no future really, there are no plans to make it work with e.g. Vulkan. Instead, NVIDIA seems to be meaning to add support for the APIs everyone else uses, like DMA-BUFs and Vulkan's DRM format modifiers extension. I think this is a much better path forward.

I don't think closing the PR will affect its discoverability. You're welcome to maintain a fork of wlroots with these patches, of course.