Now getting >90 FPS at 1080p - info on issue affecting high-end rigs [spoilers]

[sms_747]

AMD T1100 BE @ 3.7 (LC)
2x 6870 HD (LC)
16GB Corsair Vengeance (AC)
GA-890FX

getting <30fps in Albion, and 50fps+ the other side of the gate.

That said, I would think that making an AUTOSAVE would come as a higher priority, to stop your fanbase [me included] getting too
At least that way we can PLAY the bloody game while you fix it, instead of doing the same collection of missions over and over and over again.

[Tiberseptim]

I took a screenshot of the worst-case scenario with the most ships on screen.

Down to 15fps... same setup of the 90fps posted earlier... same no CPU nor GPU bottleneck (check stats in top left corner)

http://s21.postimg.org/7395wwa4m/screen ... _01_29.jpg

Compare to the best-case scenario of a highway in DeVries at ~105fps (same settings, same session actually):

http://s13.postimg.org/ukzmj0io6/screen ... _49_20.jpg

Note the important issue here is not how crowded Albion is vs DeVries. It is that in DeVries GPU utilization is actually HIGHER (!). This fact supports the theory above, but of course needs further proof.


{Images posted directly to the forums should not be greater than 640x480 or 100kb, oversize image now linked - Terre}

You don't think they actually just slapped the D3DCREATE_MULTITHREADED flag on it all instead of rigorously enforcing threading rules to ensure strong thread segregation do you? I mean sure on something this big one of those things is a huge pain and headache, but the other is basically saying screw it, and that it doesn't matter if it runs well.

[Zalifer]

Nice find~ However from what I read on steam forums Bernd stated that they could give a rats ass abut high end PC's. It sounded like they were setting this game up for future X-Box release and intended it to work low end systems like consoles.

Hopefully they listed to posts like yours and at least have pity on us with decent systems.

Link? Because I read this :

"We will improve the performance across all systems. On high end systems like the ones described in this chapter, there is definitely most room for improvement. However X Rebirth will always remain a very CPU heavy game which can not achieve the same framerate that you may be used to from very graphic intensive first person shooters. "

http://steamcommunity.com/app/2870/disc ... 371458323/

[Astyrrean]

Yes, we've seen it, and yes we're aware. No need to keep bumping.

Ok... plan on doing anything about it? I haven't heard much of anything about actually addressing this issue... which is hard to understand as this is THE issue.

I don't think it's so simple.

First, it is really just a hypothesis at this stage (although arguably a relatively well-documented one). Until the hypothesis has been confirmed by further analysis on the developers' end, it is pointless to ask for a fix.

Second, the complexity of fixing a thread synchronization bottleneck varies greatly. It can go from a simple removal of mutex objects where they are not actually needed by the code logic, to a partial rewrite of code to reduce access to synchronized resources. In some cases, core design of an application may be such that design has focused heavily on (single-instanced) heavily-featured synchronized objects. In those cases, addressing the bottleneck without essentially rewriting the entire application is practically impossible.

Third, threaded application writing is quite different from single-thread application writing. As this is the first threaded application I know of that EgoSoft wrote, it is reasonable to assume that, as skilled as the developers may be, they will face a learning curve on that front, especially on the optimization side of things. They are human beings just as we are, and deserve a break from the criticism while reviewing their first attempt at a new (and complex) coding technique).

Fourth and last, I think Bernd might be surprised (in a good way) at the end, if all goes well. Multi-threaded applications (that take advantage of that mechanism through coding best-practices) have huge potential to deliver performance above and beyond what is achievable with single-thread coding. It may well turn out that X:Rebirth, once optimized, will be the first X game that is not CPU bound... and that would be a great achievement that I think we should compliment the devs for if they can pull it off.

Astyrrean

[Astyrrean]

I took a screenshot of the worst-case scenario with the most ships on screen.

Down to 15fps... same setup of the 90fps posted earlier... same no CPU nor GPU bottleneck (check stats in top left corner)

http://s21.postimg.org/7395wwa4m/screen ... _01_29.jpg

Compare to the best-case scenario of a highway in DeVries at ~105fps (same settings, same session actually):

