How Ubuntu 16.04 Is Performing With AMDGPU/Radeon Graphics Compared To Ubuntu 14.04 With FGLRX

[rabcor]

Can we please get an AMDGPU and fglrx vs nvidia showdown?

Also seems like AMDGPU is finally starting to come around, I'm glad to see this (although it's still lagging behind in some areas)

AMD could work a bit faster on their linux driver stack though; I feel like despite the whole AMDGPU deal, we're still getting second-rate treatment compared to windows; all we've got now is a better driver ecosystem of sorts.

[Pecisk]

The obvious question there is "why?".

The open driver is already so close to parity with your closed stack, and with so many @amd.com addresses on the mailing-list it's getting closer every week.
Getting a rewritten blob running on top of DRM can't be straightforward; I'd bet Mesa is (finally) at GL4.5 before it's done. Without dividing efforts, the latter could be done even sooner.

So why pick up the cost of developing and then maintaining two stacks in the long term, when one of those actually exists and works right now?

Because fglrx is needed for 'legacy' support requested by AMD powerbase - CAD and co applications. It is also a nice fallback if something doesn't work out for specific hardware.

[Pontostroy]

hd 7790 amdgpu performance compare to windows catalyst (opengl and dx9 games and benchmarks ~ 85%)

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

[andre30correia]

Because fglrx is needed for 'legacy' support requested by AMD powerbase - CAD and co applications. It is also a nice fallback if something doesn't work out for specific hardware.

the why, is because catalyst won't support x 1.18 yet. maybe this's a good thing for open driver i don't see the point of two drivers supported by amd, they should do like intel

[bridgman]

I feel like despite the whole AMDGPU fiasco, we're still getting second-rate treatment compared to windows; all we've got now is a better driver ecosystem of sorts.

Just curious, what "AMDGPU fiasco" are you talking about ?

[bridgman]

The obvious question there is "why?".

The open driver is already so close to parity with your closed stack, and with so many @amd.com addresses on the mailing-list it's getting closer every week. Getting a rewritten blob running on top of DRM can't be straightforward; I'd bet Mesa is (finally) at GL4.5 before it's done. Without dividing efforts, the latter could be done even sooner.

So why pick up the cost of developing and then maintaining two stacks in the long term, when one of those actually exists and works right now?

It's not really "two stacks", more like "one and a half stacks" from a development POV. The kernel, libdrm, X and multimedia drivers are mostly common anyways and the OpenCL, OpenGL and Vulkan drivers are code-shared with Windows. I say "mostly common" because the hybrid kernel driver may include not-upstreamed-yet patches and potentially some non-upstreamable patches, but essentially all of the code will be common.

Long term I expect that OpenGL will be the only real difference between all-open and hybrid (since we're planning to open up the other components over time), and the reason for keeping a separate OpenGL driver is that some workstation applications require compatibility-mode profiles (which Mesa does not support) while game developers have generally been able to avoid using them.

[Nille_kungen]

bridgman https://www.phoronix.com/forums/foru...450#post132450
Seems like we're past that 70% now but maybe we also got more hardware-specific code now or maybe that only applied to OpenGL 2.1

[bridgman]

Seems like we're past that 70% now but maybe we also got more hardware-specific code now.

Yep... the 70% estimate (originally 60-70% IIRC) was based on a shader translator or very simple compiler; once Vadim started working on SB and Tom started working on LLVM that estimate was at least potentially left behind. On the other hand writing complex shader compilers is hard and the learning curve is steep so the estimate held up pretty well for a while. We made the estimate in 2007 and it held up until... what, 2013/2014 ?

[jrch2k8]

It's not really "two stacks", more like "one and a half stacks" from a development POV. The kernel, libdrm, X and multimedia drivers are mostly common anyways and the OpenCL, OpenGL and Vulkan drivers are code-shared with Windows. I say "mostly common" because the hybrid kernel driver may include not-upstreamed-yet patches and potentially some non-upstreamable patches, but essentially all of the code will be common.

Long term I expect that OpenGL will be the only real difference between all-open and hybrid (since we're planning to open up the other components over time), and the reason for keeping a separate OpenGL driver is that some workstation applications require compatibility-mode profiles (which Mesa does not support) while game developers have generally been able to avoid using them.

So far, i think RadeonSI kick the living crap out of Catalyst (except for for 4.5 compliance and some speed here and there) in all the features that actually matter, my only request is please take your time with the new hybrid approach and please burn with fire XvBA code (entirely please, to the point the actual developers forget it existed at all) and use(recreate) the gallium interface for VDPAU/VA-API if possible.

another favor for us AMD users is please don't bring back FGLRX OpenCL code, delay it if you have to because the current code is horrible to work with.

Except those 2 points i think we are all golden with the hybrid approach, thing like overdrive can wait since is pretty much useless(most GPU are hard to overclock this days and the benefit is pretty small most of the time) and it wasn't exactly stable in Catalyst either to start with.

About the comment from somebody about per game Vsync i'm pretty sure this works already with RadeonSI either select in-game, through DRIconf and globally depending the compositor, so im not sure what could be missing there.

[Drago]

It's not really "two stacks", more like "one and a half stacks" from a development POV. The kernel, libdrm, X and multimedia drivers are mostly common anyways and the OpenCL, OpenGL and Vulkan drivers are code-shared with Windows. I say "mostly common" because the hybrid kernel driver may include not-upstreamed-yet patches and potentially some non-upstreamable patches, but essentially all of the code will be common.

Long term I expect that OpenGL will be the only real difference between all-open and hybrid (since we're planning to open up the other components over time), and the reason for keeping a separate OpenGL driver is that some workstation applications require compatibility-mode profiles (which Mesa does not support) while game developers have generally been able to avoid using them.

Why not open up the OpenGL thingy also. Not integrate into mesa, but just develop it in open repo. I doubt there are much secrets in the compatibility profiles.