The AMD Radeon Graphics Driver Makes Up Roughly 10.5% Of The Linux Kernel

[GruenSein]

...

What I am getting at here is that if Linux/Linus made a decision that graphics drivers should be in userland there wouldn't even be all of these arguments and wasted time that "NVidia is a blob", there are plenty of userland applications that non GPL2 licenses and no one really complains.

...

Yes, it would mean putting the drivers into userland and maintaining a Kernel interface that speaks with userland graphics drivers. This has the added advantage of making the whole "NVidia is a blob" entirely a non issue.

There are two things that I am not sure you are aware of. Firstly, the article is concerned with the kernel driver portion. This is by no means the entire driver. It is the part that is concerned with actual hardware management like power profiles, fans, temperatures, clocks etc.
On top of this, there are various drivers (AMDVLK, RADV, RadeonSI, "AMDPRO") providing API support with all the required fixes for games and a lot of other functionality. As far as I understand bridgman's post, the line between these parts is not set in stone and up for discussion with display functionality apparently having moved into the kernel with the AMDGPU kernel driver.

Secondly, having a kernel interface which allows separate driver modules to provide the functionality currently provided by kernel drivers sounds good. However, I am not aware of any stable interface like this in the Linux kernel. This is the reason AMD's pro drivers only support professional and LTS Linux distros because they cannot provide a kernel module for every kernel iteration. From other discussions in this forum I have gathered that such a stable interface is deemed not viable at the moment. Perhaps people more involved with this can give you the reasons for this decision. This is why the kernel part of the driver lives in the kernel tree. This way, the effect any breakage or change within the kernel has on the kernel drivers can immediately be detected.

[chocolate]

While a lot of people like to throw shit at NVidia for the whole binary blob issue, if you step back and think about it you can make an argument that the whole issue is mainly the result of a technical decision rather than a political/licensing one.
...

Ah yes, the "I just learned from Wikipedia about this exciting thing called microkernels and their theoretical advantages that purists boasted about in the nineties; so, to my current knowledge, everything should be in userspace" post.

[mdedetrich]

You confuse the Kernel part that is doing all the hardware communication with the userland part of the driver we may call Mesa around here. Mesa is where all the complicated parts sit and it sits in the userland. This is not diffrent for the nvidia driver that brings a kernel part and a userland driver part. The same concept is also true for Windows btw.

I was obviously simplifying what I was saying, it is more complicated then that.

On a technical level btw, the NVidia driver ignores mesa (because it has its own implementation), it patches the Kernel headers to provide an extra interface and it provides an alternative OpenGL driver (iirc) which likely contains all of the game/application hotfixes I was talking about earlier.

A microkernel experiment that will fail like any of the other microkernel experiments out there. Turns out userland hardware drivers are a really stupid idea but we only know that since the 90s.

I wasn't stating Linux is turning into a microkernel, just making the point that the Kernel used to be a completely monolothic Kernel and it was slowly turning into a hybrid kernel where certain parts that used to be the kernel are now as modules/userland.

The same happened with Windows and the graphics driver in Windows now primarily sits in userland, I wouldn't call this approach a failure (if anything its working better than what Linux is doing)

Beside the fact that this is already the case for all mesa compatible drivers that sit in the kernel, they all share a interface connecting to this userland driver framework.

The point is that graphics drivers aren't just mesa anymore, this is an outdated way of viewing things.

There are two things that I am not sure you are aware of. Firstly, the article is concerned with the kernel driver portion. This is by no means the entire driver. It is the part that is concerned with actual hardware management like power profiles, fans, temperatures, clocks etc.
On top of this, there are various drivers (AMDVLK, RADV, RadeonSI, "AMDPRO") providing API support with all the required fixes for games and a lot of other functionality. As far as I understand bridgman's post, the line between these parts is not set in stone and up for discussion with display functionality apparently having moved into the kernel with the AMDGPU kernel driver.

