NVIDIA Proposes Mesa Patches To Support Alternative GBM Back-Ends

[ezst036]

........for allowing alternative GBM (Generic Buffer Manager) back-ends to be loaded.......

Wait, what is so terrible about the current GBM backend(s?) that is currently available that nvidia is shutting it down and saying they dont want any part of it, it would be better to write a new one from the ground up?

Is this really a necessary function that cant exist in any way outside of their closed proprietary driver that it MUST be kept within the high secretive walls? Lest all sorts of nvidia patents and copyrights will come tumbling down? I highly doubt that is the case.

Yes, this is a step in the right direction, but how big of a step is it, really? Why couldn't nvidia just participate in the wider community instead? What are they so afraid of?

Additionally if this is an extra patch so that nvidia can pursue it's own exclusivity why is it up to our guys to maintain their code???????

it kind of looks to me like yes nvidia did cave and "fine, we will support GBM after all but were gonna have it both ways if we do". "We aren't participating AND you support our patches"

Seems to me to be really close to a double down on their part. Unless I missed something.

[ezst036]

i'm glad the wayland dev's didn't cave in to nvidia's desires.

This.

1000x this.

[You-]

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 not talking about that long ago. I hear that the nv driver was useable before they obfuscated it around 20 years ago.

But the EGL streams mess was more recent. Maybe 2015 - 2018 timeframe where nVidia was saying GBM wasnt good enough and the FLOSS developers were asking why. nVidia eventually said they would get back to them on that and then we had a year or so of silence before now adding another GBM backend.

[angrypie]

https://www.youtube.com/watch?v=iSwsJLfH0tQ

I prefer this one: https://www.youtube.com/watch?v=i2lhwb_OckQ

[qarium]

Yes please, bring GBM to your driver and make it more AMDGPU-PRO-like.

haha right ... Nvidia learned it the hard way.... for me it is very interesting to watch their learning path.

and i think they learn more and more... they do not really like to learn thats for sure.

more and more people switch to amd even for PRO user cases also the pro market has also changed

more and more people user Blender and do 3D graphics with openCL and so one . 10 years ago all the professional 3D graphic design was done by closed source software.

and i think this will improve even more. in the end of all the professional tools are opensource even stuff like "AMDGPU-PRO" will die... just because opensource tools works best with opensource drivers.

[shmerl]

I'd like to see solutions that work for Vulkan/WSI as well. Why all the focus on EGL only?

[oiaohm]

Do you happen to know what hacks?

Comes down to define of hacks.

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

The reality is both are true.
First problem number of parties implementing EGLStreams its a total of 1 being Nvidia.
GBM you have Intel. AMD... all inside mesa and 3 independent implementations of libgbm as well.

So why should I maintain a code path for solo vendor? KDE lead developer ask this question of Nvidia and said Nvidia could provide one of their own developers if they wanted KDE to have EGLStreams support. Not all wayland compositors out there have implemented EGLStream support and not all will.

Now of course the Nvidia developer with KDE have run into problems like KDE lead developer wants to be able to restart the compositor the way current EGLStreams does the buffer you restart the compositor all buffers the compositor allocated include ones it passed off to independent processes goes by by. GBM is a per process solution for buffer management so a process restarting does not result in the magical disappearing buffer for other processes.

The reality is wayland compositors most likely don't need any more features than GBM and DMA BUF offers.

Nvidia brings up that eglstreams is a Khronos standard there is a little catch here.

https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import.txt

DMA BUF is a registered extensions to EGL. GBM design logic has been include in EGL development from 2014 to now. Yes this is your opengl without a X11 server.

Something to be aware of is with AMD gpu all buffer/memory management is open source. Yes even if you are using a AMD pro driver. This allows the memory operations to be peer reviewed for security defects.

GBM is all about dealing with buffers.

Its really about time on Linux that Nvidia just pulled their head in and toes the line and provides the features the other vendors do. Lot of the complexity making a Wayland compositor will reduce when we have all vendors providing Kernel Mode Setting, GBM and DMA BUF support under Linux. Yes Nvidia does need to accept that sections of their drivers need to be open source for peer review. Memory management issues is one of the biggest causes of security flaws.

[ssokolow]

Nvidia brings up that eglstreams is a Khronos standard there is a little catch here.
https://www.khronos.org/registry/EGL...buf_import.txt

Also, the timeline went something like this:

1. GBM achieves de facto standardization among everyone except nVidia
2. nVidia pulls a Microsoft and, like with C# and OOXML, rushes to get EGLStreams standardized to make it look more important than it is in practice.
3. People backing GBM realize what tactic nVidia is taking and submit their own stuff for standardization.

[Schmellow]

How much do you want to bet it was following through on the decision to split out XWayland and abandon direct-on-hardware X.org that forced nVidia's hand on this?

Highly unlikely - if you look at the MR closely, you will see that first commits are 1 year old.
Correlation != causation.
Most likely this whole thing spent a year or so in legal review or awaiting some kind of management decision, and the rest is coincidence

[oiaohm]

Highly unlikely - if you look at the MR closely, you will see that first commits are 1 year old.
Correlation != causation.
Most likely this whole thing spent a year or so in legal review or awaiting some kind of management decision, and the rest is coincidence

When the fact X.org server on bare metal did not have a maintainer and Redhat had stated only interest in the Xwayland part 2 years ago. Possible writing was on the wall a year before the first commit. The Nvidia management may have been dragging feet on releasing this on the hope that someone would step forwards and save X11 on bare meta and this development was a back-up plan if things did not go that wayl.

The reality the XWayland split away from main x.org X11 server had been in under consideration for quite some time before it happened.

Yes it may only be Correlation without Nvidia internal messages we will never be able to prove causation. The timing of these thing happening causation is possible.

If it was over 3 years old then you could be absolutely sure the release now is just a Correlation thing for why it started development. Under 2 years old the writing was already on the wall about what was going to happen if no other third party stepped forwards.