Sigh. So not ‘this work has been done’, just ‘has he stopped moaning yet?’.
I’ve been posting about it for months. Do I have to bump it daily to say it’s still the same?
Sigh. So not ‘this work has been done’, just ‘has he stopped moaning yet?’.
I’ve been posting about it for months. Do I have to bump it daily to say it’s still the same?
Hi Dave,
I flagged it up a few times and even as recently as today, but really haven’t been given much information on this subject. I’m sorry about that, but I’ll do what I can. Hopefully I can acquire some meaningful information soon. I’ll have to think about what other resources I can utilize to get some attention on these concerns. Thank you.
EDIT:
Just got an update from the team and basically I was told that the developers are aware of the reported in-game performance issues (as discussed in this Forums thread – and perhaps others) and they’re still working towards solutions. That’s all I have to offer at this time. Thank you everyone for your continued patience with us as we work to improve Zwift.
That’s great, thanks for the update (and apologies for my abrupt tone). As mentioned in the OP I’m more than happy to provide any diagnostic info that may be of use.
Did some more fannying about last night, observing frame rates on Neokyo during a group ride. Anecdotally I’ve been seeing a few reports that frame rates on Makuri in general seem to be higher recently, and I think it’s all related. It feels like whatever has been done to try and improve Neokyo in particular has been applied everywhere, and whilst that has had some positive impact on Makuri, it’s damaged everywhere else which was previously fine*.
As mentioned in the OP, it still feels to me like the field of ‘view’ (from a CPU load perspective) has been changed to be based on where the camera is pointing/looking, rather than only doing what it needs to do based on who/what is immediately around you. And the distance it ‘looks’ is much too far away. So whilst this might seem like a positive change - to cull things the user isn’t looking at - it’s been implemented in such a way that it’s actually increased overall CPU load significantly, in many circumstances including those which weren’t affected before. All the other worlds, basically.
As per the videos above, in my testing last night I was able to invoke massive FPS swings just by moving the drone cam around, even though the GPU was nowhere near full load and the number of other riders near to the camera (rider being viewed) was still being calculated as normal, and barely changing. Historically the quantity of riders nearby would be the factor determining CPU load, and nothing else. Likewise when the riders went through the harbour area the frame rate in default view 1 significantly improved, even though this was a steady group ride and the number of riders nearby was the same. I suspect this is because the camera was ‘looking’ out to areas where there’s nothing to see/calculate - out to sea and the edge of the map.
*Fine = not CPU bound unless very busy with other riders nearby.
Raising this recent post for visibility and attention.
I posted this issue last night with instant freezes in Tempus Fugit: [Instant freeze/crash on Tempus Fugit (PC)]. Sorry it won’t let me share links?
After a bit more testing, I have found that I do not freeze if I drop in on C. Cadence in the cave/waterfall area of tempus Fugit, but I get 100% guaranteed freeze if starting Tempus Fugit solo. As Dave mentions, perhaps this is a field of view/rendering distance issue. I imagine the open areas of Tempus Fugit would be especially susceptible to this bug if this were to be the case.
Anyhow, I’m glad to read that others are getting issues in Tempus. Not that I want anyone else to have a bad experience, but rather that I was about to break down and buy a new $$$ GPU thinking that this was a problem with my PC.
For the benefit of those who aren’t on the Facebook group, I’m pretty sure we’ve got to the bottom of this. I’ll type it up at some point.
We await your response with bated breath…
I’m not on Facebook so it would be useful to see a summary here.
FWIW I don’t see massive drops in FPS to 10fps (mentioned earlier), lowest I ever see is around 35:
Mac Pro (Mid 2010)
Processor 3.46 GHz 6-Core Intel Xeon X5690
Memory 32 GB 1333 MHz DDR3 (4x8)
Startup Samsung 2TB SSD
Graphics Radeon RX 580 8 GB
And the other machine:
Mac Pro (Mid 2010)
Processor 2x 3.46 GHz 6-Core Intel Xeon
Memory 128 GB 1333 MHz DDR3 (8x16)
Startup Disk: 1TB Samsung NVME 980
Graphics Radeon RX 580 8 GB
Both are MacOS 12.2
Highest FPS I see is 75. Worst is 35, mostly it is between 45-60. The drops in frame rate are always around approach to Titans Grove.
Only upgrade possible now is Radeon 6600XT which is now compatible thanks to firmware fixes. That upgrade is only if something goes wrong with the RX580.
Hopefully whatever is found might get some benefits for these machines. They aren’t new but at the same time they aren’t horrible specs either.
Drops to 10fps? Not sure what that refers to, sorry.
Anyway all of my findings are with Nvidia graphics cards and Windows as mentioned in the OP, so they won’t be relevent to your systems in any way I’m afraid.
Clever chaps - thanks Dave (and co), looking forward to trying this out later today.
Here goes.
Edit: merged below
You left out the good part
Yeah I hit post by mistake. It’s coming.
I just did a workout in Makuri and Neokyo, was hitting 60 fps (max i can get using an old TV), thats never happened!
Please bear in mind this is 100% speculation - I haven’t had any information or confirmation on any of this either publicly or privately. However it’s based on observation and testing with various combinations of CPUs (models and generations), graphics cards, operating systems and settings.
I believe that in order to address the substantially poorer performance of the game on Makuri Islands - and Neokyo in particular - two major changes have been made to how the CPU is loaded. As mentioned in the OP, for literally years the game was only ever CPU bound based on high rider density nearby. If you were solo and had any reasonable CPU from the last decade, the GPU could max out unless otherwise capped (by vsync etc). This has been the case in all my time on Zwift, until Makuri launched. Suddenly we were often severely CPU bound with nobody else around, or even offline. The CPU demands to hold 60fps went through the roof, as I documented here shortly after its release. When Neokyo came out, due to its tight level design, permanent shadows and masses of NPC activity, this CPU demand exited the atmosphere. Even the fastest CPUs money can buy in Zwift terms (12th gen Intel) were not enough to hold 60fps in the busiest of group rides. The two changes I believe have been implemented to address this are as follows.
Bear in mind this has nothing to do with the graphics card. It’s all about CPU bottlenecks, holding the GPU back.
Change 1 - Field of View
From my observations I believe the CPU demand is now based on a cone shape looking out from the camera, whereas before it was based on a sphere around the rider. This changed in early 2022 but was rolled out to all worlds together, not just Makuri where it was presumably intended to have most impact. I believe the idea was to take away some of the CPU load from things going on that you can’t even see on Neokyo, due to buildings around you. So instead of calculating everything nearby, it only calculates things where the camera is looking. This is why my videos show a massive swing in frame rate depending on what you’re looking at/towards. It feels to me like the distance the camera ‘sees’ is too high at present, and so the impact of looking down a long stretch of road is too great. The result of this change is what led to this thread. Makuri/Neokyo might have been improved by narrowing the view, but because every other world was performing just fine previously, they all went backwards. I believe that the ‘sphere’ on every other world was only really concerned with density of other riders, not everything within it. Now the new principle is uniform across worlds, but picks up everything in the ‘cone’. So the CPU load in many, many non-Makuri places is far higher than before, even when it’s not busy.
Change 2 - Threaded Optimisation
The latest game update 1.24.x brought about some unexpected improvements in performance, that are undocumented. In this respect I owe @Steven_D an apology because it seems the message he was given was accurate (albeit extremely vague). There was a change this month, and that change is to utilise threaded optimisation provided by the Nvidia driver. The default setting for threaded optimisation is Auto, so the driver decides whether or not it is used - presumably based on what the software tells it to do. Historically, specifically turning it off made no difference whatsoever to performance. Specifically turning it on however had a dramatic decrease in performance, circa 40-50% when I tested it back in 2019. As of the latest game update (and we have confirmed it came about with this update, no earlier), threaded optimisation left on Auto or specifically turned on brings about a massive increase in performance of 25-50% depending on CPU and load. Or to put it the other way, specifically turning it off has a dramatic decrease in performance, when this used to have zero impact. The behaviour has literally swapped around completely. Everyone* who’s always been on Auto (the default setting) will now be seeing a sizeable increase in frame rate - particularly on Makuri which is benefitting from both changes. Anyone who has disabled threaded optimisation in the past should immediately set it to On (Auto is fine with a quad core or above). Note that this doesn’t necessarily mean things are better than they were before. If anything it just puts things back to where they were, on all worlds but Makuri.
*The one caveat is that my testing seems to show that the performance only improves by default on CPUs with four or more physical cores. It doesn’t make any difference on dual cores with hyperthreading - Auto or off are all the same newly observed poor performance. Neokyo still being by far the worst. I’m still testing whether forcing it on can resolve the deficit for owners of dual core CPUs. Looks promising though.
Edit: Forcing threaded optimisation on does indeed improve/restore performance for 2c/4t CPUs. Those with dual core CPUs without hyperthreading are out of luck - no setting has any impact.
So if you’re still reading this shite… I have three problems with all this:
So much this.
That post was not GPU or CPU bound but Dave bound!
I’m not particularly computer proficient and I think even I understood all that, nice write up and interesting stuff.
Thanks as always @Dave_ZPCMR and for sure…….
Point 3. Just communicate please!!!
We understand not everyone wants the tech details or even cares about these things, but these forum posts should be used to provide this information for those that do care and have been begging for support and are more than willing to help you to help everyone!!
All ^that said, with the right driver settings there is definitely a notable improvement to performance on Makuri Islands (particularly Neokyo) from these changes, and as of this latest game update, performance on all the other worlds appears to have largely been restored. Physical CPU cores now play a part in FPS, where they were never relevant before. Obviously it’s very difficult/impossible for me as an end user to go back to game versions prior to 2022 to directly compare, but overall it’s probably a step forward.
In that regard and considering I’ve been moaning about Makuri for almost a year, it’d be out of order if I wasn’t to acknowledge and thank the dev team for their efforts. Not that I’m sure any of them read my ramblings on this forum, but either way it’s definitely appreciated by nerds like me who value being at 60fps as often as possible.
Cheers.