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.
The source of the quote can be found under the question of Steffen Wnkr on this page: https://www.facebook.com/feralinteractive/photos/a.752000158157823.1073741829.118120444879134/1079022688788900/?type=3 Article taken from GamingOnLinux.com.
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: https://www.facebook.com/feralinteractive/photos/a.752000158157823.1073741829.118120444879134/1079022688788900/?type=3 Article taken from GamingOnLinux.com.
0 Likes
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Patreon
PayPal
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
Last edited by edo on 6 December 2015 at 5:20 pm UTC
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.
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.
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.