Right, I was simplifying things but my core point still stands which is that there are technical arguments for having more of the graphics stack sitting in userland which is the case for Windows (and also Google's new Kernel to replace Linux)

Secondly, having a kernel interface which allows separate driver modules to provide the functionality currently provided by kernel drivers sounds good. However, I am not aware of any stable interface like this in the Linux kernel. This is the reason AMD's pro drivers only support professional and LTS Linux distros because they cannot provide a kernel module for every kernel iteration. From other discussions in this forum I have gathered that such a stable interface is deemed not viable at the moment. Perhaps people more involved with this can give you the reasons for this decision. This is why the kernel part of the driver lives in the kernel tree. This way, the effect any breakage or change within the kernel has on the kernel drivers can immediately be detected.

Yeah thats the point, btw I don't think the case of providing an interface is "not possible" but rather the fact that "we don't want to do it" (for "reasons"). Providing a stable Kernel interface isn't hard, its actually easier than having to maintain an entire graphics driver (at least in the strict definition of maintenance, either that or its just the developers at the companies working on their drivers in the source tree all of the time which begs the question of what we are really gaining in forcing them to put it into the tree.

I personally don't expect this stance to change but I am deliberately being contrarian here because this decision (which you can argue is largely technical) is creating quite a few issues and it can also be said its a relic of the past since all other monolthic kernels have moved away from this model (graphics drivers aren't as simple as the old VGA days). The other point I would like to make is that the same technical stance is not the best solution for everything, i.e. keeping drivers in the tree makes sense most of the time but there are cases (i.e. graphics drivers) where its not the optimal solution

[ed31337]

In the earlier days, X11 provided Linux with video drivers entirely in userspace. But it was a poor system. It caused problems with Linux console frame buffers and console switching, because who knows which process is in control of the video card registers or what needs correcting once getting back from some other process fiddling with the video card. Crashes were common back in those days. I remember always being afraid to CTRL-ALT-Fx when using X11 for fear of never being able to get back to my X11 desktop without causing the whole system to crash.

What we have today is far superior. The kernel manages control of the video card and provides arbitration between processes that want to fiddle with it. No more crashes, ever. It's great!

[Alexmitter]

I was obviously simplifying what I was saying, it is more complicated then that.

On a technical level btw, the NVidia driver ignores mesa (because it has its own implementation), it patches the Kernel headers to provide an extra interface and it provides an alternative OpenGL driver (iirc) which likely contains all of the game/application hotfixes I was talking about earlier.



I wasn't stating Linux is turning into a microkernel, just making the point that the Kernel used to be a completely monolothic Kernel and it was slowly turning into a hybrid kernel where certain parts that used to be the kernel are now as modules/userland.

The same happened with Windows and the graphics driver in Windows now primarily sits in userland, I wouldn't call this approach a failure (if anything its working better than what Linux is doing)



The point is that graphics drivers aren't just mesa anymore, this is an outdated way of viewing things.




Right, I was simplifying things but my core point still stands which is that there are technical arguments for having more of the graphics stack sitting in userland which is the case for Windows (and also Google's new Kernel to replace Linux)



Yeah thats the point, btw I don't think the case of providing an interface is "not possible" but rather the fact that "we don't want to do it" (for "reasons"). Providing a stable Kernel interface isn't hard, its actually easier than having to maintain an entire graphics driver (at least in the strict definition of maintenance, either that or its just the developers at the companies working on their drivers in the source tree all of the time which begs the question of what we are really gaining in forcing them to put it into the tree.

I personally don't expect this stance to change but I am deliberately being contrarian here because this decision (which you can argue is largely technical) is creating quite a few issues and it can also be said its a relic of the past since all other monolthic kernels have moved away from this model (graphics drivers aren't as simple as the old VGA days). The other point I would like to make is that the same technical stance is not the best solution for everything, i.e. keeping drivers in the tree makes sense most of the time but there are cases (i.e. graphics drivers) where its not the optimal solution

Lets get some things straight as I think you have no clue what you are talking about.
Kernel Driver - Deals with talking to the hardware, providing a common interface to a userland driver.
Mesa - A suit of userland drivers for various grapics hardware, the actual graphics driver implementation providing OpenGL, GLES, Vulkan, Gallium, glx etc.
Nvidia Binary Driver - Package containing two things, a kernel driver similar to amdgpu and a userland driver similar to mesa.
Windows Drivers - Again a kernel side driver running in Ring 0 dealing with the hardware and a userland driver providing OpenGL, GLES, Vulkan, DX9-12 etc. The userland part can crash and recover, the kernel part would cause a kernel panic.
AMDGPU is large - Most of it are auto generated header files containing the registers, nothing to worry about.

