Announcement

Collapse
No announcement yet.

There's Hope For DMA-BUF With Non-GPL Drivers

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

  • #31
    Originally posted by Sonadow View Post
    Because

    - Binary drivers break stuff? (you don't need to be a Linux power user to see how AMD's and NVIDIA's binary driver cause a whole load of problems and replace parts of the standard graphics stack with their own proprietary bits)
    - Binary drivers always break every time a kernel patch is pushed out by a distro? (eg: kernel patch from 2.6.27-20 to 2.6.27-30; this driver breakage 100% guranteed to happen)
    - Open drivers mean that what is not supported officially by NVIDIA / AMD can be done so by the community? Remember that we had no chance with Optimus switchable graphics technology until only recently with the open Bumblebee project
    - Installing binary drivers sets a tainted flag on the kernel, so your bug reports to the kernel guys become thrown down to lowest priority (if at all)?
    1) That's true... they do on occasion break stuff. But in my experience OSS isn't above this problem either. And often times bugs are filed and never resolved... ever. Just look at GNOME to see how imperfect the situation can be. Though, yes, to get in the kernel requires a much higher standard than user space stuff like GNOME. But, just as an anecdote, so far I've only had one driver that hard crashed my system, and that's the kernel Realtek NIC driver, which hard crashes the system so consistently that I had to go to Realtek's site and compile their own driver. My only point here is that OSS is just as much a victim of buggy code than proprietary stuff that's sold on the market.

    2) Okay, now that would piss me off. I've been very fortunate that every time Ubuntu has pushed out a kernel update I have never had any glitches from the process. That could be just because the kernel patches weren't dramatic enough to break something.

    3) That is definitely a major advantage... and I can see why NVIDIA and AMD would like to keep their drivers closed if they can cut off certain functionality based on GPU model (GeForce vs. Quadro, e.g.).

    4) meh. Some of that is kinda petty though. If I have a kernel panic that can clearly be traced back to the NIC driver, are they going to ignore a bug report just because I have VirtualBox or the nvidia driver installed? That doesn't instill a lot of confidence in me.


    Originally posted by quintesse View Post
    One word: control. If you don't have the source available under an open/free license you're completely at the mercy of your provider. Sure, NVidia has a nice track-record of supporting all their latest and quite a bit of their older gfx card. Good for them, but what happens if they go out of business tomorrow, or just decide Linux is not worth it anymore? Or, as they have done, that older gfx cards are not worth the trouble maintaining?
    Yeah, if nvidia evaporated tomorrow that would definitely fall into the suck category. It's a small risk though, all things considered. I purchased a video card with a particular driver and even if they went under I would still have at least the functionality that they guaranteed me. I'm not saying it would be pleasant, but there are alternative options, and it seems like such a small likelihood as to not be too concerning. (AMD, on the other hand... I don't know about them lasting much longer quite frankly.)

    Then look at all the people on this forum -- especially some of the most vocal OSS proponents -- who are so eager to throw all the old hardware / software "cruft" over the boat at the first chance. I mean damn... the news about KWin dropping support for *current* AMD hardware using Catalyst was met with rounds of applause. "It's time to move on!"

    I mean... you can still get drivers that work for the GeForce 3 or whatever... you just won't be able to run them in the latest Ubuntu or the like. But I see that as trying to fit a carburetor on an EFI engine. You have to kinda keep the components matched up.

    there are some important things that the NVidia driver does not support like KMS. Which comes back to not having any control: NVidia just refuses to support this all-important new development in the Linux kernel.
    My understanding is that most of the KMS functionality is "there" but they implemented it in their own way... sans the snazzy framebuffer support, which they said they could add that in if they wanted to, but it's at the bottom of the list of things to do. I thought supporting KMS was more of a legal problem than a pure obstinacy?

    Comment


    • #32
      Originally posted by johnc View Post
      Then look at all the people on this forum -- especially some of the most vocal OSS proponents -- who are so eager to throw all the old hardware / software "cruft" over the boat at the first chance. I mean damn... the news about KWin dropping support for *current* AMD hardware using Catalyst was met with rounds of applause. "It's time to move on!"
      It's not like you couldn't use KWin anymore, you just wouldn't get wobbly windows and blur. In fact, you could still run the XRender compositing backend to get some effects. Also, by the time this change could come out (10 months minimum) fglrx could fix it's Direct Rendering + TFP problem. I assume they will do this sooner or later to get Gnome Shell working, the only question is how long it takes them.

      Comment


      • #33
        Originally posted by robclark View Post
        The current situation on all the major ARM platforms (TI/OMAP included) is GPL kernel driver for GPU and closed userspace. So you could argue, "well, GPL kernel module, so you're ok to use EXPORT_SYMBOL_GPL()". But morally, because in the world of GPU the userspace and kernel parts are tighly coupled, that seems to me like following the letter of the law without following the spirit... so I don't think you can really argue that this situation is any better than with nvidia on the desktop.

        I'm optimistic that the situation of opensrc userspace stack improves on ARM, but it won't happen overnight. Nothing would make me happier than to be able to work on a fully opensrc graphics stack. (Please feel free to petition IMG on that topic ;-)... given the permission, I'd quite happily hack on an opensrc sgx driver on weekends and evenings.) But even when you reach the first (long) milestone of a fully functioning opensrc userspace, it will still take a long time to reach the performances levels of the proprietary driver, and when it comes to handsets/tablets, performance is everything.. so even on mali it will be the closed src driver that is shipping on devices from the factory.

        Furthermore, we do really want for nvidia to use dma-buf instead of inventing their own proprietary mechanism which wouldn't interop with the opensrc drivers. Currently the choice seems to be between those two options. One of the main purposes of dma-buf is to have a common solution to replace non-upstream vendor specific solutions for buffer sharing, and not opening up the dma-buf interface prevents that. The fact that dma-buf is mostly an interface, rather than an implementation, plus the fact that we want to get rid of vendor specific buffer sharing solutions with a common upstream mechanism, leads me to the conclusion that using EXPORT_SYMBOL() is the best choice.
        HI rob, nice to see Texas Instruments come to talk to the lowly end users and independent phoronix devs as the only real viable linux message board to get some reasonably up to date linux ARM info and performance specs in one place so far...

        you probably already know about the mali/Lima open stack development http://www.phoronix.com/scan.php?pag...tem&px=MTA1NjI so that would be our preference gfx kit to buy rather than IMG if you were to pick a base ARM Gfx soc to hack on in the coming months; to help it progress as fast as possible, there's no sign or real hope that IMG or an independent dev will bother to reverse engineer any of their Gfx blocks, as it stands mali/Lima seems the right choice this year.

        i forget, do Texas Instruments have any Mali 400 + SOC block in this years existing SOC refreshes ( we have to wait for
        Mobile World Congress next week to know for sure i guess) to give you and all the other professional TI devs some incentive to hack lima or even help get ARM directly involved in writing and submitting GIT code patches, giving info and helping this lima initative to make the first ever fully functional open ARM driver this year, OC if all the Linaro devs with mali kit releases were to help out lima too that would be even better

        anyway thanks for posting and dont be a stranger, invite all your other devs to come and contribute and correct any info contributors might get slightly wrong now and then here, and remember to have fun
        Last edited by popper; 22 February 2012, 03:01 AM.

        Comment


        • #34
          Originally posted by johnc View Post
          and it seems like such a small likelihood as to not be too concerning. (AMD, on the other hand... I don't know about them lasting much longer quite frankly.)
          Wouldn't you have said the same about AMD only a couple of years ago? Things change and sometimes very rapidly. And like I said it's not always about going under or disappearing, they could just decide tomorrow they have had enough of supporting Linux. Then what?

          Originally posted by johnc View Post
          Then look at all the people on this forum -- especially some of the most vocal OSS proponents -- who are so eager to throw all the old hardware / software "cruft" over the boat at the first chance. I mean damn... the news about KWin dropping support for *current* AMD hardware using Catalyst was met with rounds of applause. "It's time to move on!"
          Well maybe they were all in favor of KWin dropping support for a proprietary driver
          Still, for any starry-eyed youngster that spends his monthly earnings on the latest Gfx card and gushing about it on the forums are a dozen moms and dads with kids to take care of who are silently happy that their stuff keeps working as long as it ain't broke.

          Originally posted by johnc View Post
          I mean... you can still get drivers that work for the GeForce 3 or whatever... you just won't be able to run them in the latest Ubuntu or the like.
          If open source GeForce 3 drivers are available they would be part of Ubuntu and you wouldn't have to do anything to just have it work. It's exactly the closed NVidia drivers that have stopped working.

          Originally posted by johnc View Post
          My understanding is that most of the KMS functionality is "there" but they implemented it in their own way... sans the snazzy framebuffer support, which they said they could add that in if they wanted to, but it's at the bottom of the list of things to do. I thought supporting KMS was more of a legal problem than a pure obstinacy?
          It's missing quite a number of things like frame buffer support, seamless VT switching, allowing kernel oops display in X etc

          Comment


          • #35
            Originally posted by popper View Post
            HI rob, nice to see Texas Instruments come to talk to the lowly end users and independent phoronix devs as the only real viable linux message board to get some reasonably up to date linux ARM info and performance specs in one place so far...

            you probably already know about the mali/Lima open stack development http://www.phoronix.com/scan.php?pag...tem&px=MTA1NjI so that would be our preference gfx kit to buy rather than IMG if you were to pick a base ARM Gfx soc to hack on in the coming months; to help it progress as fast as possible, there's no sign or real hope that IMG or an independent dev will bother to reverse engineer any of their Gfx blocks, as it stands mali/Lima seems the right choice this year.

            i forget, do Texas Instruments have any Mali 400 + SOC block in this years existing SOC refreshes ( we have to wait for
            Mobile World Congress next week to know for sure i guess) to give you and all the other professional TI devs some incentive to hack lima or even help get ARM directly involved in writing and submitting GIT code patches, giving info and helping this lima initative to make the first ever fully functional open ARM driver this year, OC if all the Linaro devs with mali kit releases were to help out lima too that would be even better

            anyway thanks for posting and dont be a stranger, invite all your other devs to come and contribute and correct any info contributors might get slightly wrong now and then here, and remember to have fun
            yup, I am aware of lima project. Note that arm mali developers (and I *ass*ume this applies to developers working for different SoC vendors who use mali) are not permitted to look at the opensrc code. I would guess the situation is the same within, for example, AMD where they have separate teams working on opensrc and closedsrc driver stacks. You do need to be careful to prevent IP contamination in either direction.

            I'm quite sure I'm not allowed to comment on future TI products which haven't been announced yet ;-), but I think the GPU that is in omap54xx is already announced. It isn't quite like the desktop PC world where you can just pull on gfx card out and plug a different one in. In general, though, IMG cores are still very good for a given power budget.. which is basically why they exist. (I can assure you that it isn't because of how plesent their code is to deal with or their fondness for the opensrc community.) But maybe the lima project will start to put some renewed pressure on IMG.

            Anyways, standard disclaimers about how all of this is just one hackers opinions, etc, etc.

            Comment


            • #36
              Originally posted by robclark View Post
              I'm quite sure I'm not allowed to comment on future TI products which haven't been announced yet ;-), but I think the GPU that is in omap54xx is already announced. It isn't quite like the desktop PC world where you can just pull on gfx card out and plug a different one in.
              ....
              Anyways, standard disclaimers about how all of this is just one hackers opinions, etc, etc.

              yea ,the OMAP5 ARM Cortex-A15 processor [omap54??] running at “only” 800Mhz compared to a 1.3Ghz ARM Cortex-A9 Quad-core processor looks to have nice potential on the surface,for Trim-Slice type box etc



              i do wonder what official memory bandwidth and dual or single channel etc they are using there, as it is key to getting better overall data throughout today, any clue what that might be given TI have gone public with that SOC now, say hi to Charbax if your going to MWC this year and remember to collect up the data sheets and give him the full specs and speeds not just the PR stuff/fluff please LOL
              Last edited by popper; 22 February 2012, 08:25 PM.

              Comment


              • #37
                Originally posted by Qaridarium
                i vote to make the linux kernel ---> AGPLv3+
                You don't have a vote in this since you didn't even write a single line of kernel code. So there goes your daydream.

                And even if you had written kernel code, you'd need permission from everyone who ever wrote kernel code that is still included in the kernel, since Linux does not have a copyright assignment policy. That means, the kernel is stuck with GPLv2 forever. According to the kernel devs, this is not a bad thing though, since they're very hostile to Stallman and his Freeness crusade.

                Comment


                • #38
                  Originally posted by popper View Post
                  yea ,the OMAP5 ARM Cortex-A15 processor [omap54??] running at ?only? 800Mhz compared to a 1.3Ghz ARM Cortex-A9 Quad-core processor looks to have nice potential on the surface,for Trim-Slice type box etc



                  i do wonder what official memory bandwidth and dual or single channel etc they are using there, as it is key to getting better overall data throughout today, any clue what that might be given TI have gone public with that SOC now, say hi to Charbax if your going to MWC this year and remember to collect up the data sheets and give him the full specs and speeds not just the PR stuff/fluff please LOL
                  I won't be at MWC (/me just a hacker) but the OMAP5432 variant w/ dual-channel DDR3 is probably well suited to a trim-slice type box. There is also OMAP5430 which supports dual-channel LPDDR2 (IIRC) if PCB space is at a premium, but normal DDR is cheaper and something the size of trim-slice has plenty of PCB area compared to a phone. Both variants have SATA.

                  BR,
                  -R

                  Comment


                  • #39
                    Originally posted by RealNC View Post
                    You don't have a vote in this since you didn't even write a single line of kernel code. So there goes your daydream.

                    And even if you had written kernel code, you'd need permission from everyone who ever wrote kernel code that is still included in the kernel, since Linux does not have a copyright assignment policy. That means, the kernel is stuck with GPLv2 forever. According to the kernel devs, this is not a bad thing though, since they're very hostile to Stallman and his Freeness crusade.
                    I'm with Linus and his guys here.

                    Free is an ideal, and pragmatism takes precedence over idealism any time. The Linux kernel is probably the best example of how free and proprietary can come together to create a decent experience, since it plays nice with both free and non-free kmods / drivers / software.

                    If RMS had his way Linux would have been just another Hurd today.

                    That said, is there a source for your claim that Linus and the kernel devs are very hostile to RMS's mindless 'Freedom' preaches? A link, perhaps?I would love to read the discussion that took place.
                    Last edited by Sonadow; 23 February 2012, 01:16 AM.

                    Comment


                    • #40
                      Originally posted by Sonadow View Post
                      That said, is there a source for your claim that Linus and the kernel devs are very hostile to RMS's mindless 'Freedom' preaches? A link, perhaps? I would love to read the discussion that took place.
                      Yep, and it's lots of fun :-)



                      Quote from Linus Torvalds:

                      Well, you do have to realize that Linux has never been an FSF project, and
                      in fact has never even been a "Free Software" project.

                      The whole "Open Source" renaming was done largely _exactly_ because people
                      wanted to distance themselves from the FSF. The fact that the FSF and it's
                      followers refused to accept the name "Open Source", and continued to call
                      Linux "Free Software" is not _our_ fault.
                      This for the people who still claim that Linux is about "Free software". It freakin' isn't. It never was. And it never will be. Get over it. If you can't, go install GNU Hurd or something.

                      Comment

                      Working...
                      X