Civilization: Beyond Earth Overcoming Linux GPU Driver Problems

[Commander]

2 things:

First: What's the difference between this game and Pandora by Slitherine? Except that Pandora is available now, looks better and runs on Linux without a hitch?

Second: The next person to say that Nvidia drivers on Linux are better than AMD drivers will get all my accumulated hate on Nvidia for FREE. Seriously, their drivers aren't even installable without taking half the system apart (you've to kill your X server to install it. Wtf? Why? Oh, right...Nvidia). Their error messages are basically 'this does not work. Why? Fuck you, that's why!'. And getting 3D performance out of an older card is impossible (hello nouveau...).

Nothing better than AMD. Runs instantly (thanks Mesa/Radeon) and if you ever need Catalyst...well just download and install it. It even has a graphical user interface. THAT'S RIGHT NVIDIA, AMD IS ABLE TO INSTALL THEIR DRIVERS WITH A RUNNING XSERVER.

Oh and don't get me started on that bumblebee bullshit. Does that work for anyone? Yeah, didn't think so.

Fuck you, nvidia. Just, fuck you.

I thought this was Linux, in other words, use the package manager to install the drivers not some odd executable from a website.

"and if you ever need Catalyst" translates to if you ever want somewhat near performance to what the card actually should have (stated OpenGL coverege and 3D performance) but then you suddenly experience the meaning fglrx "Catalyst" that in urban dictionary should have the definition of bugs. That still cannot display the mouse properly on multi-monitor desktops without getting corrupted or random Xorg infinite hangs because I started a game in Wine. Always behind Xorg and Kernel updates and half-assed OpenGL support even when it should work

Think i manage to restart X when using their installer or why not doing it the propper way. using the package manager to download and install it properly.

For the past 1.5 years i had nVidia, X didnt crash once. FGLRX (Catalyst) could not score that for longer than 48Hours.

So in the end the saying still applies. Want performance go nVidia, want acceptable performance and OpenSource go AMD but don't buy lastgen because you gonna have a bad time.

Oh btw, bumblebee works perfectly fine on my Zenbook (UX32VD).

Cheer up and toodles!

[Ancurio]

Pretty sure they were talking about how each vendor implements OpenGL in different ways... different enough that sometimes the same set of functions on one vendor will output COMPLETELY different stuff than on another. Thus, OpenGL isn't really "portable", as even though you are writing in one API, you have to treat it as several different APIs. Having to write vendor-specific code with a "vendor-neutral API" is sad.

This is what is also in the software world commonly referred to as "bugs".

[kayosiii]

2 things:

First: What's the difference between this game and Pandora by Slitherine? Except that Pandora is available now, looks better and runs on Linux without a hitch?

Second: The next person to say that Nvidia drivers on Linux are better than AMD drivers will get all my accumulated hate on Nvidia for FREE. Seriously, their drivers aren't even installable without taking half the system apart (you've to kill your X server to install it. Wtf? Why? Oh, right...Nvidia). Their error messages are basically 'this does not work. Why? Fuck you, that's why!'. And getting 3D performance out of an older card is impossible (hello nouveau...).

Nothing better than AMD. Runs instantly (thanks Mesa/Radeon) and if you ever need Catalyst...well just download and install it. It even has a graphical user interface. THAT'S RIGHT NVIDIA, AMD IS ABLE TO INSTALL THEIR DRIVERS WITH A RUNNING XSERVER.

I am on Kubuntu and open Jockey, select nVidia drivers then restart has worked fine for me for years. I can see some validity to your point, but you can't pretend that it isn't a solved problem for the majority of Linux users. I don't have a lot of experience with older hardware but I was under the impression that nVidia drops cards from newer driver versions when the drivers have new features that require hardware that the cards just don't have. I was also under the impression that these old driver versions (the most recent versions supporting certain hardware) are kept up with kernel and X updates - at least much better than ATI is.

As I see it the situation with nVidia is things are not perfect, but the drivers are production ready for graphical workstation / gaming desktop requirements. This is something that can't be said for AMD currently, though the situation is improving.

[benmoran]

For the past 1.5 years i had nVidia, X didnt crash once. FGLRX (Catalyst) could not score that for longer than 48Hours.

I'm not directing this solely at you, but:
Just wanted to add that I'm "lucky" enough to have an Nvidia card in my work machine, and the proprietary driver crashed X about twice a week, like clockwork. It annoyed me to the point that I switched back to the integrated Intel graphics for a time, but Nouveau has thankfully improved enough since then to be a pleasant stable experience.

