6-Way Ubuntu 14.10 Radeon Gallium3D vs. Catalyst Driver Comparison

[Hamish Wilson]

Preacher sermonizing the converted of course, but I for one am more than happy to accept slightly smaller frame-rates for all of the convenience that a properly mainlined Linux kernel graphics driver can offer, especially when at this point we can still definitely expect things to get better.

[M@GOid]

Besides i suspect this result are with LLVM 3.5 not 3.6-svn, 3.6 should help quite a bit the RadeonSI cards in performance, OpenCL and memory allocation optimisations(i think i saw few of those couple of weeks ago landing in llvm master).

I am using the Paulo Miguel PPA with LLVM 3.6, and didn't see any improvement in fps compared to Oibaf PPA with LLVM 3.5 in my R9 290.

[Vadi]

I'm using a laptop with an integrated Intel & AMD FirePro M4100. Which AMD driver would give me the best experience in terms of dual-monitor support (via DisplayPort, frequently docked/undocked as well as via VGA) as well as switchability between integrated and AMD?

There is an indicator for Ubuntu which allows you to "toggle" (that is, reboot the laptop if you want to change) between the cards - but last time I used it, I spent several hours fixing Xorg from crashing endlessly.

[brosis]

"binary blob"
http://en.wikipedia.org/wiki/RAS_syndrome

No.

Nonbinary blob = bash script written by Indian coder.

[slacka]

Gallium fundamentally flawed

70%-80% of proprietary is probably about as good as gallium can get. As the Gallium devs pointed out on the mailing list, Gallium is a better match for D3D than OpenGL.

If you look at Mesa and the Mesa Gallium state tracker from the
perspective of minimizing CPU cycles and cache misses spent in the
drivers, you will likely by struck by the sheer amount of inefficiency
here due to all the useless conversions here wasting CPU time, and the
unnecessary proliferation of objects, some large, in memory causing
all the obvious allocation/cache behavior issue.

http://lists.freedesktop.org/archives/mesa-dev/2010-April/000060.html

Hopefully OpenGL Next will be a better match for the Gallium state tracker.

[smitty3268]

70%-80% of proprietary is probably about as good as gallium can get. As the Gallium devs pointed out on the mailing list, Gallium is a better match for D3D than OpenGL.

http://lists.freedesktop.org/archives/mesa-dev/2010-April/000060.html

Hopefully OpenGL Next will be a better match for the Gallium state tracker.

Way to cherry-pick a message from 4.5 years ago to try and make a point. I'm sure nothing's changed since then, especially when we're seeing that gallium can actually outperform the proprietary drivers in certain applications, and be within 5% in plenty more...

[slacka]

Way to cherry-pick a message from 4.5 years ago to try and make a point. I'm sure nothing's changed since then, especially when we're seeing that gallium can actually outperform the proprietary drivers in certain applications, and be within 5% in plenty more...

I don't need to cherry-pick a message, the benchmarks in this article speak for themselves. The message just explain WHY gallium drivers use more CPU and are slower than classic Mesa and Proprietary drivers. All hope is not lost, as the OpenGL Next may be better aligned with the gallium architecture.

This is not just an AMD issue. Take a look at the ilo gallium driver numbers:

http://www.gearsongallium.com/?p=744

http://openbenchmarking.org/prospect/1406066-PTS-INTELILO32/b5ffccc495ac8fc37a677ed9b65602097d9b7902

[smitty3268]

I don't need to cherry-pick a message, the benchmarks in this article speak for themselves. The message just explain WHY gallium drivers use more CPU and are slower than classic Mesa and Proprietary drivers. All hope is not lost, as the OpenGL Next may be better aligned with the gallium architecture.

This is not just an AMD issue. Take a look at the ilo gallium driver numbers:

http://www.gearsongallium.com/?p=744

http://openbenchmarking.org/prospect...5602097d9b7902

ILO doesn't have more than a toy shader compiler in the backend, so using it as an example is complete nonsense.

As for AMD, can you prove that the extra CPU use is from the gallium architecture and not just the fact that they aren't optimizing certain bits of code as well as the proprietary ones do? I doubt it. I'd love to see it if you can.

I'm not saying there isn't some overhead in gallium. There may well be some. But it's certainly not broken by design, and looking at a few numbers and saying they prove your point is a long way from actually proving your point. It requires actual analysis to tell exactly which parts aren't up to speed. Maybe it's the kernel driver that is slow. Maybe the driver is flushing too much and stalling out. Maybe the shader compiler isn't working as well. Maybe it's just missing some magic that auto-replaces common shaders with some that were highly tuned for the specific hardware. Maybe the LLVM backend still sucks. What you can't say is that you've proven Gallium in general sucks.