Must be a 3090 thing... My 2080 Super / 4KGood lord! What are you running in the background?....
Perhaps they have 8k?
But, of course, if you catch it while it is loading everything...
Last edited:
ED:Odyssey Update 7 Performance Issue and proofs
- Thread starter cmdr_Giboulot
- Start date
Perhaps they have 8k?
But, of course, if you catch it while it is loading everything...
It's so weird. Update 7 has been in the works for a bit. The patch notes are hefty but it doesn't look like much of anything has changed. Frontier continues to puzzle me as a developer.
I'm pegged at 99-100% GPU load at the main menu with pretty much any system I've got, at any sane settings for the GPU involved. Not much CPU work being done on the main menu screen.
Biggest issues seem to crop up in settlements when geometry/meshes get out of hand.
Nothing much - it's all EDO load but for about 2%Good lord! What are you running in the background?....
Fortunately my temps seem good. The ASUS TUF 3090OC stock does a good job from what I've seen elsewhere re 3090 temps, once you get case fans properly adjusted.
I idle around 45 - 50 C until I load EDO and then jump to around 65C with hotspot @75C and memory junction temp @ 85C which is 10 C below recommended top temp.
But if I can get ED down to 50 GPU I'd likely be another 5 - 10C cooler during gaming.
I can get lower temps if I want to hear fans - but who wants that...
I used Xperf to capture, and GPUView to...view, a trace of my system while playing a couple of minutes of the suit tutorial (at 1440p ultra+, which is where I see a good mix of alternating CPU and GPU limitations in settlements in Update 7) in order to get a more detailed picture of what was going on. Granularity of the caputure is much finer than what's possible with most monitoring apps and it's clear from these logs that when GPU utilization falls, it's usually due to the GPU waiting on the main game thread or it's primary worker thread
Recorded this in 4k, but only 1080p has finished processing...you can probably make out what's going on if you squint:
Source: https://www.youtube.com/watch?v=dA17aO4tv_s
Also, ignore the paging queue, that's a side-effect of the video capture and has little to no bearing on anything else.
Most relevant segments are the first three minutes (illustrating system specs and actual gameplay performance) or so and then ten minutes on (where I find a relevant segment of the trace and zoom in on it). As you can see near the later part of the video, that main game thread is what's bogging things down. Enough single-threaded CPU performance can brute force it's way through it (which is why going from a 3900X to 5800X noticeably improved my performance), but Frontier clearly needs to address the underlying cause of this utilization/scheduling.
Some info on how to interpret GPUView:
I could probably dig deeper with XPerf to see what the problem threads are actually doing, but I'm not sure it would be worthwhile. I know others like flexcreator have already looked at the GPU side of things with Nsight. Maybe after I figure out how to filter some of this extraneous info out of the logs, which are enormous and a pain to work with, I'll take another look.
Recorded this in 4k, but only 1080p has finished processing...you can probably make out what's going on if you squint:
Also, ignore the paging queue, that's a side-effect of the video capture and has little to no bearing on anything else.
Most relevant segments are the first three minutes (illustrating system specs and actual gameplay performance) or so and then ten minutes on (where I find a relevant segment of the trace and zoom in on it). As you can see near the later part of the video, that main game thread is what's bogging things down. Enough single-threaded CPU performance can brute force it's way through it (which is why going from a 3900X to 5800X noticeably improved my performance), but Frontier clearly needs to address the underlying cause of this utilization/scheduling.
Some info on how to interpret GPUView:
Matt's Webcorner - GPUView
GPUView is a tool to investiagate the performance interaction between the operating system, the graphics applications on your computer, the graphics kernel, and the graphics driver.
graphics.stanford.edu
I could probably dig deeper with XPerf to see what the problem threads are actually doing, but I'm not sure it would be worthwhile. I know others like flexcreator have already looked at the GPU side of things with Nsight. Maybe after I figure out how to filter some of this extraneous info out of the logs, which are enormous and a pain to work with, I'll take another look.
TF3 was released? My son will be happy, though he prefers playing demo man.
While I was giving the ground combat zones a spin, I noticed somewhat odd behaviour with the FPS. Each time I entered a new zone, the FPS tanks for a short while to around 10-20. This lasts for 5 to 10 seconds, then the frame rate stabilizes to the best I've ever had in combat zones, around 30-35.
It's getting to the point where I feel like you are doing more work trying to identify the issue than FDev themselves are. The fact that a user can figure out more with simple profiler apps than the actual dev can is worrisome.
I have a feeling we can attribute the main menu heavy load partially to the fact that it's still rendering the old Horizons menu behind it, the one that had the SRV on a planet staring up at an Orbis station.
Whenever I load up Odyssey, I briefly see it for about a second or two before the actual menu loads on top of it. And whenever I quit from the main menu, it flashes onscreen very quickly as it's unloading all the other menu assets.
Whenever I load up Odyssey, I briefly see it for about a second or two before the actual menu loads on top of it. And whenever I quit from the main menu, it flashes onscreen very quickly as it's unloading all the other menu assets.
I just did a few ground conflict zones and found the same thing. For the first 10 or 20 seconds, it's like it's loading stuff or something, and has that same stuttering/low FPS like before. But after that, the rest of the conflict goes on without interuption.
Could this mean they've maybe isolated this bug?? Must be easier to squash a bug when you have it in your sites. Maybe for the next update, they remove that bug for good? Anyways...I'm quite happy about this!
I got rocketted a few times, and then got frustrated, you know, because I didnt have much time to react before being blown up. After a few minutes, though, I heard other rockets being fired, and folks being blown up, but it was my factions enforcer launching the rockets, and it was the enemy factions troops being blown up! Thats great! More of that please
I didnt have chance to notice the turrets yet...hope to see that soon.
For those having a rougher time, I hope that gets sorted out. Keep at it FDev!
Game Development
Access tools, tutorials libraries, and code samples from Intel to optimize your games.
software.intel.com
Given the behavior I've observed, I strongly suspect that ED's main game thread is also it's main render thread, responsible for both logic and submitting draw calls. Even if neither could be parallelized, it should be possible to separate them, if this is in fact the case.
I might pull my 6800 XT out of this system and put my RTX 3080 in it to see if NVIDIA's drivers (which can intercept and redistribute command lists to other threads, improving CPU utilization at the cost of some overhead) are able to split the render work into multiple threads better and if it results in less CPU bottlenecking. I'm doubtful, given other reports and my own cursory testing on the system my 3080 is currently in, but I'd want at least the CPU the same to be sure.
Also, the slides here on resource management and sync points might be relevant:
I'm confident that FDev, or at least some subset of them, has a much clearer picture than I do. I'm just not confident in their level internal communication, or their ability to economically address these issues in a reasonable time frame.
I've seen this as well, pretty much in any fresh surface area.
It's also a CPU limitation in the main game thread, which can be fully loaded for such prolonged periods of time that it can stall the game. The video driver memory management is also very active here.
My speculation is that they tried to implement more aggressive geometry culling, or attempted to reduce static VRAM allocation, and are trying to do more on the fly than they should, or are just doing it poorly. Any time something new shows up, the game may seize up while dynamically compiling shaders and/or managing video memory...until all assets encountered in a scene have been processed, which may be being differed until a much closer range than before. Again, this is just speculation.
Well, all I know for certain is that the visual attractiveness and performance in VR remains bad on my machine. Horizons is infinitely better in every respect that matters to me. I only play in VR, and I do NOT engage in any of the on-foot aspects. The SRV experience is, without a doubt, the absolutely worst experience in VR. As a player who only wants to fly and occasionally drive the SRV to pick up materials or get blueprints, nothing else they are adding has any impact on my playing. I just want the game to LOOK great and PERFORM as well as it does in Horizons. Planets/moons are still boring in Odyssey and everything stutters. I certainly hope update 8 makes a difference---but I sincerely doubt it. They clearly don't care about the VR experience anymore.
You speculate well.
Thanks for sharing your knowledge. I usually don't understand half of your posts, but I always come away feeling a little bit wiser. Do you teach in real life? You convey information very well.
The stuttering is not only on ground.
Played in space, doing some installation defenses. Every time, I mean every time NPC pirates drop in instance to attack, it becomes a slideshow. After that, FPS is going up again.
In Horizons this wasn't the case.
This is defo a server side issue. Odyssey servers and Horizons are different. Perhaps the high performance servers remained in Horizons and they bought some server power for Odyssey but lower performance ones? I mean, server power costs a lot.
My guessing that stutterings will end only when they will merge the games.
This is why we have double server tick, because each tick is for every game.
Played in space, doing some installation defenses. Every time, I mean every time NPC pirates drop in instance to attack, it becomes a slideshow. After that, FPS is going up again.
In Horizons this wasn't the case.
This is defo a server side issue. Odyssey servers and Horizons are different. Perhaps the high performance servers remained in Horizons and they bought some server power for Odyssey but lower performance ones? I mean, server power costs a lot.
My guessing that stutterings will end only when they will merge the games.
This is why we have double server tick, because each tick is for every game.
I just did a couple ground conflicts, this time on medium intensity and at a different location. It had worse stuttering etc, than update 6, and worse than my previous ground conflicts that were low intensity and only stuttered for the first 20 seconds, then were ok after. I can tolerate that since the payout is higher for mediums, but hoping this issue can be resolved.