All the heavy lifting is done in usermode on linux by the usermode driver.

[Slartifartblast]

What I am getting at here is that if Linux/Linus made a decision that graphics drivers should be in userland there wouldn't even be all of these arguments and wasted time that "NVidia .

Re-light blue touchpaper and stand well back for the next round of the Tanenbaum–Torvalds debate.

[mdedetrich]

Lets get some things straight as I think you have no clue what you are talking about.

Nothing you have said is contrary to what I said, also

Windows Drivers - Again a kernel side driver running in Ring 0 dealing with the hardware and a userland driver providing OpenGL, GLES, Vulkan, DX9-12 etc. The userland part can crash and recover, the kernel part would cause a kernel panic.

Not sure what your definition of a "kernel side driver" is, but for Windows the kernel side of WDDM is the bare minimum required to have the graphics driver running in userland (this was the major change from XP to Vista).

So yes theoretically the "kernel" part of the Windows WDDM can crash but in practice it never happens. There is actually a good presentation here https://www.blackhat.com/docs/us-14/...ck-Surface.pdf from someone who was trying to find security vulnerabilities in WDDM that goes into detail on how it works (tl;dr, the userland driver almost has complete control of whats going on).

You are missing the general point though, which is that Windows design (aside from the whole GPL licensing debate) is generally working better. Much more control is given to AMD/Nvidia on how they do their driver development and for the vast majority of cases any crashes that happen almost always occur in userland which just means the driver is restarted. This is also the same reason why in Windows you can upgrade your graphics card driver without having to restart your computer for the effects to apply.

In the earlier days, X11 provided Linux with video drivers entirely in userspace. But it was a poor system. It caused problems with Linux console frame buffers and console switching, because who knows which process is in control of the video card registers or what needs correcting once getting back from some other process fiddling with the video card. Crashes were common back in those days. I remember always being afraid to CTRL-ALT-Fx when using X11 for fear of never being able to get back to my X11 desktop without causing the whole system to crash.

What we have today is far superior. The kernel manages control of the video card and provides arbitration between processes that want to fiddle with it. No more crashes, ever. It's great!

These problems were less to do with the driver being in userland and more with the design of X11. Putting the drivers in userland actually makes the OS more stable (see Windows and previous comments) but of course this also depends on how the Kernel interfaces with the userland driver.

X11 is an old and outdated implementation of this, hence why people are trying to get rid of it.

[khnazile]

the vast majority of cases any crashes that happen almost always occur in userland which just means the driver is restarted.

AFAIK, we don't have problems with restarting the driver in linux, the real pain is that userland is not prepared for the driver crash. Stuff like display servers and graphics toolkits should be aware of a possibility of a driver crash to be able to recover from it, but nobody seems to bother with it. On windows you have only one display server/graphics toolkit: GDI, controlled by Microsoft, that takes care of everything.

[Alexmitter]

Not sure what your definition of a "kernel side driver" is, but for Windows the kernel side of WDDM is the bare minimum required to have the graphics driver running in userland (this was the major change from XP to Vista).

Yes, and the same applies to the graphic drivers in the Linux kernel. They are the bare minimum to make it possible for a userland driver to display something. Again, most of the code is autogenerated headers you usually would find as a binary on the windows driver. AMDGPU as a .ko binary is tiny 1.6MB(10.5MB unpacked), also as a fun fact Mesa is around 50mb.

So yes theoretically the "kernel" part of the Windows WDDM can crash but in practice it never happens.

I have a notebook here that would like to heavily doubt that.

You are missing the general point though, which is that Windows design (aside from the whole GPL licensing debate) is generally working better.

LOL My notebook also highly doubt that.

Much more control is given to AMD/Nvidia on how they do their driver development

No one says you have to use Mesa, you can still use AMDs own AMDGPU-Pro binary userland driver. AMD is in full control of how they wanna make this driver though it isnt faster or brings any benefit over Mesa beside OpenCL.

