Announcement

Collapse
No announcement yet.

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

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

  • #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; 22 February 2012, 12:26 PM.

    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


            • #16
              Originally posted by hal2k1 View Post
              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.
              Yes, but this opens the great possibility of companies like AMD and Nvidia modifying their binary blob driver to be only a GPU driver while using the same GPL KMS driver as the opensource drivers. This would be possible and desired because:
              • The KMS code could became more stable/mature, gainigng more users and developers
              • Companies would be able to keep their precious GPU code* closed, while sharing work with the community on the more basic mode setting code;


              * Companies have stated in the past that they wouldn't be able to opensource their drivers even if they wanted because they contain code/technologies liscenced from other companies and not belonging to themselves. That is one of the reasons AMD started a new driver from scratch when they decided they needed an open source driver a few years back.

              Comment


              • #17
                Originally posted by faustop View Post
                Companies have stated in the past that they wouldn't be able to opensource their drivers even if they wanted because they contain code/technologies liscenced from other companies and not belonging to themselves.
                This is the precise reason why we do NOT want to run binary blobs from AMD or Nvidia.

                Originally posted by faustop View Post
                That is one of the reasons AMD started a new driver from scratch when they decided they needed an open source driver a few years back.
                Nitpick: AMD did not start a new driver, they merely published programming specs. Here they are:



                The Radeon open source driver is code written from information (facts documented in the above programming spec) by community effort (including some input from AMD employees) and hosted at Xorg. This code belongs to the community, the community holds the copyright, not AMD. In this respect this open source driver is not like the Intel open source driver. The Intel open source driver is written by Intel, owned by Intel, the copyrights are held by Intel. The equivalent scenario is NOT the case for the Radeon open source driver, this driver does NOT belong to AMD/ATI.

                Hence, code/technologies liscenced from other companies have no impact at all on the Radeon open source driver.

                This is a very, very important point in the context outlined in the first statement from you quoted above.
                Last edited by hal2k1; 24 February 2012, 07:54 AM.

                Comment


                • #18
                  1: It crasehs before networking is even up
                  2: I already reported a bug and included as much information as possible including a demonstration video. Nobody in the freedesktop bugzilla seems to care however.

                  Comment


                  • #19
                    Originally posted by asdx
                    When you get a crash you should try to SSH into the affected machine and run dmesg, get all the logs you can and file a bug.

                    But make sure you have sshd in the affected machine.
                    Some people want to get work done and don't want to spend 45 minutes a day using two machines and SSH to debug someone else's broken code. The OS community has shown that it's unable to field a reasonable team of graphics driver developers, so now it's up to the users to do the work. That might fly among the hobbiests (I've done my share), but it's not really a good way to run a software project.

                    Comment


                    • #20
                      Originally posted by siride View Post
                      Some people want to get work done and don't want to spend 45 minutes a day using two machines and SSH to debug someone else's broken code. The OS community has shown that it's unable to field a reasonable team of graphics driver developers, so now it's up to the users to do the work. That might fly among the hobbiests (I've done my share), but it's not really a good way to run a software project.
                      sorry I missed the bit where you paid me for the software you feel so entitled to.

                      Dave.

                      Comment

                      Working...
                      X