http://s13.postimg.org/ukzmj0io6/screen ... _49_20.jpg

Note the important issue here is not how crowded Albion is vs DeVries. It is that in DeVries GPU utilization is actually HIGHER (!). This fact supports the theory above, but of course needs further proof.


{Images posted directly to the forums should not be greater than 640x480 or 100kb, oversize image now linked - Terre}

You don't think they actually just slapped the D3DCREATE_MULTITHREADED flag on it all instead of rigorously enforcing threading rules to ensure strong thread segregation do you? I mean sure on something this big one of those things is a huge pain and headache, but the other is basically saying screw it, and that it doesn't matter if it runs well.

I honestly don't know but I equally honestly would be surprised if that was the issue.

I understand the graphic driver code is in a single thread. Logically, and as a best practice, that would mean that all D3D calls would be made by that single thread. If that is the case, then the D3DCREATE_MULTITHREADED is not required and should not be used.

If that is indeed coded as best practice recommends, then the issue is not related in the way D3D calls are made, but rather in the synchronization of the engine threads before the graphic driver is invoked - namely, the two "main threads" that cater to the engine and the universe, and all service threads which cater to loading, sound, pathing, etc.

Pathing in particular struck a cord with me when Bernd wrote that it was in a separate service thread. It is a generally computationally-intensive operation which, when many pathing agents are required, can really become a burden (depending on how it's implemented). Notably it's also one of the best-understood algorithms which should have ample space for optimization... but is really hard to get right upfront (see SimCity upon release and its traffic jams).

Without looking at the code though it's impossible to say - hence the need for the devs to take a look personally at this.

[WildAce]

I decided to contact AMD directly to see if they could help Egosoft with some of the performance issue on high end AMD hardware.

AMD's Director of Developer Relations & Alliances Team, and one of the European developer relations team members is now made firmly aware of some the performance issues Egosoft is having with X-Rebirth.

so hopefully they can help Egosoft improve things.

[TheRealBix]

I uploaded a picture of the graph I get with my measures (3 hours)

http://i.imgur.com/A8eYtKU.png

The average framerate is between 25 and 40. Sometimes less, rarely more.

This is the same syndrom you've described.

[Mastercyclone3D]

That good to know guys. I wish someone contact nvidia for me for to help egosoft.

This is what I done to improve my FPS restart computer after update 1.13
This is what I did after restart computer
Clean temp folder
C:\Users\blahblah\AppData\Local\Temp
C:\Windows\Temp
Then start the game from C:\Program Files (x86)\Steam\SteamApps\common\X Rebirth\ Rebirth.exe and run as Admin rights
Change the Graphic setting
1680x1050 or 1920 x 1080
4x AA or 2AA << this is all deepens on how strong is your video card is.
V sync Off
SSAO On
Shadows On
LOD setting 100
View Distance 100
Effect Distance 100
Shader Quality High
Gamma 100

Game setting
Rumble 100

Then push Alt and Tab
Then push Ctrl and Alt and Del go to the task manger
Right click on XRebirth.exe under process Set priority to High
Then right click on XRebirth.exe and Create a Dump File wait for the dump is done
Then go back to game load your saved game or start a new game.

I don't know what I did to get it going I was crashing repeatedly with this update and now I am not it shown 3.2 Gb of game file now on task manager from the process. Used to be 325mb. It the only way for me to really get a better FPS and the game doesn't crashed on me anymore.


Hope this help.

[lithast]

The only problem that I have with this theory, plausible as it sounds is that it does not explain the variation between people on identical hardware. Some people with hardware x have no issues and some other people with the same hardware are getting very bad performance.

I've written my share of threaded applications and I agree this could explain it, but I'm not sure how you would account for the inconsistency with identical hardware.

I would also expect that if this was the problem that it would have been even more prevalent on the "mid range" hardware that they stated they focused testing on.

I personally built a PC from scratch on the weekend to play this and have had no performance issue at all. i5 3.4, 760, 16gb etc.

[TDZGamer]

There are definitely some kind of performance bug. I monitored CPU and GPU utilization and neither goes above 50% during playing (occasionally spikes up to 60% on one or two cores). I tried turning down video options and it had no effect. I get framerate hickups pretty much consistently every 2 seconds.

Hardware: Core i7 920 (Quad core with HT) @ 3.3GHz, 12GB RAM @ 1600MHz, Geforce 780 (Asus Direct CU II OC). I know the CPU is "old" but I can play BFBC2 on max with smooth framerate and both CPU and GPU utilization is twice as high there.

I am using AIDA64 combined with my Logitech G19 LCD display to monitor values during play. Are there any other software out there that can put numbers OSD and log values?

[TDZGamer]

I just realized something that may be important!

After zoning around and testing different settings I observed that whenever framerate drops, so does GPU and CPU utilization! When the game runs smooth (in most sectors infact), the gauges show that several cores are running at around 70-90% and GPU utilization is well above 50%. When the lag is wors, CPU and GPU utilization drops to lower than 20%.

Edit: The GPU even throttles down like its just idling!

[Astyrrean]

The only problem that I have with this theory, plausible as it sounds is that it does not explain the variation between people on identical hardware. Some people with hardware x have no issues and some other people with the same hardware are getting very bad performance.

I've written my share of threaded applications and I agree this could explain it, but I'm not sure how you would account for the inconsistency with identical hardware.

I would also expect that if this was the problem that it would have been even more prevalent on the "mid range" hardware that they stated they focused testing on.

I personally built a PC from scratch on the weekend to play this and have had no performance issue at all. i5 3.4, 760, 16gb etc.

I haven't seen side-by-side comparisons of people with "identical hardware" (if there is any such thing in the PC world). It seems to me people are reporting vastly similar issues, equally inconsistent across different hardware types. Maybe we are looking at different things?

I will challenge your mid-range-hardware-prevalence statement. Quite the opposite in my experience - thread synchronization bottlenecks become more apparent when throughput increases. Notably, if fill-rate on a GPU is already the primary bottleneck (say, on a mid-range machine), then you wouldn't even have a chance to hit the hypothesized thread synchronization bottleneck... which would be why only higher-end machines are affected.

On your "had no performance issue at all" - can you play at 3840x2160 at a constant 60+ FPS like I do in Skyrim (also a CPU intensive game)? Because I can't with X Rebirth on my rig... although I can play at ~30 FPS (Albion) and ~50 FPS (DeVries) in a 1920x1080 windows (i.e. a quarter of my display's native resolution) as most other high-end-rig people appear to be able to do. I wouldn't call that "having no performance issue at all", at least on my end.

