[FSHero]

Dear everyone,

I was hoping to get back into Freespace 2 after the release of the voice-acted Blue Planet recently. As I use Linux as my primary OS, and with recent successes involving Doom 3, Epistory (indie game) and Tie Fighter CD in DosBox (which I do appreciate are very different from each other), I was hoping to 'win' with Freespace 2.

In Windows 10, with up-to-date drivers, I have reasonable performance. In the first mission of the main FS2 campaign (Surrender, Belisarius), when the GVD Hatshepsut enters, the framerate drops to about 17-18/second, but it looks well-textured and bump-mapped. Also, when I fire guns along side it, it glows as expected.

However, in Linux (see below for information), in the same mission, the Hatshepsut looks rather plain. The FPS drops rather more dramatically -- 5-6/second.

I have tried some 'do-it-yourself' solutions, but nothing has worked.

Due to having a combined Intel + AMD hybrid graphics, I tried the switch as detailed here. This does not improve the framerate nor the graphical appearances of the models, but does introduce a weird 'tearing' artefact moving from the top-right to the bottom-left of the screen. (I am unable to reproduce this in screenshots.)

Not specifying any graphics enhancement-related switches on the command line, and using the "-no_glsl" switch restores the adequate framerate when looking at models like the GVD Hatshepsut.

I did run a debug build (in both Windows 10 and Linux), which might lead to some useful information -- however at this point it is worth mentioning that  can get into the flight-sim in Windows, but not Linux, when using the debug build. (In Linux I cannot even get into the tech-room to replay a mission or view ship models. I can get into the current mission briefing, however.) This includes when all graphical addons are omitted and with the "-no_glsl" switch.

Here are some lines that are present in the Linux fs2_open.log that are different from the Windows one:

Linux:

Code: [Select]

  OpenGL Vendor    : X.Org
  OpenGL Renderer  : Gallium 0.4 on AMD OLAND (DRM 2.43.0 / 4.4.0-62-generic, LLVM 3.8.0)
  OpenGL Version   : 3.0 Mesa 12.0.6 
Windows:

Code: [Select]

  OpenGL Vendor    : ATI Technologies Inc.
  OpenGL Renderer  : AMD Radeon R7 M265 Series
  OpenGL Version   : 4.5.13464 Compatibility Profile Context 21.19.407.0 
Linux:

Code: [Select]

  Unable to find extension "GL_EXT_geometry_shader4".(reads "Using extension" in Windows)

Linux:

Code: [Select]

  Found special extension function "glXSwapIntervalSGI".(Reads "wglSwapIntervalEXT" in Linux)

Linux:

Code: [Select]

Why are you trying to free a NULL pointer?  [fsmemory.cpp(23)](Only appears when using the "DRI_PRIME=1" prefix on the command line)

Linux:

Code: [Select]

