NVIDIA Proposes Mesa Patches To Support Alternative GBM Back-Ends

[StillStuckOnSI]

As is, this puts mesa pretty much on the wall: they are the bad guys if they decline the merge request (due to unclear future) and they risk problems with (code and other contributing members) in the future if the accept it.

I wonder how much of an impact making a stink on public forums and publicly supporting the mesa devs had on this decision. i.e. not yet another "novideo" joke, but lighting a fire under their PR in every possible social media venue. If it had a non-negligible impact, perhaps we as a community should keep at it to get more concessions out of Nvidia.

[Slartifartblast]

A day in the life of Nvidia Propriety Driver writing to support Wayland.....

[BwackNinja]

They've quietly conceded that libgbm is worthwhile to implement, at least on Tegra.

Last version without libnvgbm.so:
https://docs.nvidia.com/jetson/archi...son_nano.html#

Introduction of libnvgbm.so:
https://docs.nvidia.com/jetson/archi...son_nano.html#

Description of current wayland support and experimental libgbm support (while eglstreams is still an option)
https://docs.nvidia.com/jetson/l4t/T...land.69.1.html

It would be really nice if they did support the api on x86/x86_64 too, but even then there still needs to be something like libglvnd to wrap multiple libgbm implementations.

As I said back in October, they were already doing this for Tegra and had it documented as experimental, so it was only a matter of time. It's also the same guy that was behind liballocator - https://github.com/cubanismo/allocator

I'm more excited about re-adding (and improving) loadable backends for gbm. It's not just Nvidia that has a libgbm implementation, and packaging creates conflicts without such a mechanism. Now libgbm will make sense external to mesa and whole graphics drivers are loadable and selectable using configuration files with the combination of this improved libgbm and libglvnd. This also makes splitting out old mesa drivers even easier.

[You-]

I remember the huge amount of slating open source devs got on this forum for not understanding nVidia or bending backwards to their will.

Though I doubt there will be much instrospection.

[BwackNinja]

This is probably commendable but IF they are now doing GBM, this is once more completely backwards (or is it just me?)
Now mesa should merge a Nvidia authored feature because maybe (who knows?) they plan to support it with their driver?
Nvidia, can you just be 'open' about your intentions for once? You have an entire open-nvidia community that is ready to pave the way for you (and mesa community would likely be highly supportive).
As is, this puts mesa pretty much on the wall: they are the bad guys if they decline the merge request (due to unclear future) and they risk problems with (code and other contributing members) in the future if the accept it.

I know this is a bit pointy but beloved Nvidia (I run a number of your titan cards) please get your Linux desktop act together.

libgbm used to have loadable backend support. It was rudimentary and the dri backend ended up as the only one, but there are still traces of that support in the code. If this isn't accepted into mesa, the simple alternative is to build a libgbm wrapper library that opens one or more full libgbm implementations. That would fall in line with libglvnd anyway.

[microcode]

Would it kill them to just publish a normal GBM impl? NVIDIA keeps saying they maintain their driver like this so that they can do stuff like the driver lockouts intended to cripple etherium mining, but they can't even succeed at that, so why are they still so desperate? AMD has high quality open source drivers, intel often has them for a given product at least by a couple years after launch, I doubt there's such special sauce in NVIDIA's drivers that they're really winning because of them (and honestly with the RadeonSI/RADV advantage, AMD's top-line products beat NVIDIA's more often on Linux than on any other platform).

[cl333r]

EGLStreams does not suite well for whole desktop environments. It needs lots of hacks to get EGLStream based Desktop Environments to run well.

Do you happen to know what hacks?

GBM is a 10 times better solution for Desktop Environments and a environment in which many clients live.

Because the DEs didn't implement EGLStreams or because GBM has features not found in EGLStreams?

[Grim85]

This seems to me a reaction because the writing is on the wall now over xorg, with no one taking over release management of the beast, its only a matter of time until their corporate Linux users are asking why they cant use nvidia on RHEL etc.

Their hand has been forced and now they must get their ducks in a row

[kpedersen]

I remember the huge amount of slating open source devs got on this forum for not understanding nVidia or bending backwards to their will.

Though I doubt there will be much instrospection.

Back in the dark days, NVIDIA were actually the good guys for providing *any* driver. The ancient AMD/ATI fglrx driver was of a very poor quality. The livna repo just about got it limping along.

I am glad times have changed though but NVIDIA lost a step. They are still fairly old fashioned in terms of closed-source. Particularly for hardware, it makes little sense.

This along with the change in mid-2000's culture of "DirectX is the only solution for l33t game developers" has improved the future of open-source (and software in general).

We just need to get over this last hurdle of NVIDIA holding everyone and the industry back. I have many NVIDIA GPUs in storage and I am very much looking forward to using them all

[CommunityMember]

All the things Nvidia states about EGLStreams are true, its an Open Standard by Khronos, its good for performance, and its portable.

Arguably, EGLStreams could have been a contender, and perhaps even the chosen one, but others went with GBM, and the rest is history.