and for the vast majority of cases any crashes that happen almost always occur in userland which just means the driver is restarted.

The same applies to Linux grapic drivers, both AMDGPU/Mesa as well as Nvidia Kernel/Userland blob.

This is also the same reason why in Windows you can upgrade your graphics card driver without having to restart your computer for the effects to apply.

You can also update mesa while your system is running. The reason why you can update the kernel side driver on windows while the system is running is because it is a Hybrid Kernel, like a Microkernel but instead of the drivers running as Userland processes they run as processes in Ring 0 beside the NT kernel. Technically you can also update the AMDGPU kernel driver, but that hot update is nothing you should do on Windows or Linux what does not mean that Microsoft would not allow it anyways.

These problems were less to do with the driver being in userland and more with the design of X11. Putting the drivers in userland actually makes the OS more stable (see Windows and previous comments) but of course this also depends on how the Kernel interfaces with the userland driver.

Originally, Xorg drivers were in the userland and part of Xorg, thats why it was needed to run Xorg as root. But that was slow, highly unstable and a horrible idea overall.

[mdedetrich]

Yes, and the same applies to the graphic drivers in the Linux kernel. They are the bare minimum to make it possible for a userland driver to display something. Again, most of the code is autogenerated headers you usually would find as a binary on the windows driver. AMDGPU as a .ko binary is tiny 1.6MB(10.5MB unpacked), also as a fun fact Mesa is around 50mb.

No one says you have to use Mesa, you can still use AMDs own AMDGPU-Pro binary userland driver. AMD is in full control of how they wanna make this driver though it isnt faster or brings any benefit over Mesa beside OpenCL.

The same applies to Linux grapic drivers, both AMDGPU/Mesa as well as Nvidia Kernel/Userland blob.

Which is the same reason why the NVidia driver has to patch the kernel in order for the blob to work http://download.nvidia.com/XFree86/L...alldriver.html ?

Ontop of this (and at least when talking about GBM in Linux), due to its design NVidia is unable to use it with their blob otherwise they would suffer a sever performance hit due to the design of their driver (this is why they were pushing EGLStream's because its a very generic asynchronous interface that doesn't make many assumptions on how the driver is meant to behave).

I think you are being disingenuous when describing how the Linux stack works.

I have a notebook here that would like to heavily doubt that.


LOL My notebook also highly doubt that.

I have had ~10 devices in the past half of which are notebooks, all running dual boot with Windows/Linux (use Windows for gaming/CUDA and for other reasons) and I haven't had a single Kernel panic since Vista days. When Vista came out graphics drivers were unstable and caused the driver to crash, but often this just bringed you to the desktop.

This is taking into account graphics cards that are released with severe problems (i.e. NVidia 3x series + vega which take ridiculous power causing the GPU to crash due to lack of power). The only exception I can think of is if there is a problem with cheap/underprovisioned PSU's where it ends up not supplying enough power to your motherboard because it can't handle both the GPU and the rest of the systems power draw, in which case yes your entire system would crash because its not getting enough power (and there isn't much you can do here).

Curiously what laptop do you have?

You can also update mesa while your system is running. The reason why you can update the kernel side driver on windows while the system is running is because it is a Hybrid Kernel, like a Microkernel but instead of the drivers running as Userland processes they run as processes in Ring 0 beside the NT kernel. Technically you can also update the AMDGPU kernel driver, but that hot update is nothing you should do on Windows or Linux what does not mean that Microsoft would not allow it anyways.

Yes I mentioned this before, Windows used to be mainly a monolothic kernel and it turned into a Hybrid Kernel over the time (the graphics stack an area that has moved to more of a microkernal approach).

Also I wasn't necessarily talking about the graphics driver updating without having to restart, I was talking about the the new graphics driver applying immediately after you update without having to restart. Most linux distros support you updating the graphics driver without restarting but in order for the changes of the new graphics driver (or kernel) to apply you need to restart the computer.

Originally, Xorg drivers were in the userland and part of Xorg, thats why it was needed to run Xorg as root. But that was slow, highly unstable and a horrible idea overall.

Yes and no, its more complicated then that. Running (most of) the graphics driver in userland in of itself is not what makes the graphics stack slow.