Linux support thread

Ask here if you experience technical problems with X Rebirth.

Moderator: Moderators for English X Forum

Post Reply
User avatar
daret
Posts: 6
Joined: Mon, 30. Nov 15, 11:14
x4

Post by daret » Mon, 7. Mar 16, 11:14

jeckhack wrote:Hi! First of all, thanks for 4.0 for linux. I've been waiting it since 2013, and it's great port.

But i have some strange problem since 4.0 beta (that was not the case in 3.61). When i start campaign and get to the Auspicious excavation for the first time to meet Borman's thip, when I enter the system there occurs some weird stuttering and fps drop, which persists no matter what I do. Flying to other systems, reload save doesn't help. Game just becomes jerky, like there's not enough ram. But I checked, and game uses just around 3GB of 12. CHanging graphics options has no effect. CPU load in this case no more than 50-55% on all cores, so it's not cpu bottleneck.

Specs: I3 4130, gtx 960, 12gb ram.
Otherwise, in Free Play, i maintain stable 45-60fps , completely smooth, with no hiccups or else. This problem appeared only since latest betas of 4.0 and on linux only.
Is this a known problem on linux version ?
Thanks

PS. I suspect that for in that area may cause this. I have stuttering even when in highway and Auspicious excavation system starts rendering far away.

P.P.s. Latest drivers, clean system, Openbox with no composite manager.
I got the same FPS drop an shuttering.
Almost the same configuration:
- GTX 960 4G with new 361 drivers
- AMD FX-6200
- 8GB RAM
- Openbox

timon37
EGOSOFT
EGOSOFT
Posts: 485
Joined: Fri, 14. Dec 12, 11:02
x4

Post by timon37 » Mon, 7. Mar 16, 12:56

Caldazar wrote:Once I tried to set AA to 32.
Hmm, maybe you ran out of gpu memory? You can check with nvidia-smi, though probably not the case.
In general 16/32 on nvidia is really heavy even on high-end gpus, and it blurs the scene, so personally I don't suggest using it.
Caldazar wrote:I've come across some rendering glitches and bugs. I can't make a proper report yet, but Yisha looks especially strange. Maybe it's the shadows? Not sure.
Is the OpenGL render (theoretically) on par with the DirectX one, as far as graphic
Sometimes things do look a bit weird (also in dx9), in general it should look the same, although I recently found two more differences.
Best situation for me is if you can compare to dx9, if not just make a screenshots & savegames and post in the bugtracker (search first of course since some things are posted already).
Caldazar wrote: I want an ingame FPS counter [..] How can I do it?
Every time I launch XR, it creates a folder "GOG_Games?Rebirth" with a few subfolders in my home directory. The main problem is that this folder messes with bash autocompletion. Why is it there? What does it do? How can I get rid of it?
-showfps should work I'm guessing start.sh just doesn't pass it to the game, you could try carefully editing it.
Unfortunately the GOG team handles their packaging and I didn't see or test it, do they have some game specific forums?
I would appreciate it if you can ping them about these two issues. I'll also try to contact them when I've got a moment.


