Updated and Optimized Ubuntu Free Graphics Drivers

[starcrossed]

nomodeset disables the driver. remove that otherwise the driver won't load.

This was it! I had to compile a kernel from git head in order to get it to boot without nomodeset but now everything is working great. =)

Thanks!

[Guest]

Not sure if there would be much demand for it, but what about also including an updated xserver package (preferably from git, but 1.16 is stable; I think 1.15.1 is latest in Trusty)? A few notable changes with it is the integrated glamor support, along with improved performance.

[oibaf]

Mesa is built with llvm 3.5 now.
I don't plan to upload newer xorg, it would require to rebuild many drivers, the advantages are not enough.

[artivision]

Mesa is built with llvm 3.5 now.
I don't plan to upload newer xorg, it would require to rebuild many drivers, the advantages are not enough.

Can you build Mesa with the D3D9 state tracker? It will be appreciated be many.

[oibaf]

Can you build Mesa with the D3D9 state tracker? It will be appreciated be many.

I don't have time to look into this now. If someone is interested and has a working patch can post it here, I could eventually add it to the ppa.

[0xBADCODE]

Trouble on the way...

There is some trouble on the way. It comes to OpenCL - the dependencies are now not fully correct.

Updated stack brought LLVM-3.5 and most driver part are now built agains LLVM 3.5, making LLVM 3.4 mostly obsolete.

However, mesa-opencl-icd package from your PPA depends on at least ocl-icd-libopencl1 and libclc-r600 which are NOT provided by your PPA. Ancient system versions of these packages are used instead (about half year old).
Thats where we have trouble on the way (obsoleted) libclc-r600 depends on (obsoleted) libclang-common-3.4-dev (and also on ancient libclc-dev). So OpenCL stack would NOT use brand-new 3.5-rc, which is pity since LLVM 3.4 is totally broken in this regard.

What worse, dependencies are not fully correct at this point. It is now perfectly possible to purge libclang1-3.4 (not referenced by other packages). This however would break OpenCL to degree it cant build OpenCL programs.

Needless to say, programs using opencl can face nuclear fallout in strange ways:

[2014-07-26 22:02:26] In file included from <built-in>:296:
In file included from <command line>:7:
In file included from /usr/include/clc/clc.h:18:
/usr/include/clc/clctypes.h:3:10: fatal error: 'stddef.h' file not found
???Segmentation fault

I do think you may want to build ocl-icd-libopencl1, libclc-r600 and libclc-dev packages against LLVM 3.5 and appropriate versions of each other? Sorry for some extra work :\.

P.S. and as for MESA DX state tracker: what practical use of it? Wine does not relies on it and it's not like if there were some DX apps built for Linux. So it has been ditched for a reason - there is virtually no use for this artifact and it got abandoned.

[_SXX_]

P.S. and as for MESA DX state tracker: what practical use of it?

As example @tizbac answered me on YouTube that with Gallium-Nine and Nouveau he have better performance in GTA4 than in Nvidia blob and WineD3D. So I suppose it's can be interesting experiment.

Wine does not relies on it and it's not like if there were some DX apps built for Linux.

As far as I get Wine patch that required to support it isn't that big at all.
Patched Wine can be easily distributed with something like PlayOnLinux.

So it has been ditched for a reason - there is virtually no use for this artifact and it got abandoned.

No it's not abandoned. There is repo it's recently merged into recent Mesa:

https://github.com/iXit/Mesa-3D/commits/master

And some guys still around on #d3d9 IRC on freenode.

PS: I didn't yet made any test of current version so I can't say in what state it is.

[0xBADCODE]

Quick update: its possible to fix OpenCL without Oibaf by installing libclang1-3.5 package manually. Then LLVM 3.5 seems to be used - it improves things vs 3.4 heck a LOT.

[0xBADCODE]

So I suppose it's can be interesting experiment.

Has nouveau got working reclocking, after all? This is absolutely mandatory for anyhow serious competition with anything around. From what I've read from Phoronix, it looks rather pessimistic and I wouldn't count on nouveau for me at all (and I'm not a big fan of blob drivers in opensource systems either). Needless to say, for that reason I prefer Intel GPU on notebook and AMD GPUs on desktop and somesuch (looking forward to get some few powerful opencl based number crunchers on wheels, could be something *really* interesting to try on opensource stack, eh?).

As far as I get Wine patch that required to support it isn't that big at all.
Patched Wine can be easily distributed with something like PlayOnLinux.

My personal opinion is that Linux have to support native code in first place as first priority, support of foreign proprietary code doomed to be suboptimal and troublesome here and there anyway. If someone want to run proprietary windows binary, they can boot windows, after all (I doubt you've bought Windows game without being able to run it, eh?). If someone want game to run on Linux, they would be better to ask vendor for native port. Causing ton of headache to others with all these odd things is IMO a really wrong idea.

No it's not abandoned. There is repo it's recently merged into recent Mesa:

https://github.com/iXit/Mesa-3D/commits/master

And some guys still around on #d3d9 IRC on freenode.

Whatever. I bet DX would never be first class citizen in Linux due to proprietary/vendor locked nature of this API. Which makes it "unwelcome guest" IMO. And if someone wants "windows but opensource", there is already ReactOS. But looking on how crappy it performs 15 years since launch it looks like if not too much devs actually want to be just a mindless followers of MS who blindly reimplemends MS-only proprietary APIs. For these reasons I mostly classify all thsi DX-in-Linux as waste of time. MS would always have advantage as creator of API, so there is no point to even try to beat them. This is battle you can't win for sure.

Long story short: I think Linux is good enough to have own path, without being "Windows but opensource" or whatever else.

[_SXX_]

Has nouveau got working reclocking, after all? This is absolutely mandatory for anyhow serious competition with anything around.

As stated in comment to video I linked it's was only partially reclocked GPU and not reclocked memory, but still had better performance than Nvidia blob. Considering @tizbac done tons of Gallium Nine testing I have no reasons to not trust him.

My personal opinion is that Linux have to support native code in first place as first priority, support of foreign proprietary code doomed to be suboptimal and troublesome here and there anyway. If someone want to run proprietary windows binary, they can boot windows, after all (I doubt you've bought Windows game without being able to run it, eh?). If someone want game to run on Linux, they would be better to ask vendor for native port. Causing ton of headache to others with all these odd things is IMO a really wrong idea.

We already have Wine and many people use it. Does it hurt if we work a bit better?

Anyway this is really off-topic and unfortunately I not the guy who able to maintain patches for Mesa because nearly zero of free time. So we might create some other topic for Gallium nine if you want some slow discussion about that.

...

Back on topic. Is LLVM 3.5 bring any improvements at all for LLVM backend of R600g driver or no?