Civilization: Beyond Earth Likely To Drop Intel/AMD Linux Support

[iv841]

Catalyst/fglrx has OpenGL 4.4 supported on Linux/Windows.

Well, if it is actually usable, games might just as well start to take advanatge now ?

[iv841]

Yes we care about compatibility and Nvidia with their loose implementation is breaking that.
Working on Nvidias driver != working on OpenGL driver (be it from Nvidia, Intel, AMD, Mesa, Apple ...).

I find Nvidias driver to have been unusable for me (not using it now so cant comment) :
- problematic settings of multimonitor that needed changes to xorg.conf
- was not working alongside oss intel and amd driver
- security problems
- video tearing
- problems with vga-passthrough for use in VM

Your anecdotes do not match mine, since I have used the Nvidia driver for more than a decade, and never had major problems. On the other hand, the one AMD GPU I have in a laptop was bad enough on Linux that I ended up having to use Windows on that machine. According to the GamingOnLinux survey that shows greater Nvidia percentage on Linux than is typical on other platforms, I might not be alone with my experiences.

Also, the only time I have seen video tearing with vsync enabled was with poorly written compositors, which I usually disable as soon as possible anyway.

[log0]

I have never claimed that the Nvidia driver should not be used for development, that is something you have invented. What I meant is that it (or any other specific driver, including Mesa) should not be used as a conformance testing tool, as in the fact that a particular piece of code happens to work on a particular driver does not by itself guarantee it does not depend on undefined behavior. Regardless of the driver, the code can always be written to the standard, and verified with whatever tools are available. If the tools are lacking, that is not the driaver's fault.

My guess is that you are not a software developer. Am I right?

For those who want more than OpenGL 3.3 (and it is not like 4.0 is not almost 5 years old by now), Mesa is not sufficient, and missing major parts of the standard limits the usefulness of its "conformance". It also does not in fact guarantee conformance, since its developers have already fixed (by including compatibility hacks) games that previously failed to work with the open source drivers, allegedly because they use the OpenGL API in "broken" ways. So, Mesa does indeed sacrifice conformance for compatibility, it just does not achieve the same level of compatibility as the proprietary drivers. And of course it is no wonder it is difficult to find Mesa-only code, because no one would want to lock out about 80% of potential users

Mesa actually supports OpenGL 4+ to a large degree, with a few extensions missing for full compliance. And yes it has to implement hacks to mimic noncompliant behavior of blob drivers. A number of them can (has to) be enabled at runtime. This still doesn't invalidate my statement, that it is the most compliant of the bunch.

[iv841]

I'm not sure why you mention it, but OpenGL 4.5 is irrelevant for this discussion.
They could release a working port for everyone, just follow the specs and stop trial & error.

If they just followed the specs, that would imply not making compromises for the limitations of drivers that are used by a minority anyway. And the OpenGL version used is relevant as long as it affects the quality of the port in some way, be it features or performance.

[pixo]

Your anecdotes do not match mine, since I have used the Nvidia driver for more than a decade, and never had major problems. On the other hand, the one AMD GPU I have in a laptop was bad enough on Linux that I ended up having to use Windows on that machine. According to the GamingOnLinux survey that shows greater Nvidia percentage on Linux than is typical on other platforms, I might not be alone with my experiences.

Also, the only time I have seen video tearing with vsync enabled was with poorly written compositors, which I usually disable as soon as possible anyway.

Unfortunately they are not anecdotes.

http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg00319.html

http://permalink.gmane.org/gmane.comp.security.full-disclosure/86747

http://wiki.xen.org/wiki/Xen_VGA_Passthrough "Some Nvidia adapters require additional/extra vBAR=pBAR patches to make them work."

https://wiki.archlinux.org/index.php/NVIDIA#Black_screen_on_systems_with_Intel_integrated_GPU

https://devtalk.nvidia.com/default/topic/543305/linux/screen-video-tearing-gtx6xx-7xx-kepler-9xx-maxwell-in-almost-all-applications-including-desktop/3/

[iv841]

