Definitive Proof of Poor Optimization, Requesting a Fix/Work-Around

[InVizO]

As you can see in the image, I am in Uldah at 1440P Ultra, and unless I set everything to Normal or Less, I don't get 60 FPS (see the yellow 45 in the corner), this problem carries over to other large battle engagements and populated fates.


I7 3770K
GTX 780
256GB SSD
16GB DDR3
+ overclocking

and as you can see I have NO bottleneck, nothing is over 80%, and a GTX 780 should never get to 75% in the first place.


edit: ctrl + middle mouse wheel forward to zoom in.

[Squa11_Leonhart]

Welcome to Direct3D9.

What you are seeing is a result of DirectX overhead, long known to exist in Direct3D9, reduced to a degree in D3D11 and being heavily focused on in Direct3D 12.

The cause is dynamically updating effects such as reflections and shadows, coupled with the spamming of thousands of new draw calls everytime a new effect occurs (or the scene changes in some way) saturating the cpu core that the main game engine is running on.

Unfortunately, there is no safe way (and few that actually improves fps) to multithread a direct3d9 engine where effects are used to such an extent, you would end up introducing thread locking which would drop fps to single digits or hang the process.

[InVizO]

Welcome to Direct3D9.

What you are seeing is a result of DirectX overhead, long known to exist in Direct3D9, reduced to a degree in D3D11 and being heavily focused on in Direct3D 12.

The cause is dynamically updating effects such as reflections and shadows, coupled with the spamming of thousands of new draw calls everytime a new effect occurs (or the scene changes in some way) saturating the cpu core that the main game engine is running on.

Unfortunately, there is no safe way (and few that actually improves fps) to multithread a direct3d9 engine where effects are used to such an extent, you would end up introducing thread locking which would drop fps to single digits or hang the process.

Thanks for that info.

You would think that after a year of promising a native x64 DX11 client they would deliver something...

Does the PS4 run on this mess or did they get a newer client?

[Syx]

Thanks for that info.

You would think that after a year of promising a native x64 DX11 client they would deliver something...

Does the PS4 run on this mess or did they get a newer client?

The PS4 uses proprietary combination of two languages, both sitting on a linux OS. One api is low-level for direct hardware access, the other is high-level for broader software graphical functions. It also has it's own shader language. There are very few components in common with D3D9.

[Nekodar]

The PS4 uses proprietary combination of two languages, both sitting on a linux OS. One api is low-level for direct hardware access, the other is high-level for broader software graphical functions. It also has it's own shader language. There are very few components in common with D3D9.

It's actually a freebsd derivative, not a linux os. AFAIK.

[Syx]

It's actually a freebsd derivative, not a linux os. AFAIK.

You're probably right. I know it's a fork of some *nix derived OS.

[Squa11_Leonhart]

The dx11 client was shifted from same time as the ps4 launch till sometime after the chinese client.

[Syx]

SE stated they plan to release the DX11 client in 2014, but that is as accurate a release date as they provided. The cpu/gpu usage percentages are basically the indication of the amount of overhead involved in D3D9 rendering. How amusing is it that 25-50% of the cpu/gpu time is spent waiting for data to be passed around the rendering pipeline. You may even notice a single core up around 90% with the others at 60%. That would be the D3D9 thread synchronization process, so multiple threads don't attempt to lock the same asset and perform the same work.

[Squa11_Leonhart]

SE stated they plan to release the DX11 client in 2014, but that is as accurate a release date as they provided. The cpu/gpu usage percentages are basically the indication of the amount of overhead involved in D3D9 rendering. How amusing is it that 25-50% of the cpu/gpu time is spent waiting for data to be passed around the rendering pipeline. You may even notice a single core up around 90% with the others at 60%. That would be the D3D9 thread synchronization process, so multiple threads don't attempt to lock the same asset and perform the same work.

^ This

I was just too tired to explain it to such a degree.

And these are 4 images demonstrating what threads are eating the cpu.









As you can see, when thread 113872 goes UP, thread 148420 goes down.

However, 154160 also increases 2% which might be where the reduction in 148420 comes from, so its hard to say which thread is actually the one causing performance to dip.

I lean towards 113872 as nvd3dum.dll!QueryOglResource is a synchronisation handle.

[CHA0S_DECEPTI0N]

Both the PC and PS4 Versions have optimisation Issues. And I think this is largely a result of object occlusion.

Take for Example: when out in the field You see on the Map a Large FATE that is in progress, but ingame you are too far away to see it. if You stand on the spot and pan the camera around it will be smooth, but when panning past the distant FATE, You will notice the camera judders.

That tells me that the FATE is being processed even though its not actually in View. It would be great if SE would use Occlusion for distant events, as this would improve performance.

Similarly, when taking part in a large FATE, everything outside the FATE, that is at a distance should be Occluded. This again would improve performance.