NVIDIA To Meet With Wayland, Linux Kernel Developers To Discuss GBM vs. Streams

[chuckula]

This is basically Mesa vs EGL. Wayland is tied to Mesa which won't work on anything that's not Linux (not a problem for Wayland, but a problem for Nvidia which shares a lot of driver code among platforms), while Nvidia went for EGL because it's cross platform (but what's Wayland to do if it goes EGL and then the world goes all Vulkan?).
Imho, this isn't something we can figure out on a forum, it's better to let those involved agree on something (not like they're not ignoring us anyway ).

That might be one way to look at it. I believe there's an equivalent to EGL for Vulkan but it's a different API, although both could co-exist as different backends for a Wayland compositor without requiring changes to the protocol.

Ironically, Intel's open source drivers are regularly trashed on here for being tied to Mesa instead of the LLVMpipe "standard" (even though Mesa and Intel's open source driver existed first). So basically it looks like you should always use the Mesa "standard" except for when the crowd arbitrarily decides that Mesa is bad and you shouldn't use it. Great.

[Trevelyan]

I actually read mailing list conversations. While it is true that both GBM and GLStreams have their pros and cons, the clear thing that both camps could agree on is that neither are complete solutions. Both would need a lot of development to provided that would really make efficient use of the underlying hardware. It not clear which would form the correct base to start such development from. The question became do you start from the Kronos standard and further develop the API (i.e. release a new version of the standard); that no one using (yet). Or do you start from GBM that is already bringing used by everyone (except NVIDIA).

So this meeting will be about what is really needed, what is missing from both, and how to proceed together (I would assume).

[bug77]

That might be one way to look at it. I believe there's an equivalent to EGL for Vulkan but it's a different API, although both could co-exist as different backends for a Wayland compositor without requiring changes to the protocol.

Well, or course backends can be changed without changing the protocol. That was never an issue. This about Weston as the default implementation. Wayland in no way mandates the use of GBM over EGL, but Weston went with GBM, then Nvidia wanted something else and here we are today.

(Sorry, I wrote Wayland where I should have written Weston in my previous post.)

[Ancurio]

Here's the standards document for EGL streams, which as you can see was approved back in 2011:
https://www.khronos.org/registry/egl...KHR_stream.txt

IIRC, back when this extension was developed, it was for media processing purposes, hence all the references to OpenMAX and audio/video sync. It was definitely not designed with compositors / surfaces in mind. Nvidia retrofitted it for that later on.

[jrch2k8]

Well to be honest both approaches have merits and demerits.

Demerits:

EGL streams:
1.) no one ever implemented it outside recently nvidia
2.) non atomic
3.) some very explicit information is kinda vaguely defined(as i interpret from the expert posts)
4.) seems very tough to integrate to KMS
5.) Seems latency/timing information is fixed and not very accurate and can trash wayland "each frame is perfect" goal
6.) 100% incompatible with all current wayland compositors(Weston, Mutter, E17, Kwin)
7.) it seems Vulkan WSI would not work naturally here or will have severe issues(as far as i get from the experts)

GBM and EGL:
1.) Mesa specific and require KMS but tailored for Wayland goal of "each frame is perfect"

Merits:
EGL streams:
1.) Khronos kinda standard(again like OpenGL many things are veguely defined and can lead to vendor specific issues all over the place)
2.) would allow nVidia to kinda support wayland(apparently with heavy timing issues or hacks) from the user space driver instead of proper atomic KMS

GBM and EGL:
1.) 100% supported and battle tested
2.) Atomic and support full time/latency accuracy(again as far as i get it from the experts)
3.) proper KMS support
4.) can be expanded to support or accomodate nVidia drivers if needed.

So, is not a political issue only since there are technical and financial motivations for each option, so lets the expert reach an agreement

[c117152]

nVidia likes shims. Now they get to shim their shim.

Problem solved.

[bregma]

Can somebody provide a good technical discussion of the pros/cons of GBM vs. EGL Streams?

Without getting too technical, EGLStreams basically hides buffer allocation and swapping in the driver, and GBM put it in the control of the display server. There are advantages and disadvantages to both. In nVidia's case, using EGLStreams allows the driver to take advantage of the hardware and reusing cross-platform driver code in ways not possible through GBM. In Weston's case, using only GBM simplifies the cross-driver code and eliminates potential bug sources and race conditions.

[log0]

Can somebody provide a good technical discussion of the pros/cons of GBM vs. EGL Streams?
So far all I have heard is name-calling against Nvidia for supposedly not following "standards" since they aren't using GBM but from what little I can tell, EGL streams are a cross-platform documented standard that's part of EGL and that goes all the way back to 2012, well before Wayland was a viable project: https://www.khronos.org/registry/egl...KHR_stream.txt

It is not about EGL streams vs GBM, but about nvidia wanting to extend EGL streams to provide GBM like functionality vs GBM... if I remember correctly.

[cj.wijtmans]

Without getting too technical, EGLStreams basically hides buffer allocation and swapping in the driver, and GBM put it in the control of the display server. There are advantages and disadvantages to both. In nVidia's case, using EGLStreams allows the driver to take advantage of the hardware and reusing cross-platform driver code in ways not possible through GBM. In Weston's case, using only GBM simplifies the cross-driver code and eliminates potential bug sources and race conditions.

That makes no sense, egl is a standard, it has nothing to do with drivers.

[starshipeleven]

Except cities are planned the same way regardless of where the steering wheel is

Was an example man.

There is also no way in hell EU would agree on something in a reasonable timescale, so in a realistic situation the US would have gone alone (with UK support) on this, while the rest of EU was hotly debating the issue for the following years.