Vertex shader failed to compile:
0:7(12): warning: extension `GL_EXT_gpu_shader4' unsupported in vertex shader
0:11(1): error: syntax error, unexpected NEW_IDENTIFIER, expecting $end


ERROR! Unable to create vertex shader!There are a few of "unable to create vertex shader" messages, all with varying lines preceding.

Linux:

Code: [Select]

  OpenGL Shader Version: 1.30(Reads 4.50 in Windows)

Those appear to be the most pertinent lines. Now, I do not claim to have a lot of technical knowledge, but I believe that the following conclusions may be drawn:

- The OpenGL shader version in Linux appears to be lower than that in Windows despite the same hardware installed.
- There seems to be very many instances where the FS2 Open engine is unable to create vertex shaders.
- These errors could lead to a lack of graphical features in Linux, and perhaps also explain the much-impacted framerate.

Assuming this could be a driver problem, I was hoping to install proprietary AMD drivers and try the game with them... except for that they are no longer provided for Ubuntu 16.04 and beyond.

I suppose my questions are:

- Why do other games (see top of post) seem to run fine in Linux, but FS2 Open is struggling?
- Is this a driver problem?
- If so, should I use a newer version of (K)ubuntu (e.g. wait for 17.04) and try to play FS2 Open from there, given that they may include updated drivers?
- Should I bite the bullet and just play the game on a desktop PC, given that even in Windows there is a big performance hit in some parts of the game?
- Why can I not enter the flight simulator in the DEBUG version of the Linux executable? (Will compiling the executable from the source code increase the probability that it would work?)

Thanks for all who read this, and especially to those who reply. I recognise that we Linux gamers form a minority of the user base, but it would go a long way in helping us, as well as bolstering the reputation of the FS2 Source Code Project as the most awesome in the world.

P.S. I may be able to shed some more light on the issue later in the week - I do have a desktop computer which I have recently set up a dual-boot on. It is old (2008) but when I used to run mediavps_3612 and fs2_open 3.6.14, the performance was much better. (Should I prepare myself for an unpleasant surprise? )

APPENDIX:
Hardware info:
CPU: Intel Core i7-5500U @ 2.4 GHz
Graphics - 1: Intel(R) HD Graphics 5500 (Broadwell GT2)
Graphics - 2: AMD Radeon R7 M265

Operating systems:
    Windows: Windows 10 64-bit
    Linux: Kubuntu 16.04.1 amd64 (kernel 4.4.0-62-generic)
FS2Open version: 3.7.4 final
    Windows: SSE2 version
    Linux: 3.7.4 pre-compiled for Ubuntu 32-bit 14.04.4
Driver versions:
    Windows: AMD radeon software Crimson 16.12.2
    Linux: ??? (how do I find out?)


ATTACHMENTS:
lspci.txt -- output of "sudo lspci --verbose" in my Linux installation
2017-02-19_2229_fs2_open.log - FS2 Open DEBUG run in Windows 10
fs2_open_ubuntu_ctd_2249.log - FS2 Open DEBUG run in Kubuntu 16.04 (uses Intel graphics card)
fs2_open_ubuntu_ctd_2318.log - FS2 Open DEBUG run in Kubuntu 16.04 with prefix "DRI_PRIME=1" to force usage of the AMD Radeon graphics card.

[attachment stolen by Russian hackers]

[tomimaki]

Try recent nightly for better experience on linux.

[Phantom Hoover]

So just skimming your post I see the following words:

"AMD"

"Linux"

AMD's driver support on Linux is pretty crappy. While this might improve significantly in the near future, I suggest you just play on Windows for now.

[FrikgFeek]

Freespace 2 uses OpenGL, that's why it performs worse on AMD hardware than other games. AMD's openGL drivers are bad and their Linux drivers are even worse. Combine the 2 with really underpowered hardware and you get terrible performance.

[m!m]

So just skimming your post I see the following words:

"AMD"

"Linux"

AMD's driver support on Linux is pretty crappy. While this might improve significantly in the near future, I suggest you just play on Windows for now.

That is generally false. I am on Linux with an RX 480 and the support of the open source drivers is great.

Try recent nightly for better experience on linux.

That is the correct solution. FSO 3.7.4 was still using the OpenGL compatibility profile and combined that with advanced OpenGL features which was is supported by the Mesa drivers. This was fixed by Swifty by using an OpenGL Core profile which has much better support on the Mesa drivers (I have support for OpenGL 4.1 but only because I have slightly outdated software, the most recent Mesa version supports OpenGL 4.5).

TL;DR: Use a recent nightly build.

[Phantom Hoover]

That is generally false. I am on Linux with an RX 480 and the support of the open source drivers is great.

Performance-wise it's definitely true. Benchmarks on Windows consistently show the RX 480 neck and neck with the GTX 1060, but on Linux it falls significantly behind.

[m!m]

Yes, performance isn't great but FSO is definitely playable. I though you meant general support instead of just performance.

[Phantom Hoover]

This guy's problem is, as I understand, that his laptop runs FSO reasonably well on Windows but terribly on Linux. So I'm guessing it's down to the driver situation.

[m!m]

No, it's because FSO 3.7.4 on the Mesa drivers tries to run with shaders which fail to compile and then cause a ton of errors. I know the situation, I have been in it myself.

[AdmiralRalwood]

Yeah, the real problem here is definitely trying to use mesa drivers with FSO 3.7.4 without -no_glsl. If you want shaders and decent performance, use a recent nightly build.

[FSHero]

So just skimming your post I see the following words:

"AMD"

"Linux"

AMD's driver support on Linux is pretty crappy. While this might improve significantly in the near future, I suggest you just play on Windows for now.

Oh dear, perhaps a good excuse to buy a new (desktop) PC then! 

Try recent nightly for better experience on linux.

That is the correct solution. FSO 3.7.4 was still using the OpenGL compatibility profile and combined that with advanced OpenGL features which was is supported by the Mesa drivers. This was fixed by Swifty by using an OpenGL Core profile which has much better support on the Mesa drivers (I have support for OpenGL 4.1 but only because I have slightly outdated software, the most recent Mesa version supports OpenGL 4.5).

TL;DR: Use a recent nightly build.

Thanks for the tip; I will try one of the nightly builds

This guy's problem is, as I understand, that his laptop runs FSO reasonably well on Windows but terribly on Linux. So I'm guessing it's down to the driver situation.

I think "reasonably" is stretching it, but I could probably lower the resolution and omit some graphical switches to improve the performance. Yes the performance on Linux is indeed terrible.

Thanks for the tips everyone; I will report back once I have tried the nightlies. I didn't have time this week to unpack my (old) desktop PC, so I'll have to leave the comparison for another time.