Painkiller Linux Dev Recommends Non-NVIDIA Open Drivers

[MWisBest]

Not surprising at all. I spent this last weekend trying to get Catalyst to work properly on my Radeon HD 6750M hybrid graphics laptop. Here is the problems I got:
* Installing using apt-get or the Additional Drivers utility breaks the system, X doesn't start or starts with no hardware acceleration.
* Installing the stable driver from ati.com broke the system. X doesn't work anymore. Had to install the latest beta to fix it.
* The beta works, but VSync doesn't work. Tearing is everywhere and modifying VSync options make no difference at all. Games that depend on vsync for timing (Superfrong HD) was running ultra fast that it's not playable.
* Switching to the integrated GPU from the Catalyst control center works fine, but it breaks the GLX direct rendering which is required by Steam. So, Steam doesn't even start.

If only Intel releases a high performance GPU/APU. That would be the best.

I'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.

[johnc]

Believe 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.

It wouldn't surprise me in the least bit.

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?

[Hamish Wilson]

As a question, why do the R600g drivers supposedly work better with WINE, according to some developers, than Catalyst does?

[sarmad]

I'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.

Maybe 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.

[MWisBest]

Maybe 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!

[.CME.]

Painkiller 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.

No matter how bad the code is, the driver should NOT crash the system.

[BSDude]

All 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.

Actually 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.

[fatino]

Nvidia drivers...

For people saying nvidia blob is soooo goood there's still no proper SLI support and no OC for newer GPUs. It seems like it won't change anytime soon.

[BlackStar]

Actually 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.

Indeed! It actually works surprisingly well, 3d and everything, considering how difficult it is to reverse-engineer hardware.

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!

[Hamish Wilson]

Indeed! It actually works surprisingly well, 3d and everything, considering how difficult it is to reverse-engineer hardware.

Indeed, although it should be remembered that Nouveau has also benefited from the work of other vendors, such as Intel and AMD, who put in the work to develop up the Linux graphics infrastructure to such a state as to make Nouveau viable. This is not an attempt to take away any sense of accomplishment that the Nouveau developers rightly deserve, I am just trying to point out that pure reverse-engineering was not the solution in of itself, and that Nvidia users have benefited from AMD and Intel's policies on and development of the free graphics stack.