Updated and Optimized Ubuntu Free Graphics Drivers

[artivision]

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?).


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.


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.

We want to play our favorite games (art), without the need of proprietary software (player) like Windowz and D3D. To any computer available, not make as buy consoles or x86 without our will. Meaning open resources like OGL and dynamically linked compilation like LLVM-JIT (maybe with persistent cache). No DRM. Same performance, universal play.

Because we don't have that, we need a compatibility layer (mostly D3D) on Linux, plus a better recompiler like a better Qemu-LLVM or better.

My main concern for today's D3D on Linux is that a D3D state tracker can be based on an OGL one and can be developed 10 times faster than Wine's translation layer, just with one developer. Only then i measure the native speed. As for availability, i believe with a Gallium patch, a state tracker can be used even with closed drivers, like when you install mesa on Windowz.

[oibaf]

I pushed an updated libclc (current git), now also built with llvm-3.5. Mesa is rebuilding now. Please try it in a hour or so.
BTW, which OpenCL applications do you use? Are them applications in Ubuntu archive or external apps?

[gutigen]

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.

I just want to say - thanks for great work man

[0xBADCODE]

I pushed an updated libclc (current git), now also built with llvm-3.5. Mesa is rebuilding now. Please try it in a hour or so.
BTW, which OpenCL applications do you use? Are them applications in Ubuntu archive or external apps?

Ahh, I see, libs updated - now it seems to be correct from logical point of view.

Yet, I wouldn't call LLVM3.5 perfect. Now it can build and run kernels where previous versions failed. Unfortunately, its not a big win in many cases. Because it turned out GPU memory intensive workloads (these which heavily use VRAM) tend to cause funny GPU crashes.

As for what apps I'm giving a try: various. Some examples could be:
1) BFGMiner (git repo with most recent version can be found at https://github.com/luke-jr/bfgminer.git). Powerful and funny program with ton of options and relatively big opencl kernels. It got some basic support of MESA. SHA256 bruteforce is mostly about massive parallel computations while scrypt bruteforce is example of GPU memory-heavy workload.
Current status (with 3.15 and 3.16-rc6 kernels, does not affects things too much): SHA256 - works and computes correctly on both R9 270 (GCN) and HD5770 (VLIW). And even gives about 80% of proprietary driver speed - nice start, isn't it? Though its mostly interesting as testcase/benchmark since ASICs would beat GPUs at SHA256 way too much. Earlier stack had issues building scrypt kernels due to LLVM register allocation failures. Now it can build these kernels. Unfortunately, its not a big win to the date: being memory intense workload, it quickly crashes any GPU, be it VLIW based HD5770 or GCN based R9 270. Just launch it with --benchmark --scrypt and enjoy by GPU deadlock in matter of ~30 seconds. I think AMD guys should use that scrypt bench as some standard testcase or so .

2) Clinfo. Interestingly, clinfo supplied by Ubuntu/Debian does not works at all, giving obscure error message: E: -30 if you try it with MESA/LLVM stack. That's FAIL but I'm not sure on who's side it happens. However, there're some more informative and more reliable tools like https://github.com/Oblomov/clinfo.git - this one works, verbose enough to give me idea where something breaks and seems to provide more or less correct info about GPUs, matching their specs. It also builds simple kernel as well and if something totally broken, its really nice place to start as it would give adequate idea what fell apart.