Astyrrean

[Astyrrean]

I just realized something that may be important!

After zoning around and testing different settings I observed that whenever framerate drops, so does GPU and CPU utilization! When the game runs smooth (in most sectors infact), the gauges show that several cores are running at around 70-90% and GPU utilization is well above 50%. When the lag is wors, CPU and GPU utilization drops to lower than 20%.

Edit: The GPU even throttles down like its just idling!

That is the whole point of this thread ... pretty much everyone with a high-end-rig is experiencing the same... see my hypothesis as to why in OP.

[Scoob]

My CPU utilisation, in the busy starting areas, is consistantly 50-60% on all cores. As for GPU, it's usually in the 90's.

So, when the game is running "well" - I see fairly high resource usage, actually higher than I'd expect on my GPU. However, it all comes back to the whole FPS drop = resource usuage drop.

FYI: my system is reasonably high-end:

2500k @ 4.8ghz
2x680 @ 1200mhz - only one used, profile set to single GPU (best perf this way)
W7 Pro 64

Note: this is a fairly "clean" build, as the PC is just my gamer. So, no additional codecs, only basic (MS Essentials) security software etc. Generally, I have a fairly trouble-free gaming experience. Skyrim was the last game I had very similar issues to this with, and that HAD to be addressed with a game update. The same is the case with Rebirth.

I've tried the various SLI profile changes suggested and, while they DO improve the FPS on the menu screen, they have at best no impact on in-game FPS, and usually hurt it quite badly.