@sirdeiu & kerberizer
Hmm, the game generally doesn't ever wait for assets/shaders, if something isn't loaded it just doesn't get rendered.
However currently "loaded" means the right opengl commands have been issued, so I guess depending on how the driver handles stuff it could still cause stuttering.
Anyway I'd like both of you to test something, when these happen does the hardware cursor also freeze? You can try in windowed and without locking the ship-steering.
I recently noticed an issue with minecraft at home where I get similar stutter every once in a while, and it actually blocks the whole Xorg server for a second or two (I'm on pretty new mesa of course).

@aspbazi
You mean the in-game setting doesn't affect the deadzone?

Caldazar
Posts: 326
Joined: Sun, 21. Sep 03, 20:21
x3tc

Post by Caldazar » Mon, 7. Mar 16, 14:57

timon37 wrote:-showfps should work I'm guessing start.sh just doesn't pass it to the game, you could try carefully editing it.
Your guess is correct. The script is very short so modifying it shouldn't be too difficult.
timon37 wrote:Unfortunately the GOG team handles their packaging and I didn't see or test it, do they have some game specific forums?
I would appreciate it if you can ping them about these two issues. I'll also try to contact them when I've got a moment.
I will but it might take a few days to get to it.

User avatar
kerberizer
Posts: 8
Joined: Sat, 19. Apr 14, 17:21
x4

Post by kerberizer » Tue, 8. Mar 16, 02:12

timon37 wrote:Hmm, the game generally doesn't ever wait for assets/shaders, if something isn't loaded it just doesn't get rendered.
However currently "loaded" means the right opengl commands have been issued, so I guess depending on how the driver handles stuff it could still cause stuttering.
Anyway I'd like both of you to test something, when these happen does the hardware cursor also freeze? You can try in windowed and without locking the ship-steering.
I recently noticed an issue with minecraft at home where I get similar stutter every once in a while, and it actually blocks the whole Xorg server for a second or two (I'm on pretty new mesa of course).
I need to test more, but here are some initial observations:

1) The issue is noticeably less frequent since the 4.0 update. In fact, it's now difficult to cleanly reproduce it: not that it happens that much less frequently, but rather the freeze durations are shorter. The only place where it seems to manifest reliably and for long enough seems to be the gate from "Sol Gate" in Toride to HoL.

2) It doesn't freeze the cursor or X in general. Quite the opposite: all radeontop counters (except for VRAM of course) drop to zero, so it rather looks that the game gets busy and can't push data to the driver subsystem fast enough. This is something that I forgot to mention in my first comment: I had noticed the same thing before too.

3) The GPU load drop is definitely inversely correlated with the activity of the "Asset Enabling" thread. In the now rare cases of stalls that are long enough (seconds) to be clearly observed, the GPU load drops to clean zero, while the "Asset Enabling" thread rises to 100% CPU utilization. Most of the time, they fluctuate of course, but to the naked eye it seems that it's indeed that thread that causes at least some of the lack of smoothness (it's clearly distinct from other cases of slowdowns, when e.g. the GPU pipeline gets to 100% load obviously because of too much work it has to do itself). Let me say again that these problems are mostly pronounced on the highways (and that gate I mentioned earlier -- probably others too, but haven't yet tested). In 4.0 they seem to be virtually nonexistent in the normal space (and on stations).

4) I tried to strace that thread to see what causes the spikes in its work, but so far couldn't get a clean picture. I do have a suspicion that the thread might be excessively waiting on the mmap() calls, but that really needs more investigation. However, if that turns out to be true, I wonder if it wouldn't be connected to the fact that I use ZFS. ZFS's ARC is not unknown to cause problems with memory allocation in specific situations with sudden spikes of memory pressure when it simply cannot free allocated memory fast enough. One thing that I'll have to try is restricting its size to a rather more conservative value than the default in order to eliminate possible interference from it.
sirdeiu wrote:@kerberizer It seems we are on to something here regarding the shader cache, a user on phoronix forums reports things improved:
(...)
See here: http://www.phoronix.com/forums/forum/li ... post853957