Kudos to the Nouveau team for making my card usable. The Nvidia binary drivers tend to be good but if they don't work, you're pretty much screwed if not for Nouveau. My laptop and personal desktop both have APUs, both use the Radeon driver, and both run Civilization 5 perfectly. (I'm not holding out much hope for my laptop running this new one though )

[ObiWan]

OpenGL problem with AMD [s]on Linux[/s]?

Where did you read that in the blog?
The only mention of AMD cards is with a Mac screenshot...

[RealNC]

It's their own fault and lack of foresight. They should have used OpenGL to begin with. The port would have been much cheaper.

However, this game also supports AMD Mantle. Wasn't Mantle released for Linux already?

[emblemparade]

P.S. this is where I point out that I'm talking out of my ass and going off of what I've heard from the people around me (people who love OpenGL even). I don't personally partake in the use of graphics APIs.

Don't worry, there's a proud tradition of talking out of your ass on Phoronix forums.

I am an experienced dev, so let me give you my take on the API issue.

Yes, Direct3D is significantly easier to work with with than OpenGL/ES: more coherent API and better tools (some would say much better). Various historical reasons for this, but the most important one is that D3D has never been collaborative: MS could always control the spec, which made it straightforward. Meanwhile, OpenGL is made up out of a lot of extensions, which according to spec may or may not be available on any particular device. This is a nightmare for programmers, because it means you have to test for the availability of certain features and then decide what to do if they are not available. This could mean coding two, three or even more versions of each particular workflow, and of course having to test and maintain each. At some point you may want to throw your hands up in despair and just target the lowest common denominator, which means you will not be able to leverage advanced features.

But, despite those advantages, OpenGL is a much better choice than Direct3D. It's not easily portable, but it really is portable. The bottom line is that it works. My from-scratch game engine runs on Linux/X11/Wayland/Mir, Windows, Android and OS X (working on an iOS port now, should not be too hard). Where certain features are unavailable, I implement reasonable fallbacks. And of course console ports would also be possible in the future. Direct3D will not let me do all that (or it will, but with unacceptable performance costs).

Lots of things in programming are hard. But the nice thing is that once you solve a problem, it is pretty much solved. It might be harder to make a game engine on top of OpenGL/ES, but once you solve all the issues, you have true cross platform support. That, to me, is worth the effort: reach more gamers on more platforms, including better "future-proofing" for porting your games to the devices of the future.

Furthermore, many games do not require a custom engine. A dev might as well use a ready-made engine that already solves all these problems. Use Ogre3D for free, or go for Unity3D, Unreal, etc. If you're using an engine, it matters much less if underneath it uses OpenGL, D3D, or both. Most of that has been abstracted away.

It was not a good choice of Civ to use Direct3D, but I guess it's an old decision that the dev team is now stuck with. Which is why they now have to wrestle with a slow D3D9/GL translation layer. But, well, let's be honest: the series has never excelled in computing efficiency, even on Windows. The system requirements since Civ 4 have been far higher than a game like this should require. Civ always takes up huge amounts of hard disk space, eats up RAM like crazy, is a CPU/GPU hog, and yet still manages to be slow! That said, quality control is excellent, and if you do meet the requirements, the games do run smoothly enough. I'm a huge Civ fan and very excited to play Beyond Earth on Linux.

[smitty3268]

It was not a good choice of Civ to use Direct3D, but I guess it's an old decision that the dev team is now stuck with.

It's been mentioned a couple of times that these devs should have done Civ in OpenGL from the start, but just to make sure everyone is clear: Aspyr is not the original devs. They are a 3rd party porting company. They have no say whatsoever in how the original game is developed, they just get to make some money from porting it.

If you read the blog post, it's pretty clear that this is the first time they've ported a post-DX9 game to OpenGL, and going from DX9 => DX10+ was a major change. That's why it's taking them some time to figure everything out, since it's the first time they've done anything with DX11, or the equivalent advanced GL APIs. Once they port this game, future titles will no doubt be easier based on what they learn here. It's not like they're whining about it - they're just sharing how things are going for anyone interested.

[smitty3268]

Oh, and i doubt it takes that long before the Mesa drivers run it

They are porting the game to OSX as well, and the OpenGL drivers Apple ships aren't that much more advanced than the ones in Mesa now.

Mesa doesn't have to match the proprietary NVidia drivers in order to gain widespread support for advanced new games - they just have to be as good as the one's Apple provides.

[emblemparade]

Another point about APIs:

Advanced versions of APIs (D3D11, OpenGL 4) are more about making it easier for the devs than offering a better experience to users (though you can argue that the former indirectly leads to the latter). In many games that allow D3D9 vs DRD11 support, for example, there is little noticeable difference in the game experience. It's somewhat disingenous when MS touts a newer version of D3D as being better for gamers. Well, it will allow you to run newer games that don't support older versions, that's true, but it's a matter of how much the devs are willing to support an older API.

Most of the features in the newer APIs are available in the older ones, with some extra work: this is especially true for OpenGL, where the way the process works is that what used to be an extension gets moved into the core in the new version. In almost all cases, you can implement the same feature with an older API, with some work.

I keep emphasizing "most", because there are of course some new features. But lately, especially, there has been an emphasis on features that allow much more efficient non-blocking "streaming" of data to GPU memory. When used correctly (it can be tricky; the APIs are a bit awkward), this can significantly improve performance, unleashing more throughput potential out of high-end GPUs. Both D3D11 and recent versions of OpenGL have it.

The awkwardness of these new APIs is due to the way objects has been handled until now -- we would make our objects in CPU RAM and then hand them over to the GPU. It was fine in the past, but now we are dealing with so much more data, and also doing more general (OpenCL) work on the GPU, so this passing-between ends up being the #1 bottleneck. (Also creates many complications for multi-core CPUs.) This is one of the reasons that we need to start afresh with a new post-OpenGL API: we need to change this fundamental working concept, which will really change everything, so much so that it would not make much sense to call it "OpenGL" anymore.