AMDGPU-PRO vs. RadeonSI/RADV & NVIDIA's Linux Drivers To End 2016

[Screech]

In Unigine Heaven in windows DX11 I get a score of 1300 and in linux opengl 900... A year has passed and the linux drivers are not close to windows performance... In windows with each major game you get new optimized drivers, in linux AMDGPU-PRO is updated once at 4 months and the drivers are still experimental/beta...

[bridgman]

It's not. Unigine benchmark is 100% OpenGL and the performance compared with windows is terrible: 20-30% less performance. A year has passed and AMD linux drivers are still trash (both open source and proprietary).

I don't think so. More like 3-4% performance difference for between Windows & Linux for the closed-source GL driver, and a bit over 10% for the open source GL driver back in August. Since then the open source driver has pretty much caught up with the closed driver on Heaven - only 2 fps difference now vs 5 fps a few months ago.

http://www.phoronix.com/scan.php?pag...ux-rx480&num=1

You may be comparing DirectX on Windows with OpenGL on Linux, which would give you the 20-30% performance delta you mentioned.

[curaga]

None of the images/charts in this article show up for me. Other articles work fine.

[Strunkenbold]

OpenGL Performance in Unigine Heaven on my 7970 is actually better on Linux Mesa GIT vs Windows 10 Crimson Relive. 60 vs 58 fps.

[Passso]

sponsoring most linux-hostile vendor is never right

Even when most-hostile gives the most-performant experience?

I fully understand that for some people open source drivers are important, but NVidia makes a good job and delivers drivers day-1 for Linux on-par with Windows.

[mannerov]

In Unigine Heaven in windows DX11 I get a score of 1300 and in linux opengl 900... A year has passed and the linux drivers are not close to windows performance... In windows with each major game you get new optimized drivers, in linux AMDGPU-PRO is updated once at 4 months and the drivers are still experimental/beta...

unigine heaven uses slightly different rendering paths dx9 vs dx11 vs gl.

For example lightning is computed differently. Looking at what it does dx9 vs gl you can notice for gl, rg32F buffers are used to store intermediate lightning computation, while dx9 uses argb32f (which is heavier to sample from on amd. If you replace by argb16f, with gallium nine you get significantly better dx9 performance than gl). The intermediate results stored in these buffers are not exactly the sames either. Very likely dx11 has yet a different lightning computation pass, and lightning is the heaviest pass on Heaven.

[schmidtbag]

misquoting and pasting generic urls won't help you. I never said that FOSS driver includes closed components.

Same could be said about you... you're misinterpreting something I never said and then disagreeing with it...
I explicitly mentioned "short answer" and what you're focusing on is exactly the opposite.

FOSS stack is Mesa + llvm + libdrm + radeon.ko/amdgpu.ko
PRO stack is AMD-closed-GL + patched-amdgpu.ko

We're talking about software provided by AMD for AMD hardware, not the entire graphics stack. Tuxee asked why AMD has 2 different driver implementations. You're blowing the accuracy of my answer out of proportion, because mesa isn't relevant to the scope of the answer.
Look at it like this: if someone asks "what's the difference between a muffin and a cupcake?" the short answer is "cupcakes are desserts, muffins aren't". Meanwhile, you come along and say "wrong - muffins are sometimes desserts and they are baked at different temperatures". You're getting anal about details that don't matter to the question. Though the additional details aren't wrong, the person wasn't asking about how the pastries are made, and pointing out semantic differences is defeats the purpose of a short answer. Whenever someone says "short answer" it implies there is a lot more involved, including (but not limited to) caveats.

Anyway.... all that being said, if you look at just the drivers, y'know, the thing Tuxee asked about, radeon/amdgpu (non-pro) is only kernel-level software. Feel free to post links proving me wrong.

The reason to have AMD-closed-GL is to support features needed by CAD tools that will never be implemented in Mesa.

My question was rhetorical. The amdgpu-pro driver is more than what you said and certainly not limited to CAD tools or workstations. It also involves the Vulkan drivers, it is more OpenCL ready, it involves disk shader caching, and so on.

[bridgman]

We're talking about software provided by AMD for AMD hardware, not the entire graphics stack. Tuxee asked why AMD has 2 different driver implementations. You're blowing the accuracy of my answer out of proportion, because mesa isn't relevant to the scope of the answer.

I don't understand this statement - maybe half of our open source developer effort goes into the mesa drivers and the rest into the other components.

[schmidtbag]

I don't understand this statement - maybe half of our open source developer effort goes into the mesa drivers and the rest into the other components.

I meant mesa as a whole, not the AMD drivers for mesa (obviously that is relevant). I was a bit vague there.

[boltronics]

PRO driver supports features that FOSS driver does not. Some of those will never be supported by FOSS driver -- like compatibility profiles for OpenGL needed for some tools (mesa only gives you OpenGL 3.0 if you ask for compatibility profile).

Never say never!