3) Clpeak (can be found at https://github.com/krrishnarraj/clpeak.git). Normally it supposed to be just some GPU VRAM benchmark. While it sounds simple... it tends to crash GPUs a lot during tests. Most notably, I *never* managed to get a single pass on GCN based GPUs at all. I can suggest this one as another testcase for regular use by AMD guys . Seriously, just launch it and enjoy by failry quick GPU deadlock. Especially on GCN GPUs. Not sure why it should work so bad while other workloads like 3D games can run for hours if not days.

4) "OpenCL examples" - by AMD (get at git://people.freedesktop.org/~tstellar/opencl-example). Basically what it tells - some relatively simple examples, by AMD guy. Mostly working, though get-global-id and get-global-id-3d just crash with segfault.

Also I have ideas to try some more things in near future. For example, Cryptohaze can be interesting to try, but it complicated app and I think MESA+LLVM should rather get more basic things working first before trying something like this. Now it looks like major issue are memory-heavy workloads - they all tend to crash GPUs and then GPU recovery usually fails to deal with it . So if someone about to try mentioned tools, don't forget to save files and sync filesystem first...

On side note I can also admit some funny stuff with access rights if you have more than 1 GPU in your system and some GPU(s) are "headless". In system with 2 * HD 5770 you can only see and use both if you running app as root. Else, current user only can see GPU which displays his desktop. To make things more funny, access rights on /dev/dri/card* are handled in really strange way. User should have its primary group set to "video" to be able to deal with these. Else user faces "access denied", even if user has been added to "video" group (so "video" is supplementary group for that user but primary group is something else, traditionally it would be group matching user name). Adding supplementary groups works for normal files but when it comes to /dev/dri/card*, kernel seems to only care about main group of user and not cares about supplementary groups at all, unlike happens with normal files. And even if you strace and get idea about it... then it turns out some ioctls still fails with access denied, too. And this prevents GPUs from being detected. So to use some "headless" GPU you have to run app as root. Which is not the best idea ever, obviously. I think rights handling on /dev/dri/card* is a kernel-side bug? Not sure why card* device rights should be treated in totally different way than usual file access rights. How the heck unprivileged user can use GPUs other than one displaying desktop and how to do it properly without launching everything as root? Just curious how it supposed to work.

[asdfblah]

@oibaf: thank you very much

[Sundance]

Hello all,

Oibaf, thank you for your work.

Is there a documentation somewhere to compile Mesa into a set of .debs such as in your PPA?

Since the Oibaf PPA moved onto Mesa 10.3-git, I've experienced important stability issues -- Xorg freezes and crashes, mainly. Mesa 10.1 such as ships with Ubuntu 14.04, has a bug where the Minecraft modpack I mostly play these days grows slower and slower until it's unplayable.

I would therefore like to compile Mesa 10.2, which worked well for me back when the Oibaf PPA was based on it, into a set of Oibaf-like .debs. Is there a documentation somewhere to do that?

Thanks.

[dungeon]

@Sundance

Generally you need packaging knowledge:

https://www.debian.org/doc/manuals/maint-guide/maint-guide.en.pdf

That may sound hard, but all books firstly sounds hard... but you obviusly will need sometimes knowledge from there .

There are simplified guides, firstly you can try to rebuild some package:

https://wiki.debian.org/BuildingAPackage

Or maybe try this more simplified, but right to the matter if you wanna rebuild packages only for you:

http://raphaelhertzog.com/2010/12/15/howto-to-rebuild-debian-packages/

So there is mesa 10.2 in utopic, can you backporting it for trysty using this guide? It is easy

http://packages.ubuntu.com/utopic/libgl1-mesa-glx

http://anonscm.debian.org/cgit/pkg-xorg/lib/mesa.git

Of course you may want to have your own PPA and to build there, that is also easy after *knowing* some of those things .

[oibaf]

@0xBADCODE
Make sure to report the bugs, maybe they can be fixed before final llvm 3.5.

@Sundance
It would be better to report the current problems you have here: https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa so that they can be fixed.
You may also found older version of packages you downloaded (unless you cleaned the cache) in /var/cache/apt/archives .

[dungeon]

Yeah, filling a bug is the best way to your usage case may continue to work. And there can be a bugs along the way

@Sundance

For example, current 10.2 git does not build against current llvm 3.5 . Patch is included in git head:

http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/auxiliary/gallivm/lp_bld_debug.cpp?id=564821c917f4a9d5a0de2ee77b90b0cd85e3d3a6

But not included in mesa 10.2, so you may request that to be included, just point out that on mesa-stable list:

http://lists.freedesktop.org/mailman/listinfo/mesa-stable

[okias]

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.

Hey, I got pointed to you message from here

If you want, there is patch against today git download.ixit.cz/d3d9/ for building libd3dadapter9.so mesa has to be passed "--enable-nine" to ./configure.

I hope it helps