IF Egosoft do enable SLI support - likely along with an NV driver update too - then I'd expect both my FPS to improve quite markedly but, equally, my CPU load would increase also. However, this would not fix the situation where resource usage is low and FPS is poor.

Egosoft appear to have a fairly agressive patching schedule planned, so I'll be eagerly keeping the game up to date when these are focusing on performance. I still think the various broken elements of trading and general ship control are a higher priority though.

Scoob.

[TDZGamer]

I just realized something that may be important!

After zoning around and testing different settings I observed that whenever framerate drops, so does GPU and CPU utilization! When the game runs smooth (in most sectors infact), the gauges show that several cores are running at around 70-90% and GPU utilization is well above 50%. When the lag is wors, CPU and GPU utilization drops to lower than 20%.

Edit: The GPU even throttles down like its just idling!

That is the whole point of this thread ... pretty much everyone with a high-end-rig is experiencing the same... see my hypothesis as to why in OP.

Indeed, and EGOSOFT goes far in admitting the problem is someting like this in the sticky:

Technical details for the experts:

As I have explained above our engine is oftentimes CPU bound because of the massive AI simulation going on in the background. This is happening on multiple threads, but there are always two threads which mostly limit the framerate. This means the game will greatly benefit from a quadcore machine where two cores can crunch on our two main threads, one core can do the graphic driver code and the fourth one is free for the lower priority threads of our game such as pathing calculations, loading and sound. More cores will unfortunately not help much at this point in time

It seems that only a single thread is doing much work during the lag so it would appear that the other threads largely depend on one of the main threads and has to wait for some results before continuing. This should favor new CPU quad cores with high clocks.

I don't think we can do much about it except wait for a patch. I will try a "Free flying" game and hope that the hangup is related to the campaign somehow

[Scoob]

If one of the major threads was so heavy, wouldn't we see that reflected in the CPU load, with one particular core being higher than the others?

I've been checking CPU and GPU stats pretty much since I got the game - I run Process Explorer, GPUz (x2), CPUz and CoreTemp on my 2nd screen while playing - and CPU load has been pretty consistant varying between a low of 40% and a high of 60% overall, with a nice even load on all cores. I do see a brief spike to 70% load - again on all cores - just after loading a save, but that settles down almost immediately.

Memory load isn't excessive either, usually somewhere over 1gb, but climbing as I play, with the odd purge when it reduces slightly. Memory controller load is typically around 40% when looking at a reasonably complex station. GPU load IS high, at 95%+, however GPU TDP is only in the mid-60's for this load level, suggesting the hardware isn't pushed as much as you'd think - I can see 90%+ in demanding games & benchmarks

GPUz doesn't seem to show PCIe bus load, can't recall which tool I used to measure that previously...if I ever did.

Scoob.

[venkar]

It sounds like there are specific animations that cause the strain. I noticed the same effect when dropping off the 'selling 100 energy cells' mission at the lonely giant in exhaustless mines. The pulsing wave graphic around the asteroid is a clear indicator.

Loading up the game fresh with no extra CPU cycles trying to render the extra animations makes the zone move at a fast FPS. Now travel out and return the zone several times, this will cause the CPU thread not to close properly and creates the bottleneck. Make sure to let the animation render for a while before leaving. I can watch the heavy load build over time.

It's the number of threads that used and not closed. It's how the X:R EXEs are directing the calculations for the animations to be rendered by the CPU instead of the GPU. Granted it's a great process and opens the door on how the stations look incredible, but a process is causing the thread to remain open and in use...so re-rendering the graphic again causes the CPU to open a thread and leaves that one open too...rinse and repeat.

[TDZGamer]

A single thread only uses one logical core. So the overall CPU utilization on a quad core with hyper threading would show as 12.5% if a single core was working at 100%. However the CPU core rarely uses 100% even when its working hard. A thread could be using only 60% of the core and still hang the system as all the other threads wait for it to return a specific result.

[curt428]

Still haven't seen any Devs admit that this is the issue and that it is being worked on... bump.

[Astyrrean]

The fact that the game is particularly laggy after loading a savegame for several seconds (i.e. when the loading thread is still at work), and then becomes smooth again, further supports the theory, I believe.