Game performance on Makuri Islands

Sounds like the game engine can only handle very detailed graphics (e.g. Yumezi/Neokyo) by putting a high load on the CPU. This doesn’t sound right. Why isn’t more being offloaded to the GPU?

I hope that someone is looking into the game engine to see how this can be made more efficient.


Neokyo followed by Fuego Flats. You can see a clear difference.

However, I might not be understanding the concept of being CPU bound properly, but I didn’t see anything close to 100% CPU even in the worst parts of Neokyo.

The highest I saw was 52% at the end of the Neon Flats loop:

The lowest I saw was 41% (corresponding to the highest frame rate):

Compare that to seeing 38% CPU and 48-60fps in the Fuego Flats.

Of course, by comparison Neokyo has a lot more going on, so maybe something like New York would be a better comparison.


You won’t, because Zwift can’t utilise your (or any) CPU properly. You’re still CPU limited, same as a group ride.

The fact is, if you pulled your CPU/mobo/RAM out and put a current gen i5 in, and changed nothing else, you’d get better results on Neokyo. The Fuego Flats performance would be the same, because that’s GPU bound. If you kept your CPU in and swapped your 1050 for an RTX 3090, the Neokyo results would be the same, and Fuego Flats would go through the roof (or never waver from 60fps, if you have vsync on).


Thanks Dave, I guessed I was probably failing to understand something. :rofl:

It can’t be seen on your screenshots unfortunately, but the key difference would have been the GPU utilisation. On Neokyo it will have been something far below 100%. Under 60fps but the GPU not working its hardest. On Fuego the GPU utilisation would have been far higher, right up to 100% in certain demanding spots (like where all the flowers are). GPU working its hardest to try and maintain your 60fps target.

An alternative way to consider this is the old group ride frame rate drop, which is easier than ever to demonstrate with Pace Partners. Simply follow C.Cadence and you’ll experience vastly lower frame rates through the exact same areas where your system can easily maintain 60fps on your own. A lot of people believe many riders increases the GPU load, but it’s the total opposite. The CPU can’t cope with the data crunching needed, and the GPU becomes starved. This is why a faster CPU is needed to keep group ride frame rates up. A better GPU literally wouldn’t help.

It’s like this on Neokyo (and to a lesser extent, Yumezi) all the time.


Yes, good point. I didn’t even notice that Task Manager had a GPU item. I’ll watch that next time. For science!

The thing is I can understand the CPU limitations in group events etc. It’s not ideal of course, and I feel like use of CPU resources could probably be better, but when you’re having to account for the position and inputs of hundreds/thousands of different people around the world and what they’re doing every second… I get it.

Jazzy visuals shouldn’t be the same. That’s what the GPU is for, rendering stuff. More demanding visuals should require more GPU power. More GPU power should equal more frames.

1 Like

I think it all comes down to when Zwift was started up. Game engines of the time may not have been able to lean on the GPU as much as they can now. 5-7 years ago a powerful GPU was pretty big bucks but CPU’s were relatively cheap. That’s changed with the 'splosion in gaming and a GPU that would’ve cost 3 grand back then is 300 bucks now. I’m just guessing here and this doesn’t account for the low RAM requirement of Zwift.

That fairly explains the CPU bottlenecks when there are tons of riders around. It happens everywhere and whilst not ideal, is a known limitation of the game. It doesn’t explain why Makuri Islands displays CPU/GPU load behaviour which is so different to every other world though. I’ve done a quick comparison between Neokyo and New York to demonstrate it.

Testing conditions:

  • Vsync disabled. Internet disconnected. View 3, HUD disabled. 4K resolution, Ultra profile.
  • Image one: Everything Bagel. CPU fully loaded, GPU at 99% load.
  • Image two: Neokyo All-Nighter. CPU fully loaded, GPU at 58% load.

Spot the difference in resultant frame rate.


For comparison at the other end of the scale, here’s a Pentium G3258 at stock clocks paired with a GTX 970. Exact same testing conditions. Bear in mind that the G3258, pictured here allowing the 970 to push almost 70fps in 4K on New York, is a dual core processor (without hyperthreading) that costs £6.00 to buy.

  • Image one: Everything Bagel. CPU fully loaded, GPU at 99% load.
  • Image two: Neokyo All-Nighter. CPU fully loaded, GPU at 73% load.

TL;DR: you lose about 40% frame rate performance on Neokyo due to the GPU being suffocated.


Same thing here, but GPU and CPU not that taxed, lower frame rates than watopia

My current theory is that there’s a problem with the level of detail/field of view configuration, or it’s simply been overlooked. Makuri Islands is more ‘alive’ than any other world - there’s stuff going on all over the place with NPCs walking around, playing football, interacting with one another and the environment. We know Zwift is highly single threaded, so all that computation gets added onto the same total CPU load. However whilst the other worlds seem to have no issue trimming the bits you can’t see, in Makuri it feels like this stuff is going on everywhere at all times. Or at the very least, much further away than it needs to be. Neokyo takes this even further due to how packed with detail it is; almost every building is ‘alive’. If you use the helicam and allow it to zoom right out, you can see tons of NPCs etc are still there, even though there’s literally no way for me as the rider to see them in any other camera view. In some cases there’s no way to get to them, even if we wanted to. But they’re there, doing their thing, taking up CPU resources. Another clear example is all the pointlessly cast shadows, from the back side of fully lit buildings and windows. Physically impossible to see, but still having an impact on performance.

If this is indeed the issue, there are two ways around it IMO. One is to address it head on, and reduce the impact of things we can’t even see. The other is for Zwift to break away from their historical policy of giving the user no control whatsoever over the graphics options, unlike any other PC game. That way the user could adjust the game’s appearance to suit their own hardware, to acheive the performance results they want. Again, like virtually every other game ever does.


You are almost certainly CPU bound, specifically if you’re referring to Neokyo.

1 Like

Yes neokyo, on a new m1max running zwift in rosetta. It’s fine, I’ll roll back to watopia anyway.

I’d wondered if it was something to do with culling, but then I assumed all that sort of stuff was the job of the GPU anyway. I’m not a 3D engine programmer, so I’ve little to no frame of reference.

Another laughable result here. Again, someone please advise me why these hardware specs aren’t good enough to expect a constant 60fps. It’s utter nonsense.


That might be a clue as to what is going on. I don’t think that m1max can show the high detail setting with the detailed shadows etc. Could be wrong.

It can

It can’t but the GPU utilization in watopia is always higher than in neokyo. 40% neokyo vs 65-70% watopia (using custom config to add as much detail as possible in the high setting).

Probably due to Makuri (inc Neokoyo) being heavily bottlenecked on the CPU, therefore not sending enough work to the GPU to utilise it better.

1 Like

That’s exactly what it is, this clearly isn’t a platform-specific problem. :+1: GPU utilisation should be as high as possible unless the frame rate is deliberately capped (at 60fps by vsync, for example). When the target cannot be maintained, we should see the GPU working as hard as possible to provide as many frames as it can.