My guess is that you are not a software developer. Am I right?

My guess is that it is none of your business who I am, nor is it relevant to the discussion.

Mesa actually supports OpenGL 4+ to a large degree, with a few extensions missing for full compliance.

Given that the "few extensions" that are missing include some major ones, it is enough to limit the usefulness of the support. Commercial developers also tend to prefer not depending on partial implementations. For comparison, Wine claims to have implemented about 80% of Direct3D 10, it just happens that the missing 20% prevents most games from working.

This still doesn't invalidate my statement, that it is the most compliant of the bunch.

Regardless of whether your statement is valid (it could only be objectively verified by intentionally writing many test cases of non-compliant code, and counting which driver correctly rejects the highest percentage of the tests), the fact remains that the OpenGL implementation provided by Mesa is incomplete and not up to date. Therefore it cannot be proclaimed as some kind of "official" reference driver, like many are trying to. It is already not 100% compliant with what it does support either, which does invalidate the approach of "write for Mesa only, forget the rest".

[iv841]

Unfortunately they are not anecdotes.

They still are because of the small numbers (=lack of statistical significance), and because no comparable effort was spent on finding similar links for AMD related problems (=bias).

[ningo]

How about Russ Looney files a bug report against the driver instead of blogging?

[Remdul]

IMO the developer may be better off not supporting Linux at all under these circumstances. Not every customer knows their machine hardware (nor should one these days). Sure it may have an Intel sticker on it, but doesn't it also have an Intel or AMD or NV GPU? And if it has one, does it even work, or fall back to Intel build-in?
Some systems have both Intel GPU AND a second high powered GPU. On my dual GPU laptop some Windows/Linux (Wine + Bumblebee) games/applications only detect the Intel GPU, then crash due to GPU mixup, or downgrade graphics to conform Intel standards, even though stuff is being rendered on the NV GPU. Others run fine at great perf. But what a mess!

If you are a developer and can't make your OpenGL graphics cross-vendor, let alone cross-platform, you're doing something wrong. I know about GL extension hell (aaargh!), but graceful fall back is just part of the job. Don't support Linux/GL if you're not fully committed. Like this, even if 'NV-only' may break when NV screw up a driver update.

GL is cross-platform and cross-vendor, and while some implementations may suck or lag behind, it is a very good design principle to make it work on all the same. It helps you narrow down application performance bottlenecks, pinpoint bugs etc. etc.

[Xaero_Vincent]

It doesn't seem unusual that proprietary game developers will base their code on proprietary OpenGL implementation in the graphics drivers. As far as proprietary drivers go, Nvidia wins hands down on Linux. Fglrx is still a mess but is improving and hopefully will improve alot with with the hybrid FOSS/proprietary 'amdgpu' driver for future AMD GPUs. The FOSS Intel and AMD stacks are pretty good but only upto OpenGL 3.3. I mean, only very recently has the FOSS stack been able to support a OpenGL 3 games like The Witcher 2 reliably, which I just installed yesterday.

Only the proprietary drivers have full OpenGL 4.x support at the moment and this game requires DirectX 11, which only OpenGL 4.x can compare to. Although the DirectX 11 driver may expose Direct3D 10.x functions to the the minimum supported graphics cards of the game.

It may just be a matter that this Civilization game is "too much" for the current state of FOSS Intel and AMD stack and that the Fglrx is too buggy. I imagine we'll see support arrive in Mesa-git and git versions of the AMD and Intel driver relatively soon after release.

I think the proper solutions would be for a dialog box to appear at game launch when Intel or AMD hardware is detected:

.................................................. ............* Warning *
-----------------------------------------------------------------------------------------------------------------------------
This game requires an Nvidia graphics adapter with the genuine Nvidia Accelerated Graphics Driver to function.
....Intel and AMD Radeon graphics are currently not supported and game may not function correctly or at all.

.......................................Would you like to launch the game anyway?

.................................................. ___..................______
.................................................| Yes|.................|Cancel|
..................................................-----...................--------
-----------------------------------------------------------------------------------------------------------------------------