For the HD3000 AMD said 2x GPGPU performance per flop against HD2000, because of the new architecture. Not 2x Shading performance (they are equal on shading). In what language you measure GPGPU performance anyway and regardless of my posts?
Way to miss the point, the API in question can't be considered gpl code, legally. So Alan Cox's (and your, apparently) politically motivated rage against nVidia is rather impotent.Quote:
What they can't do is link proprietary code against GPL code.
Oh, and define link, the gpl doesn't.
************************************************** ************************************************** *
Maybe add a small opensource part to the driver just for doing this communication could work legally? :/
API is API, but if you link against a GPL implementation of it, you're in trouble. You're welcome to make your own implementation, though, and nobody can stop you from doing that.
That's why you can't copyright a stdio.h header, but if you link against a GPL implementation of libc, you are bound by the GPL. This is why glibc does not use the GPL. The kernel does.
The GPL talks about derived code. Like I said, the legality of combinint proprietary software with GPL software depends on what this exactly means.Quote:
Oh, and define link, the gpl doesn't.
Many important kernel devs, starting with Linus, have a very clear opinion on this, and Nvidia is ignoring them because they have lots of legal muscle.
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 the name implies there is very little hand-holding and depending on how new you are to programming you might want something more 'basic'.
You should try and understand the difference between an API and actual CODE. NVidia wants to use kernel CODE from their PROPRIETARY driver, this code has been marked as only legally linkable from GPL compatible code (EXPORT_SYMBOL_GPL) which means you cannot legally call it from PROPRIETARY code. NVidia is allowed to copy the API verbatim as many times they want, but they have to write THEIR OWN CODE.
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. :D 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 .. :D
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 .. :D
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. :rolleyes:
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 .. :D
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 :D), 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. :D 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 .... -.-
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.Quote:
Nvidia/fglrx blobs have no future in Linux.