You can sign up to get a daily email of our articles, see the Mailing List page!
Support us on Patreon to keep GamingOnLinux alive. This ensures we have no timed articles and no paywalls. Just good, fresh content! Alternatively, you can donate through Paypal, Flattr and Liberapay.!

Feral about AMD driver support

Posted by , | Views: 11,022
Reading through the Feral Interactive Facebook page, I stumbled upon this post, which is the most elaborate about the topic by Feral I know of about AMD support.

QuoteWe can also pass your query on to our devs in the hope one of them has a moment to answer, and we were lucky enough to snag a bored one on his lunch break. So here goes:

At Feral we target three different vendors on two different platforms so we have experience working on six different possible card and driver combinations (not counting the OpenSource AMD drivers which would make seven). This means we spend a lot of time working on code that is portable and can support specific options to work around around limitations on all the various hardware and software combinations when various setups are detected.

When asked, we've always been open about our support for different vendors and the reasons behind the support or lack of it. With recent games we have taken a large leap forward in the complexity of the title, meaning even on minimum settings features available in OpenGL 4.1 or in some cases 4.3 are requirements to be able to even load on the minimum settings.

This has meant we have been pushing the newer and less tested areas of the drivers to the maximum and unfortunately this means that in some cases we find either missing features (in the case of the MESA drivers) or some driver issues that need to be addressed which has been the case on AMD.

The actual issues we find are always interlinked and not as simple as X doesn’t work, but usually more subtle. E.g. in this specific instance of this spec this feature doesn’t work as intended, or when running feature X and feature Y at the same time then side effect Z will happen, so it’s not something simple that can be listed in bullet points. We are and always have been committed to supporting all vendors devices when possible and that goal has not changed.

However, as the MESA driver fix list is open and you seem to be interested in the technical side of things, here's an example of an issue we found in drivers that has been fixed but prevented a game we are working on from rendering correctly: Link

The source of the quote can be found under the question of Steffen Wnkr on this page:
We do often include affiliate links to earn us some pennies. We are currently affiliated with GOG and Humble Store. See more information here.
The comments on this article are closed.
Page: 1/2»
  Go to:

MayeulC 5 December 2015 at 5:28 pm UTC
Thanks for sharing the article. Though not very detailed, it explains a bit more why AMD and intel cards aren't supported, and it seems they don't completely exclude these cards from their development.
alexThunder 5 December 2015 at 6:50 pm UTC
Can confirm. If you start developing with cross-vendor and -driver OpenGL, you will stumble upon this rather quickly.
ElectricPrism 6 December 2015 at 1:51 am UTC
This was a good read. I also enjoyed the patch summary.

To me it reinforces the truth that all systems have caveots and suck somehow.

At least in this instance the openness of the code allowed the problem to be resolved.

The more that they, valve & others carve the way the easier it'll be to follow suit in design
Shmerl 6 December 2015 at 4:22 am UTC
Hopefully Vulkan will fix most of this mess.
oldrocker99 6 December 2015 at 4:56 pm UTC
There is a reason why I have always bought nVidia cards, and AMD/ATI's Linux "support," which is why I don't buy their cards, is still problematical. I remember when Painkiller came out, which worked for me the first day. ATI users had to wait about 5 weeks for a driver which would work. It should be said that the game developer did work with ATI to fix the problem, but still...
edo 6 December 2015 at 5:19 pm UTC
In other words, Feral is the 1st company ever developing GL 4.2-5 AAA games on linux, so thats why they find many untested code on the drivers, and that means bugs. I hope Feral will start supporting Vulkan on their future games the 1st second after its launched.

Last edited by edo at 6 December 2015 at 5:20 pm UTC
STiAT 7 December 2015 at 3:16 am UTC
Well, porting D3D code to Vulkan is probably even more complicated than porting it to OpenGL, I rather expect that DX12 code will be ported to Vulkan, since that would be much easier. They're really one of the first companies really going to the limit of OpenGL in Linux, and of course there are a lot of issues and untested features. It's good to read they are actually doing that, since it's necessary.

For AMD. I have some love for the company, but to be true, they can't get even close to NVidia proprietary drivers. Even if it's binary blobs, for me NVidia is one of the first hour Linux-Supporters, and the support has been good. There is a lot of work in the drivers they provide for Linux, so therefore as well a pretty good financial investment. And they've done that for years now. I guess the most game developers support only NVidia in Linux because of their very good proprietary drivers.
Pangachat 7 December 2015 at 4:36 am UTC
Fine, while they experiencing, i buy/play games from other developers, which are working without problems on my actual videocard.
mao_dze_dun 7 December 2015 at 11:11 am UTC
As somebody pointed out recently - there is a reason the Unigine benchmarks run so well on AMD cards in Linux but games don't. The benchmarks have to be completely OpenGL compliant in order to provide accurate results. And guess what - when the code is clean AMD performs very good. It's funny because Nvidia users don't realize that if devs/porters wrote OpenGL compliant code they'd get better performance, as well - much closer to Windows as opposed to the current 30 to 50% gaps.
I'm not exonerating AMD in any way - they should be more flexible with their drivers considering the situation and support messier solutions. However, the real blame lies with developers who go the quick and dirty route instead of writing clean code, which results in unplayable performance in on AMD and Intel and nerfed on Nvidia.
I'm quite shocked nobody talks about that problem, because it's probably the most serious one regarding Linux gaming IMO. No amount of driver fixes and next-gen APIs will bring Windows level of gaming performance to Linux unless the developers do their job the right way. Vulkan will be like a Ferrari - unless you know how to drive it, you'll most likely fly of the road at the first turn.
tuubi 7 December 2015 at 11:38 am UTC
View PC info
  • Supporter
@mao_dze_dun: I can't find any indication that Unigine's benchmarks use any of the latest and most advanced OpenGL functionality though. There are reports from 2013 that they're using some features of 4.3, but that doesn't mean Feral is speaking out of their ass. Unigine might even purposely be restricting themselves to extensions and features that are universally and well supported.

As someone in the software business I'd take a strict implementation of a standard or a specification any day over vendor-specific quirks, bottlenecks or loose interpretations, but we just might not be qualified to argue with people actually writing cutting-edge OpenGL when we know little more than what we've read on the intertubes.
  Go to:
While you're here, please consider supporting GamingOnLinux on Patreon or Liberapay. We have no adverts, no paywalls, no timed exclusive articles. Just good, fresh content. Without your continued support, we simply could not continue!

We also accept Paypal donations and subscriptions! If you already are, thank you!
Livestreams & Videos
Community Livestreams
See more!
Popular this week
View by Category
Latest Comments
Latest Forum Posts