Updated and Optimized Ubuntu Free Graphics Drivers

[kmod]

When did your problem start? and are you using the Intel HD graphics chipset?

Mine started after updating this morning.
I am running Linux Mint 16 Petra (saucy)
I was thinking about upgrading to Linux Mint 17 and see if the latest updates form oibat work there.
Any thoughts?

By the way, I start up in recovery then continue to normal start up to be able to use the computer.
I suspect that is in vesa mode, no hardware acceleration ;(

For me, I upgraded the night before last night and unity wouldn't load at all, then after this afternoon's update (the latest) Unity loads but the graphic is all garbled like stfn's picture.I saw that the problematic commit was reversed, https://bugs.freedesktop.org/show_bug.cgi?id=79469, hopefully the next update would clear things up (assumming the reversal happened after this afternoon's update)

Intel ironlake here.

I would like to revert back to the original driver, however ppa-purge complains that there is no package list
so I am stuck with it, unless I surgically go in and replace packages. and then deal with that nightmare.

I clone my / partition regularly in anticipation of something like this, so I just reformated and restored and it is back to it was before after a few minutes. To use ppa-purge make sure that oibaf ppa is activated, you might have disabled it after the bad update.

[kmod]

Just got the latest update (~ an hour ago), still not fixed, graphics still messed up.

[kmod]

Still not fixed. Updated today, again graphic still all garbled.

[kmod]

After the latest update graphics are still messed up. So it is this bug
https://bugs.freedesktop.org/show_bug.cgi?id=79534

[0xBADCODE]

Fresh LLVM for 14.04?

Greetings! Don't you mind building recent LLVM versions like 3.4.1 or 3.5 GIT for Ubuntu 14.04 LTS and so on? LLVM 3.4 supplied with Ubuntu 14.04 proven to be totally bugged when it comes to GCN-based GPUs/RadeonSI. Actually, updating drivers isn't a big deal with GCN based GPUs because most bugs in RadeonSI (GPU lockups and all funny kinds of weird crashes) are mostly attributed to old and bugged LLVM which generates broken code. Not to mention it also needed for OpenGL 3.3 compliance.

If someone thinks I'm joking, try this WebGL demo (WebGL enabled browser required). Warning, RadeonSI users: this URL could crash your browser at very least due to error in LLVM. In worst case you can also get nasty GPU CP stall and GPU recovery tends to miserably fail, leaving your system without graphic output, so you'll have to reboot without picture on screen. You has been warned.

[mj13]

Greetings! Don't you mind building recent LLVM versions like 3.4.1 or 3.5 GIT for Ubuntu 14.04 LTS and so on? LLVM 3.4 supplied with Ubuntu 14.04 proven to be totally bugged when it comes to GCN-based GPUs/RadeonSI. Actually, updating drivers isn't a big deal with GCN based GPUs because most bugs in RadeonSI (GPU lockups and all funny kinds of weird crashes) are mostly attributed to old and bugged LLVM which generates broken code. Not to mention it also needed for OpenGL 3.3 compliance.

If someone thinks I'm joking, try this WebGL demo (WebGL enabled browser required). Warning, RadeonSI users: this URL could crash your browser at very least due to error in LLVM. In worst case you can also get nasty GPU CP stall and GPU recovery tends to miserably fail, leaving your system without graphic output, so you'll have to reboot without picture on screen. You has been warned.

It should be LLVM 3.4.2 by now. Hopefully that point release will fix the compilation errors of the previous point release. I agree that RadeonSI are currently useless at 3D applications with the current LLVM no matter what mesa version we have.

[curaga]

LLVM breaks ABI compatibility every release, so at least 3.5 would need to be built statically. Likely 3.4.1 too, as having them shared would break existing apps built against the shipped 3.4.

[0xBADCODE]

LLVM breaks ABI compatibility every release, so at least 3.5 would need to be built statically. Likely 3.4.1 too, as having them shared would break existing apps built against the shipped 3.4.

1) I do not have any apps linked agains libllvm except RadeonSI. In fact I only can see clang itself as another user of this lib. And looking on amount of bugs in LLVM crap I'm not really surprised there're so few masochists who are willing to use this LLVM stuff. There are literally 2 users: clang itself and RadeonSI.
2) From what I remember, various versions of same lib can co-exist due to different .so names, as .so name also includes lib version. Actually, Ubuntu haves LLVM 3.5 (git) in Universe repo, and its possible to install it side by side with 3.4 but Oibaf repo relies on LLVM version 3.4 from stock Ubuntu repo and would not use it. Unfortunately, stock LLVM 3.4 from Ubuntu repos is bugged beyond repair.

[curaga]

+ Webkit and a few other JIT/compiler users.

By default, only libLLVM has a versioned name. The headers and other libs do not. Perhaps Ubuntu patches this in, I don't know.

[0xBADCODE]

+ Webkit and a few other JIT/compiler users.

Negative. I took reverse dependencies lookup on ubuntu 14.04 and only discovered 2 users of libllvm: various MESA parts from Oibaf PPA and clang itself. No other packages were dependent on libllvm 3.4. AFAIK, Webkit uses its own JIT which haves nothing to do with llvm.

By default, only libLLVM has a versioned name. The headers and other libs do not. Perhaps Ubuntu patches this in, I don't know.

Ubuntu separates binaries and headers. Headers are in -dev packages and -dev package for llvm 3.5 is different one that 3.4. So they can coexist for sure. Not sure about 3.4.1 but I guess it just should replace all 3.4 stuff alltogether.