Originally posted by sarmad
View Post
Announcement
Collapse
No announcement yet.
Painkiller Linux Dev Recommends Non-NVIDIA Open Drivers
Collapse
X
-
-
Originally posted by MWisBest View PostBelieve it or not, Rallos is correct. From what I've seen not many people on this forum are even slightly experienced with OpenGL (not including people who actually contribute code to Mesa and open-source GPU drivers and whatnot of course, but those aren't the people in here trolling that I'm mostly addressing)... now I'm not claiming to be an expert by any means, but with the knowledge I have I can tell you that Nvidia drivers allow some ridiculously stupid non-compliant (non-compliant meaning not following the OpenGL published specification to the letter) OpenGL code to run, which then causes headaches for those developers who actually put their time into making sure all the details in the OpenGL spec is followed like they should be. You then have your developers using Nvidia and Nvidia drivers only for development and testing and then blame AMD's drivers for all the issues in the developer's program, when really it's either Nvidia's or that developer's fault and not the back-asswards way everybody seems to think.
I believe there was one developer who goofed up in a GLSL file and didn't put the GLSL version at the very top of the file like they were supposed to (it might not have been the version, but it was something along these lines) as it is supposed to be done according to OpenGL spec. Nvidia's drivers didn't have a problem running this malformed code, but AMD's drivers complained about it as they are supposed to. We're even seeing crap like this with LLVM/Clang vs. GCC, where GCC will have no problem building a program that doesn't follow the spec but Clang will complain about it telling the developer to fix their fucked up code (more or less...). However, it seems people are more accepting and understanding of why Clang does that and people have made effort to get everything complaint and compiling correctly with Clang, whereas we're seeing the exact opposite with the Nvidia situation that nobody seems to know or care about. Oh, long-story short, I think that developer was too arrogant to make any correction to his code when it was pointed out and instead blamed AMD since it worked fine for Nvidia so apparently it should have no trouble with AMD either then.
What we need is for Mesa to keep upping it's OpenGL spec implementation, and then have that as a "base" of sorts for developers to test their code on via just a CPU-based renderer. Sure, that's not going to be fast to use all the time when testing code, but when a rendering engine is being finalized or something, run it through a "generic" OpenGL sorta thing rather than a more vendor-specific implementation?
Mind you, this is just my view and opinion. Everybody is entitled to their own opinion, and I'd be happy to debate back and forth on something, but not when it goes downhill into a hostile argument.
I've never used WINE though so I can't comment. I just thought it was open source so if the OpenGL implementation wasn't correct and that's a known entity, why doesn't somebody go in there and fix it?
Comment
-
Originally posted by MWisBest View PostI've already addressed your 6750M issues on at least one occasion, asking some questions and whatnot to help possibly figure out what's causing your issues. I ended up with no reply from you whatsoever, and here you are complaining about your 6750M yet again. Please, stop trolling.
Also, I did respond to your recommendation on the other thread as far as I remember. I'm surprised you're saying I didn't.
Comment
-
Originally posted by sarmad View PostMaybe you read my post without reading the original article to know what we are talking about in the first place. You gave me recommendations on how to get ATI to work with the open source drivers, not the binary ones, and this article is all about binary vs open source drivers. So I'm here to explain my experience with the closed source drivers and why I'm not surprised that the article is recommending open source ones for ATI.
Also, I did respond to your recommendation on the other thread as far as I remember. I'm surprised you're saying I didn't.
That thread was regarding the open-source drivers, my mistake, however I am correct in that you didn't reply to me.
Honestly, the open-source drivers have tended to give me the fewest problems of the two. Once I'm able to dial-in fglrx just right it usually turns out OK, but it's a little more tinkering versus the open-source drivers working much better out-of-the-box.
Installing fglrx via apt-get or the additional whatever menu (does the same thing, as far as I know) probably isn't a great idea. I don't think Ubuntu really stays on top of those packages like they should be.
Following the guide here was one of the easier ways to get the latest version of fglrx up and going on Ubuntu at first for me, so I'll link you to it to see if it's at all helpful: http://wiki.cchtml.com/index.php/Ubu...allation_Guide
What I asked in that other thread that might still be relevant: "If you're booting via UEFI that could be related to that (with Ubuntu 13.04 anyway), but I'm not aware of any systems that shipped with UEFI and a 6750M... except maybe some Apple laptop of some sort? I believe I remember a 6750M BIOS being posted that was taken from some sort of Apple laptop... those have their own slew of Linux issues to begin with."
Some more info that might be helpful: Is this an Intel CPU + AMD GPU system? Or AMD APU + AMD GPU system.
EDIT: Jeez I'm tired... I read your post as saying you were surprised they recommended open-source drivers! Definitely a sign it's time for bed, lmao. Sorry!
Comment
-
Originally posted by Rallos Zek View PostPainkiller Developers do not know how write graphics code it seems. Nearly every time one blames Catalyst for being buggy its the user land code in this case Painkiller itself that is a mess of buggy code not the driver. AMD catalyst likes clean OpenGL spec code, if you use non standard OpenGL code than catalyst will mess up. Nvidia does the wrong thing and lets one write buggy OpenGL code that works with their driver.
Hence why wine sucks on catalyst is cause wine devs target Nvidia hardware because they do not know how write proper code.
Developers stop writing bad code and blaming drivers.
Comment
-
Originally posted by droidhacker View PostAll that actually says is that nouveau is WORSE than nvidia's craptacular blob, and that AMD blob is (and this is quite obvious for just about everyone who has used both blob and open source radeon drivers) worse than AMD OSS. Makes no comparisons between nvidia blob and amd oss.
Comment
-
Originally posted by BSDude View PostActually looking on nouveau's freedesktop page, besides the power management work everything else is pretty much done. Of course you've got the issue of outstanding bugs but now that nvidia has thawed a little bit towards the OS project maybe we'll see an improvement in that area.
Performance is still somewhat lacking, but that is due to the lack of power management (without PM it's dangerous to enable proper 3d clocks, since you are in danger of frying your board.)
Still, nouveau runs great on my 650M, including suspend, vgaswitcheroo, 2d and 3d. That is a huge amount of progress!
Comment
-
Originally posted by BlackStar View PostIndeed! It actually works surprisingly well, 3d and everything, considering how difficult it is to reverse-engineer hardware.Last edited by Hamish Wilson; 22 October 2013, 01:07 PM.
Comment
Comment