Update 18 - True Multi-Core CPU Support

Vaoh

So this should help game performance quite a bit!

I don't know a whole lot about this sort of stuff, but I know plenty of you probably do lol.
Will this change improve game performance for consoles at all? Would be very nice.

Turelus

In theory any of the issues due to CPU load yes (so less stuttering).

It won't fix Cyrodiil lag suddenly though as that's more about server calls that your own machine.

MLGProPlayer

It should help with FPS drops anywhere that the CPU is bottlenecking. I'm not sure the CPU is a bottleneck on consoles though where the GPU is quite weak.

Vaoh

Turelus wrote: »

In theory any of the issues due to CPU load yes (so less stuttering).

It won't fix Cyrodiil lag suddenly though as that's more about server calls that your own machine.

Would that apply to performance-intensive scenarios that aren't based on server lag? Like Vet trials. Rakkhat HM, 4th boss vHoF, Assembly General HM can be especially low on FPS.

It would be very nice to see improvement there.

Wreuntzylla

I'm optimistic. I haven't had much lag since I installed an optane 900p for single core optimization, and I would think that the remaining lag is server based.

Vahrokh

Vaoh wrote: »

Turelus wrote: »

In theory any of the issues due to CPU load yes (so less stuttering).

It won't fix Cyrodiil lag suddenly though as that's more about server calls that your own machine.

Would that apply to performance-intensive scenarios that aren't based on server lag? Like Vet trials. Rakkhat HM, 4th boss vHoF, Assembly General HM can be especially low on FPS.

It would be very nice to see improvement there.

It heavily depends on how much and how well they have re-engineered the graphics engine. It is pretty hard to:

- streamline sequential events into a parallel process, especially if the former used to be the whole game until recently.
- share equal load between processor. It's "easy" (actually, it's still hard) to take away ancillary tasks from 1 processor and assign them to the others. But in this case, processor #1 is still way more burdened than the others and is still a bottleneck. Just less than before.
- sharing 100% workload between 4 processors, does not yield to having them 25% workload each. Each thread is different and does not have to process the same stuff. Then there are various inefficiencies and queues (for example, processor #2 completes a task but #3 is still busy and processor #1 can proceed only when both #2 and #3 are done).
End result, if you have 4 processors and had 20 FPS today, after patch you won't have 80 FPS. You'll have 40, perhaps 50. It's still a tangible enhancement, though.

Vaoh

Vahrokh wrote: »

Vaoh wrote: »

Turelus wrote: »

In theory any of the issues due to CPU load yes (so less stuttering).

It won't fix Cyrodiil lag suddenly though as that's more about server calls that your own machine.

Would that apply to performance-intensive scenarios that aren't based on server lag? Like Vet trials. Rakkhat HM, 4th boss vHoF, Assembly General HM can be especially low on FPS.

It would be very nice to see improvement there.

It heavily depends on how much and how well they have re-engineered the graphics engine. It is pretty hard to:

- streamline sequential events into a parallel process, especially if the former used to be the whole game until recently.
- share equal load between processor. It's "easy" (actually, it's still hard) to take away ancillary tasks from 1 processor and assign them to the others. But in this case, processor #1 is still way more burdened than the others and is still a bottleneck. Just less than before.
- sharing 100% workload between 4 processors, does not yield to having them 25% workload each. Each thread is different and does not have to process the same stuff. Then there are various inefficiencies and queues (for example, processor #2 completes a task but #3 is still busy and processor #1 can proceed only when both #2 and #3 are done).
End result, if you have 4 processors and had 20 FPS today, after patch you won't have 80 FPS. You'll have 40, perhaps 50. It's still a tangible enhancement, though.

Ty for the detailed description! +1

Cinbri

Turelus wrote: »

In theory any of the issues due to CPU load yes (so less stuttering).

It won't fix Cyrodiil lag suddenly though as that's more about server calls that your own machine.

But will it fix problem that with 8 cores i have 15 fps as soon as i fight zerg?

Turelus

Cinbri wrote: »

Turelus wrote: »

In theory any of the issues due to CPU load yes (so less stuttering).

It won't fix Cyrodiil lag suddenly though as that's more about server calls that your own machine.

But will it fix problem that with 8 cores i have 15 fps as soon as i fight zerg?

I can't say really, I am far from on expert on the issue. I mean I would have expected that to be based around the GPU but I've heard a lot of people say ESO is more reliant on CPU than GPU power.

I hope so though, it would honestly be nice to play SO and not be running trash mob fights at 20 FPS on a machine which was built to run Fallout 4 on ultra settings without issues.

profundidob16_ESO

Cinbri wrote: »

Turelus wrote: »

In theory any of the issues due to CPU load yes (so less stuttering).

It won't fix Cyrodiil lag suddenly though as that's more about server calls that your own machine.

But will it fix problem that with 8 cores i have 15 fps as soon as i fight zerg?

I do dare to call myself an expert with over 20 years experience in hardware and performance troubleshooting. Identifing bottlenecks has become second nature to me so naturally I could not resist troubleshooting this exact issue extensively in the past. Here are my findings and an attempt to clarify in layman's terms:

The first prerequisite to meet in order to maximize fps is have sufficient GPU performance. That is a joke since the latest generation of top end nvidia cards (1070ti,1080ti) who all blow this custom modfied yet dated hero engine away. In other words as long as you have anything close to the latest generation of high level gpu hardware gpu performance this prerequisite is off the table

The second prerequisite is the real bottleneck: It is the CPU in combination with the GPU and memory, having to run in a circle between all 3 to transfer data as fast as possible and this in continuous process multiple times per second. In computer hardware terms this is the single-core performance of the cpu and front bus frequency as well as memory timing and frequency.

However the reason all the stress is on that part of the hardware is because of the game's code as perfectly described by forum user @Vahrokh. Some jobs as part of the continuously running code are just very hard or even impossible to split off onto another thread (read: another core of your cpu) because they contain active dependencies on elements in the main thread.

Think about it this way: Imagine you are alone inside your house in ESO and the game has to display the animation of you casting a circle of whatever this task can easily be launched on a different core or thread of your cpu as the animations of the walls, the floor, the objects inside it, all rendered per second nonstop in time. So all cores can be used effectively without ever bottlenecking 1 core and all the load is handle with ease by the gpu, resulting in max fps your monitor can handle

Now imagine you're in a zerg in cyrodill and want to cast that same circle of whatever. In order to determine wether this effect will be drawn or not your cpu first has to calculate wether you are capable or not which is dependent on wether the stun launched on you by the guy behind you succeeds or not which in turn depends on....you see where this is going. 20+ people in a zerg all affecting each other with buffs and if enemies with debuffs, dmge, stuns and other cc...all depending on each other. All this stuff has to be calculated within 1 and the same main thread and that is why 1 thread running on only 1 core of your cpu will completely bottleneck in a zerg and drop your fps because this is after all a nonstop continuous process that happens multiple times per second

so for example with an Intel 7700K/8700K cpu @5+Ghz, a front bus of 4.5+Ghz and memory 3600Mhz@CL15 or better all your current problems go away already as it is and you won't drop lower than 50fps ever in zergs, dolmens or trials, even with 40+ peeps on your screen. But with let's an average amd on a low frequency it will be normal to see drops to 15fps in the same situation because that hardware is terrible at single core performance.

The promise of better multicore support in update 18 is basically an attempt to yet to split off some dependencies into different threads by optimizing the code, even though that's very hard. Based on how successful this is you could realistically see up to 30% increase on your lowest drops or only 10%, it all depends on the code

But if you have 15fps in zergs as it is your hardware is not up to the task and even 30% increase on that won't make it fluent. So with your particular hardware the answer is....no

Merlin13KAGL

If they do split up the processes properly, the result will be tremendous. Even in low end PC's there's a lot of currently unused processing power.

This is counting on the fact that they keep timing and information synced properly. The side effect is that some bugs will probably become even more difficult to nail down than they previously were.

Even if they offload much of the 'background' processes to another core, the less time sensitive essential stuff, it should free up significant resources on the primary thread.

Carbonised

@profundidob16_ESO

Can you also give us the magical solution as to why ZOS claims the game is unable to render more than 700 inert, inanimate objects inside a gigantic mansion house? -_-

Turelus

Carbonised wrote: »

profundidob16_ESO

Can you also give us the magical solution as to why ZOS claims the game is unable to render more than 700 inert, inanimate objects inside a gigantic mansion house? -_-

This was based on the lowest end machines remember (back in 32 bit) so who knows what level of potato that was designed around.

I really hope we see an increase how we're leaving some of the older stuff behind.

Merlin13KAGL

Probably has to do with the way houses are coded. They are essentially one giant container of containers.

The difference being, that each of those likely has additional coded information, since they can move, vs a premade level/instance that does not change.

One is created in a more efficient manner. The processing required (whether actual processing, memory capacity, or method of storage within memory) is probably beyond what the hardware spec of console is capable of, and would require a complete redesign of the (program) structure.

That's a much bigger deal than it sounds like it would be, so they're leaving it as is.

profundidob16_ESO

Carbonised wrote: »

@profundidob16_ESO

Can you also give us the magical solution as to why ZOS claims the game is unable to render more than 700 inert, inanimate objects inside a gigantic mansion house? -_-

yes, that would be changing to another engine and require basically rewriting the whole game....

Vostorn

profundidob16_ESO wrote: »

Now imagine you're in a zerg in cyrodill and want to cast that same circle of whatever. In order to determine wether this effect will be drawn or not your cpu first has to calculate wether you are capable or not which is dependent on wether the stun launched on you by the guy behind you succeeds or not which in turn depends on....you see where this is going. 20+ people in a zerg all affecting each other with buffs and if enemies with debuffs, dmge, stuns and other cc...all depending on each other. All this stuff has to be calculated within 1 and the same main thread and that is why 1 thread running on only 1 core of your cpu will completely bottleneck in a zerg and drop your fps because this is after all a nonstop continuous process that happens multiple times per second

Well, I don't really understand this.

The server has to calculate if you are able to cast or not. This obvious. If it is client side, it could be easily cheated.

So, on the client side, this is going as "Try to cast X skill - wait for server response - server agreed -> start cast animation".
FPS shouldn't drop while waiting : all other animations can be still cast easily. I truly don't see how an animation needs to be waited before another animation is started. If there are, I'd be happy to see an example.

Now, on the server side.
Each monster/player character is an object. Should these objects freeze other objects in order to be thread safe ? I don't see why.

These objects have attributes (position, stats, etc). Most of these attributes are immediately gettable without computation.

Now let's take an example in Cyrodiil where a player (A) is casting a skill with direct damage on a target player (B) (or even a mob in a dungeon, it should work the same). Let's say to simplify the the skill is truly instant and there are no delay between the start of animation and the damage being inflicted.
A's computer will ask the server to start the skill. Server must compute if A can do it. It's the thread of the object A (the object instancing player character A) which will calculate it. If it can, it tells A's computer that the animation can start and sends a message to B with the parameters allowing to calculate the HP los. B will calculate it with its own thread.

A & B computations are linear and very fast. I would take my laptop (dual core i5 2,6GHz) 1µs for each one. Even with 1000 people focusing one poor guy, you could not saturate a thread (unless they use some hacking tool to spam actions). Even if they proceed, only that guy would appear laggy and not the whole server.

I'm a student developper so I may miss some things but I'd be happy to know why.

zParallaxz

Vahrokh wrote: »

Vaoh wrote: »

Turelus wrote: »

In theory any of the issues due to CPU load yes (so less stuttering).

It won't fix Cyrodiil lag suddenly though as that's more about server calls that your own machine.

Would that apply to performance-intensive scenarios that aren't based on server lag? Like Vet trials. Rakkhat HM, 4th boss vHoF, Assembly General HM can be especially low on FPS.

It would be very nice to see improvement there.

It heavily depends on how much and how well they have re-engineered the graphics engine. It is pretty hard to:

- streamline sequential events into a parallel process, especially if the former used to be the whole game until recently.
- share equal load between processor. It's "easy" (actually, it's still hard) to take away ancillary tasks from 1 processor and assign them to the others. But in this case, processor #1 is still way more burdened than the others and is still a bottleneck. Just less than before.
- sharing 100% workload between 4 processors, does not yield to having them 25% workload each. Each thread is different and does not have to process the same stuff. Then there are various inefficiencies and queues (for example, processor #2 completes a task but #3 is still busy and processor #1 can proceed only when both #2 and #3 are done).
End result, if you have 4 processors and had 20 FPS today, after patch you won't have 80 FPS. You'll have 40, perhaps 50. It's still a tangible enhancement, though.

profundidob16_ESO wrote: »

Cinbri wrote: »

Turelus wrote: »

In theory any of the issues due to CPU load yes (so less stuttering).

It won't fix Cyrodiil lag suddenly though as that's more about server calls that your own machine.

But will it fix problem that with 8 cores i have 15 fps as soon as i fight zerg?

I do dare to call myself an expert with over 20 years experience in hardware and performance troubleshooting. Identifing bottlenecks has become second nature to me so naturally I could not resist troubleshooting this exact issue extensively in the past. Here are my findings and an attempt to clarify in layman's terms:

The first prerequisite to meet in order to maximize fps is have sufficient GPU performance. That is a joke since the latest generation of top end nvidia cards (1070ti,1080ti) who all blow this custom modfied yet dated hero engine away. In other words as long as you have anything close to the latest generation of high level gpu hardware gpu performance this prerequisite is off the table

The second prerequisite is the real bottleneck: It is the CPU in combination with the GPU and memory, having to run in a circle between all 3 to transfer data as fast as possible and this in continuous process multiple times per second. In computer hardware terms this is the single-core performance of the cpu and front bus frequency as well as memory timing and frequency.

However the reason all the stress is on that part of the hardware is because of the game's code as perfectly described by forum user @Vahrokh. Some jobs as part of the continuously running code are just very hard or even impossible to split off onto another thread (read: another core of your cpu) because they contain active dependencies on elements in the main thread.

Think about it this way: Imagine you are alone inside your house in ESO and the game has to display the animation of you casting a circle of whatever this task can easily be launched on a different core or thread of your cpu as the animations of the walls, the floor, the objects inside it, all rendered per second nonstop in time. So all cores can be used effectively without ever bottlenecking 1 core and all the load is handle with ease by the gpu, resulting in max fps your monitor can handle

Now imagine you're in a zerg in cyrodill and want to cast that same circle of whatever. In order to determine wether this effect will be drawn or not your cpu first has to calculate wether you are capable or not which is dependent on wether the stun launched on you by the guy behind you succeeds or not which in turn depends on....you see where this is going. 20+ people in a zerg all affecting each other with buffs and if enemies with debuffs, dmge, stuns and other cc...all depending on each other. All this stuff has to be calculated within 1 and the same main thread and that is why 1 thread running on only 1 core of your cpu will completely bottleneck in a zerg and drop your fps because this is after all a nonstop continuous process that happens multiple times per second

so for example with an Intel 7700K/8700K cpu @5+Ghz, a front bus of 4.5+Ghz and memory 3600Mhz@CL15 or better all your current problems go away already as it is and you won't drop lower than 50fps ever in zergs, dolmens or trials, even with 40+ peeps on your screen. But with let's an average amd on a low frequency it will be normal to see drops to 15fps in the same situation because that hardware is terrible at single core performance.

The promise of better multicore support in update 18 is basically an attempt to yet to split off some dependencies into different threads by optimizing the code, even though that's very hard. Based on how successful this is you could realistically see up to 30% increase on your lowest drops or only 10%, it all depends on the code

But if you have 15fps in zergs as it is your hardware is not up to the task and even 30% increase on that won't make it fluent. So with your particular hardware the answer is....no

Can explain how this will affect higher end consoles like Xbox one x with an external ssd.

exiars10

profundidob16_ESO wrote: »

I do dare to call myself an expert with over 20 years experience in hardware and performance troubleshooting. Identifing bottlenecks has become second nature to me so naturally I could not resist troubleshooting this exact issue extensively in the past. Here are my findings and an attempt to clarify in layman's terms:

The first prerequisite to meet in order to maximize fps is have sufficient GPU performance. That is a joke since the latest generation of top end nvidia cards (1070ti,1080ti) who all blow this custom modfied yet dated hero engine away. In other words as long as you have anything close to the latest generation of high level gpu hardware gpu performance this prerequisite is off the table

Oh, look, another Team Green propaganda. Like Radeon cards doesn't exist at all.

This game's graphics can be maxed out with GeForce 1060 3 GB and Radeon RX 470 cards without any problems and with even forced better types of AA via drivers. Source: me and my friends. ESO needs fastest possible CPU IPC and that's it. There is no need for Vega or 1070+ graphics cards. Total overkill.

zParallaxz wrote: »

Can explain how this will affect higher end consoles like Xbox one x with an external ssd.

Xbone X still uses weak Jaguar cores. SSD helps alot with loading but it has nothing with frame rate.