Digging a little deeper into Arma 3 performance

[brightcandle 114]

Over a year ago I posted the following image:

https://dl.dropboxusercontent.com/u/3638175/Capture%20Palagia.jpg (612 kB)

Showing that performance was CPU limited and dominated by the simulation and the rendering and it wasn't very multithreaded. Well SweetFX 2.0 alpha came out a few days ago and one of the new aspects it adds is a draw call count to show how many times the graphics API of DX11 is called. Most modern games will typically use 4000 calls to render a frame, the absolute limit is somewhere around 8k - 10k. Takes a lot of effort to get there and its often the limit of RTS games.

So based on the rendering time above we might anticipate that Arma 3 was very draw call heavy, the CPU spends a lot of the time on it. So I did an initial look in the editor on an empty Altis and I saw about 1000-1200 draw calls. That is impressively low considering how the game looks. But it also rules out DX11 being the dominate time factor for the rendering aspect on the client side performance, it must be BI code calling onto the API that is slow and not the API itself. Given a much more efficient renderer we should be able to have 8x the detail in the scenery.

For now I'll wait until our weekly game and get some in game counts with some real players and more stuff going on but there is no real reason to suspect it will suddenly jump really high considering 1000-1200 equates to 60 fps. I would recommend against trying this in multiplayer servers yourself as you might get banned for hacking as it is an injection tool and its probably not on the white list yet. By all means try it locally with benchmarks and such and see what you get, more work is obviously necessary to determine the exact numbers but it doesn't look like its Arma 3's issue, thus Mantle nor DX12 would help Arma 3 performance at all.

Edited February 11, 2015 by BrightCandle

[brightcandle 114]

I have dug a bit deeper still. This time I have a GPUView (its a Windows performance toolkit profiler for DirectX) picture that shows how Arma is utilising the resources of the GPU and CPU in regards to the queued and work done.

What the image shows is 42milliseconds representing 2 frames of the game and its running at 50 fps (editor single unit and nothing else). Time runs left to right and the blue lines are vsyncs (I am not running with vsync on here so they just give you an idea of time).

There are two areas to focus on, the first is the GPU queue that shows the work packets submitted to the GPU and how long they take to process and how long they wait (if they are stacked above one at the bottom they are waiting). The second is the CPU context queue for the arma3.exe process.

In the GPU hardware queue you can see we never get more than 1 call waiting within any one frame and the GPU spends a large amount of the frame idle. We can see that in the stats listed in the top right, it works for 24.7ms which is just 60% of time. The gaps we see are moments when the GPU is not being utilised.

In the CPU context queue we see work queued up inside of DirectX, and here again we can see the CPU is not used all that heavily. There are large amounts of gaps between the various calls and the associated calls that ultimately get made to the hardware. Usage here is just 61%.

In summary what this trace shows is that the game is in no way limited by the GPU hardware or DirectX. There is space in the DirectX CPU pipeline for more and there is space on the GPU for more as well. This game must be limited outside of the graphics API. We kind of already knew this but I don't think anyone has used Microsoft's debugging tools to confirm it before.

Edited February 11, 2015 by BrightCandle

[windies 11]

Interesting but basically just confirms that the engine is the problem in a sense and it's not some API/Hardware deficiency.

[I give up 152]

I have dug a bit deeper still. This time I have a GPUView (its a Windows performance toolkit profiler for DirectX) picture that shows how Arma is utilising the resources of the GPU and CPU in regards to the queued and work done.

https://dl.dropboxusercontent.com/u/3638175/gpuview%20Paragaia.png

What the image shows is 42milliseconds representing 2 frames of the game and its running at 50 fps (editor single unit and nothing else).

Your test was performed with which Island (Map)?

If I am allowed, I would suggest to perform a similar test but using 10 Vehicle Units (AI in formation) and 20 Men Units (AI in formation) with Altis Island (Map), placing yourself in a position where you are unable to have visual contact with the Units.

[calin_banc 19]

Try and make the test in a city, with roughly 5k in draw and object distance, terrain and object detail high. Increase the view and object view even more and see how it goes with the draw calls. If the render is independent, then it the draw calls should increase as the performance drops.

[St. Jimmy 272]

You should also test this map http://forums.bistudio.com/showthread.php?182817-Unnamed-terrain-12-8-km-%28Ukraine%29-early-wip It's very heavy for GPU (bottlenecked mostly by GPU and I've GTX970) and adding AA brings even high end GPUs to have some mercy so they could run at 60fps.

[brightcandle 114]

I tested altis in the middle of the primary city, so this is about the most object heavy you can get without adding units. I did a similar test in open ground and saw similar results. This graph is typicaly of all the scenarios I saw. As you increase the in game units the usage of the GPU decreases and this graph changes as you would expect, bigger and bigger gaps on the CPU and GPU side of things.

[I give up 152]

I tested altis in the middle of the primary city, so this is about the most object heavy you can get without adding units. I did a similar test in open ground and saw similar results. This graph is typicaly of all the scenarios I saw. As you increase the in game units the usage of the GPU decreases and this graph changes as you would expect, bigger and bigger gaps on the CPU and GPU side of things.

My intention is to see the difference in GPU and also CPU behaviour when you are visualizing the units and when you are not. I am curious to know if there is such space for graphics rendering when your graphics card is rendering also the units.

Also if you could add some smoke mixed with units, I would be interested in know if there is space left for rendering.

Edited February 12, 2015 by Bratwurste

[St. Jimmy 272]

I tested altis in the middle of the primary city, so this is about the most object heavy you can get without adding units. I did a similar test in open ground and saw similar results. This graph is typicaly of all the scenarios I saw. As you increase the in game units the usage of the GPU decreases and this graph changes as you would expect, bigger and bigger gaps on the CPU and GPU side of things.

I gave that Ukraine map as an example because it should be one of an extreme example because there's a lot of vegetation around tightly everywhere in the small town and vegetation in Arma is very GPU heavy so I wonder if that gives any different result. I think there's nothing close to that in any other map. I would say you should see pretty big draw calls in that place but I'm not 100% sure.

[calin_banc 19]

Depends on how many distinct stuff you have to render. Same (textures) can be rendered in a single draw call -

1300 boxes rendered in 1 draw call, running on a laptop GPU (Nvidia Gt 525m). All the geometry is rendered once for the main view, once for the reflections and three times for shadow maps, which shows how much performance can be gained.