Announcement

Collapse
No announcement yet.

Proposals To Split KMS & GPU Drivers, 2D Kernel API

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

  • Proposals To Split KMS & GPU Drivers, 2D Kernel API

    Phoronix: Proposals To Split KMS & GPU Drivers, 2D Kernel API

    Following a "Kernel Display and Video API Consolidation" mini-summit held at the Emebedded Linux Conference (ELC 2012) last week, Linaro and other mobile/embedded Linux stakeholders have come up with several graphics-related action items for the Linux kernel. One of the proposals is to split KMS and GPU drivers in the kernel...

    http://www.phoronix.com/vr.php?view=MTA2MDM

  • #2
    Would this also allow to implement KMS in closed source drivers?

    Anyway, I always wondered how it could be "impossible" to implement KMS in the proprietary drivers. Maybe someone can help me with that.

    Shouldn't it always be possible to implement KMS as a thin wrapper around a closed-source shared library? Why should it be impossible to implement this in closed source drivers? I really can't imagine a way how this is possible...
    (Note: I have never looked at KMS code or something like that. I tried to, but diddn't understand to much of it, as I'm not a driver developer).

    Comment


    • #3
      Originally posted by b3nn0 View Post
      Would this also allow to implement KMS in closed source drivers?

      Anyway, I always wondered how it could be "impossible" to implement KMS in the proprietary drivers. Maybe someone can help me with that.

      Shouldn't it always be possible to implement KMS as a thin wrapper around a closed-source shared library? Why should it be impossible to implement this in closed source drivers? I really can't imagine a way how this is possible...
      (Note: I have never looked at KMS code or something like that. I tried to, but diddn't understand to much of it, as I'm not a driver developer).
      Closed source drivers SUCKS...

      Comment


      • #4
        Congratulations. You have been awarded with the Most Qualified Comment Award.
        I have to agree though, closed source drivers suck. But it's good if they work when you need them.

        Comment


        • #5
          Well, nouvou simply doesn't work for me.
          Can't set a resolution. Artifacts. Crashes. I had a hard time to even install the binary blob because nouveau permanently crashed.

          However, I just love KMS. So i think it would never be a loss to make it possible to be implemented in closed source drivers.

          Anyway... my question is still not answered.

          Comment


          • #6
            Originally posted by b3nn0 View Post
            Would this also allow to implement KMS in closed source drivers?

            Anyway, I always wondered how it could be "impossible" to implement KMS in the proprietary drivers. Maybe someone can help me with that.
            The last news that i read was that the internal APIs for this are GPL Only. And i dont believe that amd and nvidia want to reinvent the wheel.

            Comment


            • #7
              Originally posted by Nille View Post
              The last news that i read was that the internal APIs for this are GPL Only. And i dont believe that amd and nvidia want to reinvent the wheel.
              This should not be a problem at all.
              You could always define a thin GPL driver layer (i.e.: A wrapper around the binary blob) that relies on an external implementation.
              That the binary blob is the only actual implemenation of that wrapper-interface is written somewhere else...

              (To elaborate on that:
              NVidia/AMD could write a very thin KMS-enabled "driver" that does not actually drive the hardware but simply call in a (closed source) shared library that does the actual work.
              Than KMS-enabled pseudo-driver could of course be open source as it does not include any driver-internal secrets or something like that.
              And as I already said, there might of course be problem I do not see right now, as I have never looked at KMS code. I just wonder what those are. "impossible to implement" just seems a bit too far for me.)

              Comment


              • #8
                First of all, any driver code which runs on Linux *is* covered by the GNU GPL. There is no user land exception for drivers... See Alan Cox mail in the DRI dev mailing list archive, and the GNU GPL linux exception at the top of the kernel tree (the GNU GPL exception is granted only for "normal user programs" above syscalls, and drivers are *not*). Till no significant kernel holder of copyrights decides to sue in order to get the driver code, anybody is allowed to infringe the linux GNU GPL and keep their linux driver code closed.

                The current gfx stack is dual licensed: BSD/GPL (personal opinion-->that's why I do not code for it: it is not plain GNU GPL) that's how we will have a close source wince fork of the AMD GPU stack with the discret DMA engines and UVD decoder in order to make the linux driver look like a degraded wince driver (you can be *sure* that microsoft sailesforce *will* leverage this). See the phoronix announcement (that makes me sick). I met many industrials, they all dream of an apple world (=useless opensource core for an optimal close source OS), then going BSD is IMHO far too dangerous and defeat the purpose of getting an optimal 100% open source OS which will stay for good.

                Instead of convincing ARM to improve their close source driver, it would be better to convince them to release *all* hardware APIs and help the open source driver: LIMA (https://gitorious.org/lima, unfortunately not cleanly GNU GPL).

                GPU hotplug... is a sort of PCI hotplug (external PCIE). With the electrical modulation of displayport being the same than the one of PCIE, we can expect a simple standard PCIE interface set (something like MMIO regs) for display devices (= one driver for all, EDID in the PCIE ROM! )... well except for the GPU DMA engines which will send the display data to the display devices over the PCIE fabric. Thunderbolt *is* a step in the right direction (apple/intel are right on that hardware path).

                If the new EDID kernel parser could be protected with plain GNU GPL... thx!

                My 2c... totally personal!

                Comment


                • #9
                  Originally posted by sylware View Post
                  that's how we will have a close source wince fork of the AMD GPU stack with the discret DMA engines and UVD decoder in order to make the linux driver look like a degraded wince driver (you can be *sure* that microsoft sailesforce *will* leverage this). See the phoronix announcement (that makes me sick).
                  You might have misread the article and subsequent posts... plan was to release the WEC7 driver under the same X11 license used by the Linux version, and the MS-owned DDK bits under the same MS license *they* have today.

                  Comment


                  • #10
                    Split KMS and GPU Drivers

                    Very good idea regarding the very positive consequences of this.

                    And DMA-BUF V4L2
                    Common Video Mode Data Structure / EDID Parser
                    What not a buffer mechanism generalized as much as possible? Not just for video but able to do video?
                    It's all just passing data in a fast and flexible way.
                    With a general data structure model to describe hierarchy in data structures.
                    (video: 2D pixels 3 or four n bit components per pixel, new stuff t times per second.)
                    (picture: 2D pixels(samples) 3 or four n bit components per pixel, new stuff event based.)
                    (music: 1D samples, new stuff t times per second.)
                    ...

                    Comment


                    • #11
                      All these highly qualified comments everywhere..
                      Personally, open source drivers cause a lot more problems for me. Including crashes, low performance, loud fans, artifacts, etc...

                      I would love to see good open source drivers. But right now, they just can't compete to the proprietary drivers in a technical sense.

                      EDIT: asdx: I have reported bugs from time to time. But with my new GFX card, it's just impossible to do so. Even simple stuff like using "dmesg" results in crashes from time to time. I can't even gather information I could report (And well, according to http://nouveau.freedesktop.org/wiki/FeatureMatrix most of that stuff is not even supposed to work on the later fermi cards yet. So I guess the developers are aware of the problems. Having a new GTX 570, btw).
                      Refering to KMS and multihead mostly. Just for information: I was using Oibaf's PPA for the latest Mesa.
                      Last edited by b3nn0; 02-22-2012, 11:26 AM.

                      Comment


                      • #12
                        asdx: We posted at about the same time. See my EDIT: in the post above.

                        Comment


                        • #13
                          Originally posted by asdx
                          Indeed, I hope proprietary drivers break and they never appear again in Linux.

                          Same with flash, skype and all the other crap.
                          Yeah, I wouldn't want to be able to actually use the computer to get useful things done. It's more important to just use broken and worthless free software just so that you can say that you're using it.

                          Comment


                          • #14
                            Originally posted by b3nn0 View Post
                            Would this also allow to implement KMS in closed source drivers?

                            Anyway, I always wondered how it could be "impossible" to implement KMS in the proprietary drivers. Maybe someone can help me with that.

                            Shouldn't it always be possible to implement KMS as a thin wrapper around a closed-source shared library? Why should it be impossible to implement this in closed source drivers? I really can't imagine a way how this is possible...
                            (Note: I have never looked at KMS code or something like that. I tried to, but diddn't understand to much of it, as I'm not a driver developer).
                            AFAIK, KMS is Kernel ModeSetting. The video mode is set when the kernel first loads and runs. Hence the KMS driver has to be an actual part of the kernel, it cannot be a loadable module which the kernel only loads later.

                            Closed source drivers are bunary blobs which are wrapped in an open source wrapper and loaded after the kernel has started as a kernel loadable module. Too late for KMS.

                            The only way that one can have a KMS driver is to include it as a part of the kernel itself. Hence the module must be GPL licensed. Hence it canot be a closed source blob.

                            Comment


                            • #15
                              And why are on my System i have kms as Modules? And why i see the first output not with my nativ resolution and why he switch after loading the modules?

                              Comment

                              Working...
                              X