[Tomdarkness]

From what I understand after briefly looking into this earlier this month the issue seems to be basically NVIDIA want to push their own buffer API (EGLStreams) rather than use the buffer API developers are actually using (GBM).

If you use one of the "big" compositors like GNOME or KDE I believe they have sort of added EGLStreams support so you can use it on NVIDIA but it's not perfect. If you use a more niche one, e.g sway, then it won't work on the NVIDIA proprietary drivers because they don't support GBM.

There is some news recently that NVIDIA may be coming around and are in the progress of implementing GBM support in their drivers, but it's not confirmed.

You can also use the nouveau nvidia drivers but from what I understand the performance is trash in 3d applications using modern cards, it seems more orientated to supporting older nvidia cards.

[jjoonathan]

NVIDIA tends to be good (in an evil way) at proprietary lock-in, but they also tend to be good (in a genuine way) at making better thought-out and more advanced APIs. What's the balance of these two qualities in EGLStreams (as compared to GBM)?

[ZeroCool2u]

I've looked into this myself before, because I was curious and had the same thought as you. I don't feel comfortable making any detailed claims about GBM vs EGLStreams and which is better, but I will say there are absolutely some tradeoffs between the two and neither is entirely without merit.

The thing that is worth noting is how this situation came to be. That is, there was at one point a conference where the community invited AMD, Intel, and NVidia to discuss the future of this API and Nvidia was a no show for some reason. Those who showed ended up producing GBM, Nvidia pulled EGLStreams out of a hat, and the rest is history.

Who knows, maybe it was something as simple as scheduling and the people at Nvidia that needed to be there couldn't make it? Maybe in another timeline this mess could have been avoided entirely.

[akoncius]

linux development is one of those areas where physical absence is not required in order to participate in discussion and to collaborate with other participants, so it sounds to me more like excuse rather than proper explanation why nvidia decided to go another route :)

[jjoonathan]

Yes, but there is an argument to be had that sole ownership and lack of design-by-committee is exactly why NVIDIA can put out better APIs.

Money and proximity to hardware development would be the competing factors, and normally I'd like to pin the attribution on them, but there's just one small problem: I've been on a bunch of committees and they have pushed my estimation of typical committee dysfunction to extraordinary levels.

[trissylegs]

There's also the External memory extensions for Vulkan and OpenGL. All the vendors support the Vulkan api. https://vulkan.gpuinfo.org/listdevicescoverage.php?extension...

But not sure about the OpenGL (I think Nvidia do).

These apis let you export a FD for sharing. Pretty sure you can import (scanout compatible) objects into DRI/DRM/KMS. Which is what libgbm does for Mesa drivers.

Although most compositors (including wl_roots based ones) still use libgbm as they might also need to support embedded hardware. (eg: Tizen).

(In the original release of Vulkan intel has a weird "unofficial" extension that let you export a FD. and khr had a VK_cube demo that could directly use KMS with Vulkan using this "extension". This was removed as it was only there to test Vulkan before any window manager integration was implemented)

[rofrol]

NVIDIA will use DMA-BUF instead of EGLStreams https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-4...