Announcement

Collapse
No announcement yet.

Linux Developers Still Reject NVIDIA Using DMA-BUF

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

  • Originally posted by XorEaxEax View Post
    No actually you missed the point, I wrote that it doesn't matter if you get 110 fps with open source drivers or 190 with proprietary drivers when the game still only needs to run at 30-60fps. In other words, as long as the open drivers can provide 30-60fps (depending on game) with acceptable levels of graphics then that's all that's needed to cater for the wider audience. Obviously there will be the hardcore gamers who want everything at maximum but really they won't switch to Linux anyway, heck they are probably not even on PC anymore as they've migrated to dedicated gaming consoles.


    Of course it does, that is what adequate means. If it is adequate for playing a game at full speed with a adequate level of graphics then that is perfectly acceptable for the majority of people playing games out there. Again the hardcore gamers are not what I'm talking about here. A good gaming experience goes far beyond the ability to crank up the graphics to 'MAXIMUM LEVEL! OVER 9000!'. The runaway success of things like the Humble Bundle where the majority of games doesn't come close to taxing even the open source drivers is a prime example of this.


    If you want to use the proprietary driver because you don't find the performance to be adequate then that's up to you, who is stopping you? If you are talking about 'optimus' then that's because NVidia has not seen it fit to release a proprietary driver for this hardware on Linux, which is not something that not being able to use DMABUF prevents, they are fully capable of implementing that functionality in their proprietary driver themselves, as they've done with all other kernel functionality they can't use due to being proprietary. The reason you don't have a proprietary optimus driver for Linux is that NVidia doesn't care about supporting optimus on Linux.

    And this will ALWAYS be the case with a company like NVidia which only supports proprietary drivers, you will be at their begging, they will CHOOSE which platforms you can or cannot run the hardware you BUY from them. It doesn't end with optimus, this will always be a problem. FreeBSD allows proprietary drivers to interact directly with kernel interfaces, yet it does not have optimus support, what gives?

    Again it has nothing to do with that, if NVidia _wants_ to support a platform they will. They want to support Linux on the professional level for HPC and 3D/SFX so they provide proprietary drivers for their cards which are used in those areas, they have no interest in Linux on the end user desktop so technologies like optimus is not on their agenda.


    As someone who has been programming in C (amongst other languages though) for 12 years that makes me happy to hear If you want a nice kickstart/learn-through-practical-examples experience I would suggest 'learn c the hard way', I wish I'd had something like this back when I started out: http://c.learncodethehardway.org/book/

    As the name implies there is very little hand-holding and depending on how new you are to programming you might want something more 'basic'.


    Yes this is indeed a subjective thing, but I'd wager as long as people think graphics look 'good' they will (in general) fully enjoy the game even though it doesn't reach the maximum level of detail it can muster on their hardware/drivers.

    I'll say again the fps thing. If in cases where on other OS you'd get 100 fps or whatever, you get 30-60 on Linux, then in cases you'd get 30-60 on that other OS you'd get significantly less on Linux. Ok? Thus, I wouldn't say it's adequate. In many cases the performance of opensource drivers is good enough, but also in many other cases it's not. And those cases seem to be many more than the other OS that would get more fps or proprietary drivers. Am I wrong here?
    So if you have more cases where performance is not good enough, compared to what it could be, I'd call it not adequate.
    I'm sure you agree that performance on open drivers, on average, is not as good as it could. And in my opinion, not as good as it should. Although I do understand the technical difficulties, to consider them good for daily usage, I'd like better performance in relation to hardware.
    For me it's probably just power management that prevents me from using them. Video decode would be very welcome too. And in my usecase, granted the first condition was met(power management), the advantages would probably indeed outweigh the disadvantages. SO I have my hopes up regarding some news that there might be progress on this front ...
    And I wouldn't say we're at the point where in most cases I'd recommend open drivers instead of closed ones to people new to Linux. At least from my perspective, which I find fairly justified.

    Even though we might have disagreements, I'm glad we can talk without derailing too much, unlike in other cases.

    Indeed, FreeBSD may not have optimus, but I think they have more reasons to give this support on Linux. In the end, Nvidia is indeed a company, not a charity or anything ..
    While not pleasant, it's somewhat expected that they wouldn't care as much as for windows. Especially if they also don't have any OEMs complaining they can't get Optimus to work on their pre-installed Linux pcs ..
    It's not good, but expected due to how things work. I might be wrong, but I care more about it being implemented that how it will be. I believe for myself that it's more likely or better to implement, even if in wrong way, and then do it better. Also I believe accepting the blob and bashing nvidia would bring us one step closer to nvidia open drivers than wishing them and the blob to die. I don't think it will be easy to give us open drivers by forcing(I think it'd be to tough to do so), but maybe if they are more involved in Linux they that they can have advantages actually from open. But this is how I see things.
    Besides, even if it's implemented itcould help get more users, in other words more power to actually pressure them in the long run.
    I can accept though that there are legal problems, and maybe I should mention, that I don't expect or want them to implement it if it indeed is against gpl etc.
    I don't like the idea that "we'll prevent them cause we hate them" though.
    Making it easier for them would obviously help implement features though. But yes, we should stay within what gpl says. I don't say to revert anything, just that no need to prevent them IF it's in agreement to what they're allowed to do(cause I get the impression some people would prevent them anyways).
    Also I don't like that some people are so zealous about opensource, that they want to go against everything that's not open and generally deny it. I do believe that open is better, but we can't just erase everything else in a single fell swoop. And of course Nvidia aren't victims, I don't think anyone really said so, the victims are the users. And Nvidia is indeed at fault more or less, but I'd also blame some other people, who I believe could maybe have handled things a bit better in my opinion. Just a tiny little bit.
    We shouldn't see them, or anyone else for that matter, as enemies in my humble opinion.


    Btw, about Nvidia's support. I can't confirm much of this with benchmarks or anything so take with a grain of salt .. Or many ..
    I've read various articles, comments etc regarding graphics performance under Linux, among other things, and the general idea I got is that both nvidia and amd blobs tend to give around the same performance between Windows and Linux(native apps). But fglrx has more random bugs and features missing/not implemented that well(this I can confirm .. -.-). Under Wine though, amd performance is worse or horrible for games, personally I can confirm 70%-80% performance losses in fps on average on some games I tried. Pretty bad, huh? Although the games were playable, there was a bit of lag on Stacraft II sometimes(even on lowest settings it wasn't all gone). I should note that there was barely any decrease in performance under heavy battles(4v4 clashing with hundreds of troops from all sides, and I don't have a high end laptop ), while on Windows in the same circumstances the screen would probably update every 1-2 seconds(that was while I played, so I can confirm) .. And generally, less heat was produced(always a good thing on a laptop. With radeon I didn't try though to say, but from what I've read it occasionally performs better than Catalyst with Wine .. xD Still less than windows though.
    With Nvidia blob on the other hand(not confirmed by me from here on) it seems the performance under Wine often similar to Windows, even better on cases ..!
    Granted you can have working video decode acceleration, it seems to me close to the best you could have on Linux, as things stand now(not as good as it should again, some bugs here and there, and some other stuff).

    And I'd generally say, that their driver mostly works pretty well, from my experience too. Although I find both Nvidia's and AMD's installers pretty stupid. Ok, AMD needs a bit of command line(can't do much without amdconfig/aticonfig, the rest is all possible through only gui though, but generally faster on terminal), but Nvidia requires to completely shut down X and the display manager to install( manually) from what I remember from last time. xD
    Other than that it's not so bad for Nvidia though .. As far as support goes. With Catalyst I get various glitches, mostly on fullscreen hardware accelerated windows of any sort(wine games, browser with flash video, fullscreen flash video, even lightdm with elementary theme, and more, all give some kind of graphical glitches, making features unusable in some cases).

    I hope that the driver won't get too bloated if they add all the code for Optimus themselves though.


    And thanks a lot for the recommendation regarding C programming, I'll certainly have a look at it.
    I was learning a bit of gtk lately, but generally I'm not experienced on programming.

    **Dear God, how did I end up writing so much again .. -.-
    It must be those essay/language classes I had a couple years ago .... -.-

    Comment


    • IMO we're missing the point

      This is one of the few multi-page threads I read completely before responding, and I haven't sees once asked the following question : "who is the target audience of Linux?" I don't have the answer, I only have my answer, so all that follows is my personnal view.

      There is none. The point of Linux is creating a great product. When someone wants to use it for something, he is welcome to modify it as seen fit; with the GPL safety that those changes will go public. This has happened on more than once occasion, however Linux on servers/supercomputers comes first to mind. The changes went back to the main branch, and independent devs got interested and contributed too. Now we're seeing the same in the embedded space : DMA-BUF was created to address a specific need for ARM vendors. In the end it was designed more generically than was originally needed, and the enablement of dual graphic solutions is AFAIK more of a side effect. Thanks to the GPL (again) the work went back into the main branch.

      Now NVidia dances in, wants to hook in but oh surprise, it's an internal interface, and you can't link against it from non-GPL code. (Admittedly, this has never been tried in court, but who would want that?). Why is this? because when communicating with the kernel via system calls (exempted from the GPL derived work clause), the kernel can (and will) assure some type of security. With internal interfaces, this protection is irtually impossible. The best described case in the mailing list is a bug that appears somewhere, but traces back into the black box that is the blob, this creates impossible to debug issues, and for people hit by them, an impression that linux is unstable (and that no one is willing to look into their issues). In the end, they are making a decision which should be good for the product.

      To the users (of which I am a subset), well, sorry guys, the qualty of the product should be and is the primary concern; jeopardizing this for a vendor (granted popular) that doesn't play nice doesn't seem like a fair tradeoff.

      This was very personal analysis of the situation, and one more thing :

      I bought my GPU, and I want(should be able to) to use it how I want. Imagine you bought a dishwasher into which you weren't legally allowed to use Calgon tablets, only had to use Sun tablets. The notion of "owner" is slowly fading, all we are is a "licenced user". I say NO! I own it, I use it how I see fit.

      Third time repeated : my view only.

      Nvidia/fglrx blobs have no future in Linux.
      Agreed, the way things are becoming more tightly integrated, controlling them from dozens of different places (vendors) is unsustainable.

      Serafean

      Comment


      • Originally posted by Serafean View Post
        This is one of the few multi-page threads I read completely before responding, and I haven't sees once asked the following question : "who is the target audience of Linux?" I don't have the answer, I only have my answer, so all that follows is my personnal view.

        There is none. The point of Linux is creating a great product. When someone wants to use it for something, he is welcome to modify it as seen fit; with the GPL safety that those changes will go public. This has happened on more than once occasion, however Linux on servers/supercomputers comes first to mind. The changes went back to the main branch, and independent devs got interested and contributed too. Now we're seeing the same in the embedded space : DMA-BUF was created to address a specific need for ARM vendors. In the end it was designed more generically than was originally needed, and the enablement of dual graphic solutions is AFAIK more of a side effect. Thanks to the GPL (again) the work went back into the main branch.

        Now NVidia dances in, wants to hook in but oh surprise, it's an internal interface, and you can't link against it from non-GPL code. (Admittedly, this has never been tried in court, but who would want that?). Why is this? because when communicating with the kernel via system calls (exempted from the GPL derived work clause), the kernel can (and will) assure some type of security. With internal interfaces, this protection is irtually impossible. The best described case in the mailing list is a bug that appears somewhere, but traces back into the black box that is the blob, this creates impossible to debug issues, and for people hit by them, an impression that linux is unstable (and that no one is willing to look into their issues). In the end, they are making a decision which should be good for the product.

        To the users (of which I am a subset), well, sorry guys, the qualty of the product should be and is the primary concern; jeopardizing this for a vendor (granted popular) that doesn't play nice doesn't seem like a fair tradeoff.

        This was very personal analysis of the situation, and one more thing :

        I bought my GPU, and I want(should be able to) to use it how I want. Imagine you bought a dishwasher into which you weren't legally allowed to use Calgon tablets, only had to use Sun tablets. The notion of "owner" is slowly fading, all we are is a "licenced user". I say NO! I own it, I use it how I see fit.

        Third time repeated : my view only.

        Agreed, the way things are becoming more tightly integrated, controlling them from dozens of different places (vendors) is unsustainable.

        Serafean


        And i have to add my view, Linux will dominate in less than 2 years. If until the end of 2014, Linux is not the most used OS installed on all devices (including phones, tablets, googles), then I will not write again on any technology site.


        And I'm still waiting an answer from AMD!!!

        Comment


        • Originally posted by asdx
          Most people want to play games, not brag about how many FPS they can get.

          The same is true for people who want to watch movies, I don't care how many FPS I can get when watching a movie, I want to watch the god damn movie.

          Linux with open source graphics is more than adequate for 3D games, and performance will only keep getting better with time.

          Nvidia/fglrx blobs have no future in Linux.
          0_o
          Ok, so you saw the word fps and threw an answer before reading anything else?
          I'll write the same .. AGAIN, please read it now ..

          "If in cases where on other OS you'd get 100 fps or whatever, you get 30-60 on Linux, then in cases you'd get 30-60 on that other OS you'd get significantly less on Linux."

          Hope you understood this part. Besides, it's not like like mos cards would give you 100 fps on Windows, probably just 30-60 there too. And when you have hardware that can fly, are you fine with being adequate or barely making it? Can you say for sure you'll get the SAME framerate, which is not always over the top, often just normal or even less then the 30-60 on the open drivers? No. Not in most cases(maybe there are exceptions of course, but they're still exceptions, when they're the rule we'll talk again about it.)
          That's why they're looking for optimizations on compilation level and other things.

          You sure you don't care for your movie's fps? Seen what can happen when you get less than the video? Oh, I've seen. And can(or could) happen with blobs too. Wouldn't keep my fingers crossed you'll watch any movie with no hiccups. Btw, CPU seems to be important too for my laptop, don't wanna burn it.

          Yes, performance will keep getting better, but it's not that good now. Maybe if more people step up to help it can go faster.

          **Btw, I take it that with games you take such stuff into account: Crysis, Diablo III, The Elder Scrolls VI: Skyrim, GTA IV, etc etc etc ..
          Ya know, many people tend to like those ..
          And might not have an easy time getting them to 100 fps, under Windows/closed drivers on common system, so would you even get 30 on open ones? I they're good enough on performance let's forget about improving it for now and work on all those other areas that require work, but I doubt it's that way. And I speak as a person who doesn't need my maximum performance. But then again, if I paid for some well performing hardware, why want to get sub par performance?


          Btw, Linux most used OS in two years from now .. Too optimistic ... Wish you're right though!!

          Comment


          • Originally posted by Serafean View Post
            Now NVidia dances in, wants to hook in but oh surprise, it's an internal interface, and you can't link against it from non-GPL code. (Admittedly, this has never been tried in court, but who would want that?). Why is this? because when communicating with the kernel via system calls (exempted from the GPL derived work clause), the kernel can (and will) assure some type of security. With internal interfaces, this protection is irtually impossible. The best described case in the mailing list is a bug that appears somewhere, but traces back into the black box that is the blob, this creates impossible to debug issues, and for people hit by them, an impression that linux is unstable (and that no one is willing to look into their issues). In the end, they are making a decision which should be good for the product.
            Then you know what? You, as a user, can decide not to use said companies products anymore. On Windows, I get no end to the complains about Creative and their crap soundcard drivers, so I recommend everyone toward ASUS/Auzentech/HT Omega instead.

            On Linux, you instead get a crappier driver with features reduced. Then people get the impression Linux isn't as good as Windows, and avoid the OS. How is THAT good for Linux?

            Comment


            • Originally posted by RealNC View Post
              Why is it OK that I can run a GPL app on Windows, which links against Microsoft's C library
              You can run and distribute the app because MSFT's C lib license allows you to do so.
              but I can't have a proprietary driver making use of an interface of a GPL kernel?
              You can have an infinite number of such drivers. However, you can't distribute them because the kernel authors' license for the relevant interfaces does not allow you to do so.
              In my eyes, what the kernel devs are doing is plain bigotry. The kernel is a required component and you cannot work around it. If you're not allowing proprietary vendors to use it in order to be able to offer support and stay competitive in the licensing policy of their choice, then you're being a bigot.
              No; The licensing terms offered by parties A(1) through A(n) to party B do not get dictated by party B's subsequent business needs absent some prior contractual arrangement between A(1-n) and B.

              In more MBA-friendly terms: "Waaa my previous short-term, time-saving thus bonus-boosting decisions are now biting me in the ass" is not an argument for overriding copyright.

              Next time, consider deferred gratification and/or sound engineering principles such as "reinventing wheels is bad".
              If NVidia isn't allowed to interface with the kernel, then Google shouldn't be allowed either. Much of the Android stack is proprietary, yet no one sees a problem with the Linux kernel sitting at the center of it. And NVidia isn't actually even modifying the kernel, let alone distribute it. It's not like they have changed the kernel and refuse to GPL their changesets. The only thing they're trying to do is to use an interface.
              Depends, but probably false unless you can point to a GPL-marked kernel interface that Android uses. Go ahead, we'll wait.
              Hypocrites.
              Crybaby/troll.

              Comment


              • Originally posted by gamerk2 View Post
                Then you know what? You, as a user, can decide not to use said companies products anymore. On Windows, I get no end to the complains about Creative and their crap soundcard drivers, so I recommend everyone toward ASUS/Auzentech/HT Omega instead.

                On Linux, you instead get a crappier driver with features reduced. Then people get the impression Linux isn't as good as Windows, and avoid the OS. How is THAT good for Linux?
                You know what, I don't use said companies products... I try my best to put my money where my mouth is, and mostly succeed.
                Did you read/understand what I said in my post? I never said it was good for Linux's desktop market share, I said it was IMO the right decision to keep code quality, stability and security at a very high level (or at least to let everyone see the mistakes).
                You say yourself that you recommend another vendor if one doesn't meet your requirements; do you recommend AMD/Intel for everyone who wants to use linux (who really support linux and OSS)? Or do you recommend nvidia for its pseudo-support of linux (no OSS there)? If the second, then you only want a system free as in "free beer", and don't have a clue about what free as in "free speech" means (or you simply don't care).
                I'm not judging, all I'm saying is that I understand your point of view, but for me (and others) free as in "free speech" is more important, and I'd like you to understand that.

                Serafean

                Comment


                • Originally posted by artivision View Post
                  OK agent, I'm this close to $#@! you. The entire page of comments is irrelevant and wrong because are based to you comment that is also wrong. The reference implementation of OpenGL drivers IS OPEN. Anybody is welcome to look at the reference code (there is not actual code, just some precode = how it works + standards for binary compatibility), without the need to Open or Close anything. Its Nvidias fault and AMDs also: With HD5000 AMD it self said that they will try with HD8000 to have only Open drivers. Fuck both. If only i wasn't gamer!
                  Ok, if you are right, why AMD does not publish directly its Catalyst driver as open source? Why do not directly port the Windows/Mac drivers? Only because they are dorks?
                  Why Intel does not just make a direct porting of their Windows or Mac drivers? Why should they spend money paying programmers who are re-inventig something that Intel alredy has?
                  Why, in general, Mesa and not open-source OpenGL drivers?

                  You already told it : "there is not actual code, just some precode = how it works + standards for binary compatibility" --->THERE IS NOT THE REAL HOT STUFF. The probably PATENTED stuff...

                  Go and $#@! somebody else...

                  Comment


                  • ... More on OpenGL...

                    The public, open, part of OpenGL is how to use a driver that already exist. Not how to program an OpenGL drivere.
                    They give you documentation about how to display a cube with OpenGL, what OpenGL call you need, for example. They do not tell you how the OpenGL driver actually draws the cube for you, they do not tell you how the OpenGL call works inside. That is the problem. That is the reason behind the bugs and the sluggishness of open source dirvers...
                    Who programs the Mesa drivers is in the same position of the Wine programmers: they know what each library call is supposed to do, but not HOW the result is achieved in the original thing..

                    This is what I undestood...

                    Comment


                    • Originally posted by Gigetto96 View Post
                      Ok, if you are right, why AMD does not publish directly its Catalyst driver as open source? Why do not directly port the Windows/Mac drivers? Only because they are dorks?
                      Why Intel does not just make a direct porting of their Windows or Mac drivers? Why should they spend money paying programmers who are re-inventig something that Intel alredy has?
                      Why, in general, Mesa and not open-source OpenGL drivers?

                      You already told it : "there is not actual code, just some precode = how it works + standards for binary compatibility" --->THERE IS NOT THE REAL HOT STUFF. The probably PATENTED stuff...

                      Go and $#@! somebody else...
                      Get some information before you start spreading misinformation.
                      I won't comment on a reference opengl specification, as I have no knowledge in that area. I do know that some mandatory parts of openGL are covered by patents (namely s3tc and the floating point extension). These two extensions are implemented for mesa, but not merged in master.

                      Binary graphic drivers contain a lot more than just the openGL specification. One thing that comes to mind is video decoding. These are patented technologies, and most likely not even completely designed internally -> meaning they licensed it from a third party. This is where the shitstorm is brewing, and why the blobs won't be opensourced. Another reason is paranoid guarding of some magic. But that's a non-reason.
                      Porting a driver to another platform is almost a complete rewrite (if you don't have the infrastructure ready beforehand) -> this is why Intel doesn't port, and why nvidia and AMD do (their drivers have a shared core). Plus nothing guarantees that Intel already has an opengl implementation, they surely have a DX implementation, maybe opengl runs on top of it... (this is only speculation)

                      Bottom line is :
                      - opensourcing blobs is not possible due to everything they ship (do you really think that an OpenGL implementation could be > 100MB in size, after compilationn?).
                      - With the current state of software patents, mesa will not be able to safely implement all opengl features.

                      Serafean

                      Edit :
                      Who programs the Mesa drivers is in the same position of the Wine programmers: they know what each library call is supposed to do, but not HOW the result is achieved in the original thing..
                      Mesa devs at least don't need to have bug-compatibility And IMO your reason for slugishness is incorrect : you know what you're supposed to do, and you have perfect knowledge of the hardware, so you do it in the optimal way. IMO the true reason is that mesa and its drivers is still catching up on features, and in a development process optimisations come after feature-completeness...
                      Last edited by Serafean; 10-16-2012, 08:54 AM.

                      Comment

                      Working...
                      X