Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by mdedetrich View Post
    An argument can be made either way of whether graphics should sit in the Kernel or should sit in userland (doing the latter moves you slowly more towards a hybrid/micro kernel approach). This is purely a technical decision, with pros and cons either way and its appropriate to point out that over time for Windows the graphics driver has actually moved to userland for stability reasons (i.e. in Windows XP if your graphics card crashed it brought the whole system down, in Vista+ Windows can recover from such cases).

    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. The reason why I am bringing this up is that
    1. Graphics drivers are f'in complicated and large (in this case taking up 10.5% of the Kernel)
    2. Graphics drivers have many more software features and aren't really just "pure graphics drivers anymore". i.e. for DLSS (Deep Learning Super Sampling), the neural network models are stored in the driver (which for obvious competitive advantage reasons NVidia doesn't wan't to make open source). You also have things like NVidia voice (which uses AI cores on the graphics card to remove background noise and its better then any other solution I have seen). NVidia drivers also have a ginormous table of hotfixes for games that are programmed incorrectly in order to get them to run properly (cos game development sucks).
    In conclusion I think the whole premise of Linux forcing all drivers to be part of the Kernel may run into issues when we start dealing with non trivial hardware, in this case GPU's. GPU's are now ridiculously complicated, change very often and also the "software" part of the stack is becoming both larger and more important (and this is stuff that companies should never be forced to GPL). Having the GPU part of the Kernel also adds an extra barrier when it comes to updating drivers because now all changes have to approved by the Linux kernel team (vs the Linux kernel just having an interface and the driver being userspace which allows the companies to update the driver whenever they want).
    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.

    Originally posted by mdedetrich View Post
    This is also the main reason why Google is creating a new kernel for the phone to replace Linux called Zircon. One of the main features of the Zircon is that drivers sit in userspace, which fixes a big problem that exists currently with Android phones where its very difficult to update Linux versions on the phone separate from the drivers.
    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.

    Originally posted by mdedetrich View Post
    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.
    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.

    Comment


    • #22
      Originally posted by mdedetrich View Post
      ...

      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.

      Comment


      • #23
        Originally posted by mdedetrich View Post
        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.

        Comment


        • #24

          Originally posted by Alexmitter View Post
          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.

          Originally posted by Alexmitter View Post
          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)

          Originally posted by Alexmitter View Post
          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.


          Originally posted by GruenSein View Post

          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)

          Originally posted by GruenSein View Post
          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

          Comment


          • #25
            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!
            ed31337
            Senior Member
            Last edited by ed31337; 12 October 2020, 04:51 AM.

            Comment


            • #26
              Originally posted by mdedetrich View Post


              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.

              Comment


              • #27
                Originally posted by mdedetrich View Post

                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.

                Comment


                • #28
                  Originally posted by Alexmitter View Post


                  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

                  Originally posted by Alexmitter View Post
                  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.

                  Originally posted by ed31337 View Post
                  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.
                  mdedetrich
                  Senior Member
                  Last edited by mdedetrich; 12 October 2020, 05:35 AM.

                  Comment


                  • #29
                    Originally posted by mdedetrich View Post
                    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.

                    Comment


                    • #30
                      Originally posted by mdedetrich View Post
                      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.

                      Originally posted by mdedetrich View Post
                      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.

                      Originally posted by mdedetrich View Post
                      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.

                      Originally posted by mdedetrich View Post
                      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.

                      Originally posted by mdedetrich View Post
                      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.

                      Originally posted by mdedetrich View Post
                      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.

                      Originally posted by mdedetrich View Post
                      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.
                      Alexmitter
                      Senior Member
                      Last edited by Alexmitter; 12 October 2020, 07:00 AM.

                      Comment

                      Working...
                      X