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

[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.