So now, I guess we need to wait for mesa to 11.2 with this feature.
It definitely looks promising! Unfortunately, I'm still stuck on Mesa commit 3c9ed20 (right before those changes), because of the GPU faults, and I still can't find time to properly bisect it to see if I can find the actual reason for the faults (I'm somewhat surprised that seemingly nobody else has complained, so it might be something specific to my particular setup).

User avatar
kerberizer
Posts: 8
Joined: Sat, 19. Apr 14, 17:21
x4

Post by kerberizer » Tue, 8. Mar 16, 02:38

@timon37, on a side note, while testing I noticed also this broken texture (?) in The Fallen Kingdom (and adjacent areas). I'm almost sure someone did already report it earlier, but couldn't find the report here or on the bug tracker (might've missed it, sorry). Of course, it's just a minor cosmetic glitch.

User avatar
aspbazi
Posts: 11
Joined: Sat, 7. Nov 09, 01:18
x4

Post by aspbazi » Thu, 10. Mar 16, 00:02

"You mean the in-game setting doesn't affect the deadzone?"

Yes. Not working.
IT-Service «Crimea-Karro» .

sirdeiu
Posts: 11
Joined: Fri, 9. Aug 13, 13:12
x4

Post by sirdeiu » Fri, 11. Mar 16, 06:13

timon37 wrote: @sirdeiu & kerberizer
Hmm, the game generally doesn't ever wait for assets/shaders, if something isn't loaded it just doesn't get rendered.
However currently "loaded" means the right opengl commands have been issued, so I guess depending on how the driver handles stuff it could still cause stuttering.
Anyway I'd like both of you to test something, when these happen does the hardware cursor also freeze? You can try in windowed and without locking the ship-steering.
I recently noticed an issue with minecraft at home where I get similar stutter every once in a while, and it actually blocks the whole Xorg server for a second or two (I'm on pretty new mesa of course).
Hi again,

So trying what you suggested, in windowed, the X server is not freezing and neither is the hardware mouse cursor.

Only XRebirth freezes, especially when flying in highways, sometimes less than a sec, sometimes more than a few seconds.

Also, it still happens even with the mesa shader thing added. I'm using Fedora 23 with griever/mesa-git copr repo.
mesa-libEGL-11.3.0-0.devel.6.90f9df3.fc23.i686
mesa-libglapi-11.3.0-0.devel.6.90f9df3.fc23.x86_64
mesa-libwayland-egl-11.3.0-0.devel.6.90f9df3.fc23.i686
mesa-libEGL-11.3.0-0.devel.6.90f9df3.fc23.x86_64
mesa-libglapi-11.3.0-0.devel.6.90f9df3.fc23.i686
mesa-libGL-11.3.0-0.devel.6.90f9df3.fc23.x86_64
mesa-libEGL-devel-11.3.0-0.devel.6.90f9df3.fc23.x86_64
mesa-filesystem-11.3.0-0.devel.6.90f9df3.fc23.i686
mesa-libwayland-egl-11.3.0-0.devel.6.90f9df3.fc23.x86_64
mesa-libgbm-11.3.0-0.devel.6.90f9df3.fc23.i686
mesa-dri-drivers-11.3.0-0.devel.6.90f9df3.fc23.i686
mesa-libGLU-9.0.0-9.fc23.x86_64
mesa-libgbm-11.3.0-0.devel.6.90f9df3.fc23.x86_64
mesa-libGL-devel-11.3.0-0.devel.6.90f9df3.fc23.x86_64
mesa-filesystem-11.3.0-0.devel.6.90f9df3.fc23.x86_64
mesa-libGLU-9.0.0-9.fc23.i686
mesa-dri-drivers-11.3.0-0.devel.6.90f9df3.fc23.x86_64
mesa-libxatracker-11.3.0-0.devel.6.90f9df3.fc23.x86_64
mesa-libGL-11.3.0-0.devel.6.90f9df3.fc23.i686

User avatar
kerberizer
Posts: 8
Joined: Sat, 19. Apr 14, 17:21
x4

Post by kerberizer » Fri, 11. Mar 16, 14:06

sirdeiu wrote:So trying what you suggested, in windowed, the X server is not freezing and neither is the hardware mouse cursor.

Only XRebirth freezes, especially when flying in highways, sometimes less than a sec, sometimes more than a few seconds.

Also, it still happens even with the mesa shader thing added. I'm using Fedora 23 with griever/mesa-git copr repo.
Do you happen to use ZFS?

User avatar
daret
Posts: 6
Joined: Mon, 30. Nov 15, 11:14
x4

Post by daret » Fri, 11. Mar 16, 14:45

Q1:
According to system requirements X Rebirth needs min. 8GB RAM, recommended is 12GB.
When I run the game (campaign), it uses only 2.5GB RAM the whole time.
Why?

Q2:
Performance on my system is low (20 FPS), no mater what Graphic settings I use (Ultra or low). In "Auspicious Excavation" the CPU utilization is high - one core is sometimes 100%, FPS is 15-20.
In "Frozen Circuit" the CPU utilization is lower - all cores less the 60-80%, FPS is better around 30 (vsync off), but there is some sort of shutter (less with vsync on).
Platform performance is always low 20-30 FPS.
Is CPU the problem? Is AMD FX6200 not enough? What AMD CPU should be suitable?

I installed X on SSD, but is makes no difference.

My system:
System: Kernel: 4.2.0-25-generic x86_64 (64 bit gcc: 4.8.2) Desktop: Openbox 3.5.2
Distro: Linux Mint 17.3 Rosa
Machine: Mobo: ASUSTeK model: M5A99X EVO R2.0 v: Rev 1.xx Bios: American Megatrends v: 2501 date: 04/03/2014
CPU: Hexa core AMD FX-6200 Six-Core (-MCP-) cache: 12288 KB
flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm) bmips: 45752
clock speeds: max: 3800 MHz 1: 1400 MHz 2: 3800 MHz 3: 3800 MHz 4: 1400 MHz 5: 3800 MHz 6: 3800 MHz
Memory: 16GB (4x4 GB) 1600MHz
Graphics: Card: NVIDIA GM206 [GeForce GTX 960] bus-ID: 01:00.0
Display Server: X.Org 1.15.1 drivers: nvidia (unloaded: fbdev,vesa,nouveau)
Resolution: 1920x1080@60.0hz
GLX Renderer: GeForce GTX 960/PCIe/SSE2 GLX Version: 4.5.0 NVIDIA 361.28 Direct Rendering: Yes

sirdeiu
Posts: 11
Joined: Fri, 9. Aug 13, 13:12
x4

Post by sirdeiu » Fri, 11. Mar 16, 21:02

kerberizer wrote:
sirdeiu wrote:So trying what you suggested, in windowed, the X server is not freezing and neither is the hardware mouse cursor.

Only XRebirth freezes, especially when flying in highways, sometimes less than a sec, sometimes more than a few seconds.

Also, it still happens even with the mesa shader thing added. I'm using Fedora 23 with griever/mesa-git copr repo.
Do you happen to use ZFS?
Nope, atm using btrfs (with compress=lzo).

User avatar
kerberizer
Posts: 8
Joined: Sat, 19. Apr 14, 17:21
x4

Post by kerberizer » Fri, 11. Mar 16, 21:40

sirdeiu wrote:
kerberizer wrote:
sirdeiu wrote:So trying what you suggested, in windowed, the X server is not freezing and neither is the hardware mouse cursor.

Only XRebirth freezes, especially when flying in highways, sometimes less than a sec, sometimes more than a few seconds.

Also, it still happens even with the mesa shader thing added. I'm using Fedora 23 with griever/mesa-git copr repo.
Do you happen to use ZFS?
Nope, atm using btrfs (with compress=lzo).
So, if we do encounter a common issue, it can't be caused by ZFS or Btrfs alone. It still could be filesystem related though, I guess: compression (I use lz4 in ZFS) or their very CoW nature. But that's probably too far fetched a suspicion: I suppose there are tens of possible causes for the issue that are much more likely than the filesystem. In any case, further testing is apparently warranted. I'll see if I can make more meaningful traces of that Asset Enabling thread which seems to be closely connected with the issue on my system.

sirdeiu
Posts: 11
Joined: Fri, 9. Aug 13, 13:12
x4

Post by sirdeiu » Sat, 12. Mar 16, 06:31

I don't think so, happened when using Fedora's default partitioning scheme also, which defaults to ext4.

Caldazar
Posts: 326
Joined: Sun, 21. Sep 03, 20:21
x3tc

Post by Caldazar » Sat, 12. Mar 16, 21:11

XR just crashed with a segfault. It happend while I was doing a mission to help a miner in distress in Toride. Not sure if it's reproducible from the last save, but here is the console log from before the crash:
======================================
[BuildControlTextureEntry::Update] Failed to set shader, probably due to async load, @Timon do we skip or do we sync?
======================================
Name shadergl\high_spec\copy compiled 1065
Name shadergl\high_spec\copy compiled 1068
Name shadergl\high_spec\copy compiled 1071
Name shadergl\high_spec\xu_shadowmap compiled 1074
Name shadergl\high_spec\xu_shadowmap compiled 1077
Name shadergl\high_spec\xu_shadowmap compiled 1080
Name shadergl\high_spec\xu_l_pass_spotlight compiled 1083
Name shadergl\high_spec\xu_l_pass_spotlight compiled 1086
Name shadergl\high_spec\xu_l_pass_spotlight compiled 1089
TextureD3D::BE_SetSize(ui\core\presentations\widget_detailmonitor\widget_detailmonitor_recovered\detail_monitor-rendertarget) 582 438
TextureD3D::BE_SetSize(ui\core\presentations\widget_detailmonitor\widget_detailmonitor_recovered\detail_monitor-rendertarget) 655 656
TextureD3D::BE_SetSize(ui\core\presentations\widget_detailmonitor\widget_detailmonitor_recovered\detail_monitor-rendertarget) 443 297
======================================
/(): GetComponentData(): Component 169211 does not exist any more
======================================
======================================
/(): IsInfoUnlockedForPlayer(): Component 169211 does not exist any more
======================================
======================================
/(): GetContextByClass(): Component 169211 does not exist any more
======================================
======================================
/(): GetModuleType(): Component 169211 does not exist any more
======================================
TextureD3D::BE_SetSize(ui\core\presentations\widget_detailmonitor\widget_detailmonitor_recovered\detail_monitor-rendertarget) 655 656
TextureD3D::BE_SetSize(ui\core\presentations\widget_detailmonitor\widget_detailmonitor_recovered\detail_monitor-rendertarget) 443 297
TextureD3D::BE_SetSize(ui\core\presentations\widget_detailmonitor\widget_detailmonitor_recovered\detail_monitor-rendertarget) 655 656
TextureD3D::BE_SetSize(ui\core\presentations\widget_detailmonitor\widget_detailmonitor_recovered\detail_monitor-rendertarget) 443 297
TextureD3D::BE_SetSize(ui\core\presentations\widget_detailmonitor\widget_detailmonitor_recovered\detail_monitor-rendertarget) 655 656
TextureD3D::BE_SetSize(ui\core\presentations\widget_detailmonitor\widget_detailmonitor_recovered\detail_monitor-rendertarget) 582 438
TextureD3D::BE_SetSize(ui\core\presentations\widget_detailmonitor\widget_detailmonitor_recovered\detail_monitor-rendertarget) 655 656
./testandlaunch: line 32: 9093 Segmentation fault ./$cmd "$@"

gilboa
Posts: 260
Joined: Sat, 28. Apr 07, 10:33
x4

Post by gilboa » Sat, 19. Mar 16, 09:55

gilboa wrote:Hello,

As I recently switched to a big-ass 4K display, I decided its time to ditch my X3:TC/AP XRM games and join the cool people @X:R :) *

However, not all is smooth sailing.
My X52 joystick that more or less worked out of the box in all the X series games (X2/linux, X3:R linux, X3TC/wine and X3AP/linux) doesn't really work under X:R.
1. The games seems to see 3-4 axies out of the joystick's 11. E.g. I cannot use any of the POV (either axis ones or "botton" ones) to strife, same goes for actual POVs.
2. Deadzone value seem to be ignored.

BTW, even on a lowly GF780 (non-TI) @4K on "high", performance seems to be acceptable. Kudos to the people involved in this Linux port!

Any help will be greatly appreciated.

- Gilboa
* Actually, being old with less-than-perfect eye sight, I need a telescope size magnifier glass to see the tiny fonts in X3AP, but lets leave it at that...
Short update.
Managed to get everything working.

Reset the custom profile.
Reloaded the "joystick" profile.
Lowered dead-zone to 5%.
Disable a roll and piloting assistance.
Joysticks now work as intended.

Though, somehow the joysticks are less fluid than under X3:TC/AP, but that's another issue.

Thanks
- Gilboa
X2 Linux (LGP).
Heavily modified X3:R Linux w/ XTM (LGP).
Heavily modified X3:TC w/ XRM (under wine).
Heavily modified X3:AP Linux w/ XRM.
Modified X4 Linux w/ VRO.
Machine: 2 x E5-2658V2, 32G, 8TB RAID10, 1080GTX, Dell UP3216Q 4K LCD.
OS: Fedora 33/x86_64.

Mahi Ma
Posts: 76
Joined: Mon, 16. Mar 15, 14:10
x4

Post by Mahi Ma » Sat, 26. Mar 16, 09:37

Still, i get horrible performance in Nebulas like Maelstrom/Sixth Scriputre.
TO is less worse but still ...

User avatar
ezra-r
Posts: 3420
Joined: Fri, 14. Oct 05, 21:04
x4

Post by ezra-r » Thu, 26. May 16, 20:54

Are we going to be stuck forever with that horrible noise for the long range scanner under Linux?

User avatar
kerberizer
Posts: 8
Joined: Sat, 19. Apr 14, 17:21
x4

Post by kerberizer » Thu, 26. May 16, 21:32

ezra-r wrote:Are we going to be stuck forever with that horrible noise for the long range scanner under Linux?
Indeed, why are some sounds different on Linux? It's not just the LR scanner. For example, the "wind" sound when the ship is moving is very muted compared to Windows. The next might be a subjective feeling, but to me the weapons also seem to lack "depth" (bass, reverb, not sure), especially the particle repeater.

timon37
EGOSOFT
EGOSOFT
Posts: 485
Joined: Fri, 14. Dec 12, 11:02
x4

Post by timon37 » Tue, 7. Jun 16, 10:10

Hi, sorry for going under for so long, as usual it means we've been very busy.
Unfortunately we'll be very busy for quite a while so there likely won't be any updates coming anytime soon:(

The scanner is a bug/missing feature, so it's on the todo list.
Any other sound differences are because on windows we use XAudio2, which is quite different from OpenAL (btw as an api xa2 is actually nicer imho). Anyway I did do some changes to openal-soft to mitigate any differences but it's practically impossible to fix all of them. Especially since some things are actually more correct in openal, (e.g. reverb doesn't cut off when a sound is stopped). The problem is the assets were designed for some of these implementation quirks and abuse them, so some stuff is not fixable.

User avatar
ezra-r
Posts: 3420
Joined: Fri, 14. Oct 05, 21:04
x4

Post by ezra-r » Wed, 15. Jun 16, 15:25

Thanks for the update timon37. As long as the long range scanner thing is in the todo list is fine by me :P

You guys very busy is a good thing I guess, at least looking at the future. Keep up the good work.

:)

kongha
Posts: 8
Joined: Mon, 11. Jul 16, 21:02

Post by kongha » Tue, 12. Jul 16, 10:46

Just want to give a big thank you for taking your time to port the game to linux. Im very happy about it :)

Keep up the great work. X-rebirth is my first sandbox/sci-fi and Im blown away :)

Post Reply

Return to “X Rebirth - Technical Support”