Hi, I think this issue persists in Arma 3 and Arma 2 as well and I'm hoping it will be solved in DayZ.
Here is a video I made explaining the issue http://www.youtube.com/watch?v=9ssjr36NKTE
Basically the more objects being rendered on screen the less GPU usage.
System Specs:
i7 4770k @ 4.0GHz
2x GTX 780 Ti SLI
256gb Samsung 840 Pro SSD
Cross-Post from YouTube:
Nice work there. I'd say this is a pretty bad bug in the ArmA 2 engine. Fixing this might actually help improve the really bad frame rates the game is known for. Since it's dropping GPU utilization without increasing CPU utilization, it's either file IO which is blocking the main rendering thread or (more likely) bad resource sharing code (locks/mutexes).
It's not a bug, it's the way the game works, just like most other games only it's more noticeable in Arma because of the massive maps.
The server needs to tell the client what it sees and what happens, the client then based on this renders the image. Games sometimes render based on approximations, Arma doesn't to this as much because it's a simulator at heart.
Most of the time you wont notice if a game uses guesswork to render, but in simulators its a big no no, the reason is because when you see a hit in Arma when you shoot you see it because the server sees it, not because your client guessed it.
This is the difference against Battlefield, CoD, CS that work on FPS/flow > accuracy, this is the part of their netcode everyone is screaming about, you shoot someone, you see blood, a hit, a clear shot but it doesn't hit, you miss because your client guessed and was wrong or you or someone guess and get it right but at the wrong time and someone shoots you even though your client says you gotten behind the wall etc.
The Real Virtuality engine doesn't work this way, it works on the opposite principle that accuracy > FPS/flow, this makes the client FPS bound somewhat more by the server FPS and the network communication speed. If your view includes more data needing to be verified by the server and taken in to account the limitations of the server and the network traffic will lower your FPS.
And even if you got a 1Gbit/sec fiber connection and playing on a super server with a super computer you are still limited by the netcode limitations which has to take in to account all the other players that might not have the same as you.
The idea is that every client should get a fairly identical amount of data and so on to make it an even playing field, a simulator has to show the same image to you and to your opponent or its not doing its job.
I'm not sure it has much to do with what the post above is saying, but this needs to be addressed or the game will always run like shit. The engine uses your CPU for objects rendering and it needs to use the GPU more for that. I'm no game designer/coder but I'm sure it can be fixed.
While i have to agree that there are performance issues, there is something you can try as a temporary fix.
Check this page out: http://opendayz.net/threads/dayz-performance-increase.17704/
At the time of writing, the forums seem to be down for maintenance, but i've added a link to a cached version;
Holok I don't want to offend you, but what you say is only half true. The other half is bullshit from somebody who has never actually written a line of code, yet networking, graphics rendering or game engine code.
I'll leave this up for the devs, they probably (hopefully?) know what they are doing, but to follow up on my stand: the rendering loop can (and should!) continue to render the game even if the simulation has not updated since the last tick. The server not keeping up or a high delay connection should cause something gamers usually refer to as "lag". It should not cause the frame rate to drop or the GPU utilization to drop. If that happens, it is a bug. Mind you: bad game engine design might be at the core here, nevertheless, bad engine design should also be considered a bug.
Holok, could you expand on what you're saying? Because, as I'm currently understanding it, I don't think what you're saying is correct.
The RV Engine very much works on approximation, which is how desyncs and net lag are dealt with. Movement is interpolated and isn't necessarily updated by the server every frame, unless it needs to be.
The game state isn't guaranteed to be displayed identically to everyone. I was playing with a friend just yesterday who was experiencing network lag, meaning, for whatever reason, we could see where he was, but he couldn't see us - obviously in his game state, we were somewhere further back.
The server also isn't *needed* to display the world. This is why we can move around in desyncs and, more noticeably, when the server restarts and there's no connection at all.
And DayZ does use client-side hit detection, which is why we get problems such as this: #818
It's true that RV also uses approximations but it's not as prominent as other fast game FPS.
If you for example look at Counter Strike Global Offensive you got a similar setup up only the client is allowed to approximate more. The server Tick/FPS on their normal servers are 64 and there max kb/s is 8K I think.
As the client isn't FPS limted by the server you can still have your 300FPS on the client only you often see bloodsplatter but don't get a hit. If a server runs with 128 Tick/FPS and I think it's 20K bandwidth for each client then this is much less an issue.
The difference with RV is that it wont let the client approximate as much, sure you still need some and I think Rocket has said he wants the servers to at least have a server FPS of 15.
You do need approximation for network games to limit the bandwidth usage etc, but if you compare RV to the source engine, a 64 tick CS:GO server doesn't limit your FPS but if you join a slow server with a bad connection on Arma your FPS takes a dip.
Whether Holok is correct or not, which I really doubt; It has nothing to do with the issue of the game using your CPU for models and shit, and not utilizing the GPU, and there's no way to force it.
Please consider to force server providers to set automatic server restarts every 3-4 hours as a temporary fix while we wait for optimization. It helps.
From experience with ArmA servers (and DayZ is using much the same techniques) the factors relating to local fps are multiple and varied, and for the most part bear no relation to your own hardware set up. A better indicator is to look at the player with the worst connection to the server. That seems to be the overiding factor.
This is why we sometimes limit connections based on ping.
As I have stated before there is probably either bad thread synchronization or IO (e.g. optimistic stream reading) happening on the rendering thread. Other blocking operations should be considered as well of course. The fact that GPU utilization drops without CPU utilization spiking is a clear sign that some operation is suspending the rendering thread and waiting for a system interrupt before the rendering thread is resumed (usually happens during blocking IO like reading from a file or over-reading from a network stream and in thread synchronization code).
Of course this is pretty much just a guess, an actual analysis would require knowledge and access to the source code, a debugging build and a profiler.
btw, this issue here http://feedback.dayzgame.com/view.php?id=818 actually hints at that they might be using streams (TCP) for ephemeral game state data. Reading from streams can easily block if you're not careful.
I'd like to know what your "fps drops in half" is. The human eye at max can only see 60 fps. Normal conditions 30 fps. So if it's less than 30, it's probably your rig, since the entire map is already loaded onto your cpu minus the spawns which are handled server side. Any graphical issues are going to be related to your rig. Other than spawns of course:)
DeadlyDanDaMan: Wow, how much L3 cache does your CPU have if you can load the entire map onto it (minus the spawns - of course)?
Also, you might want to watch the video first that the OP posted if you want to critique his report.
@DeadlyDaDaMan First of all the human eye doesn't see in fps, secondly the human eye can (and clearly) see the difference between 60 and 120 fps, provided the monitor actually supports 120Hz (or more)
As for the issue: I run a 780GTX SLI setup and run at 30 fps near cities and 20 fps in cities. Absolutely awful performance, but I suspect it will be optimized at some point in the future. Fact remains though, it needs to be improved.
In my opinion this is one of the most important things that the devs should be working on.
When I saw the system requirements to play this game I thought I would be able to run the game smoothly at least on the lowest settings but I'm having a hard time trying to play the game with a extremely low FPS.
My computer is not very good but that doesn't explain the 9 FPS I'm experiencing inside Cherno or Elektro. When I run some hardware monitoring programs while running DayZ they show an usage of about only 50% of my GPU, leaving all excess rendering to my processor which is unable to process everything.
I don't mind waiting for months until the performance is improved (it's on alpha after all), but if it doesn't, I'll have wasted my money because I wouldn't have bought the game if the system requirements provided showed I wouldn't be able to run it decently
@ ripzeus made absolutely no difference when I changed mine, I think you're just experiencing the placebo effect.
This line has made being in cities a little better, this is not a "fix all" and only upped it enough to were cities are in the 30-40 FPS now.
I did post here http://feedback.dayzgame.com/view.php?id=247
My PC:
AMD FX9590 CPU @ 5.5GHz
CORSAIR Vengeance Pro Series 32GB Windows 8 Enterprise 64 bit Geforce GTX Titan 6GB
DayZ sits on a Kingston HyperX 240GB SSD
I lag even at low settings in the city's. The difference between Very High and Low is maybe 2 - 5 FPS difference, I go from solid 60+ FPS while in the woods with my GPU usage at 56%, to 20-30 FPS with GPU usage at 23% in cities.
Something is a bit backwards. :D
I was able to push a little more FPS outa DayZ with this launch line in steam.
-nosplash -noPause -world=ChernarusPlus -cpuCount=8 -exThreads=7 -maxMem=8192 -maxVRAM=6144
Remember to MATCH this to your system or you will do one of two things, crash or lower FPS.
@ ripzeus the comandlines are mainly for lower-midend computers. For example with my i7 4770k @ 4,5Ghz and OCd GTX780 I saw a mere 2-5 FPS increse.
But on my laptop with i7 2670qm (locked at 3,1Ghz) and GT630m@780mhz/990mhz it gave me up towards 15 FPS in difference.
As for the perfomance problems in general, its my opinion that it shouldve been 2 of the things sorted out before release(First shouldve been Zombies). Its not like the problems just appeared out of nowhere, theyve been there for the longest time and I am pretty sure that BIS know about them, but are throwing cowboyhats and paintable guns(i.e late beta/post release stuff) on the problem to take the focus off it.
I wonder if when the migrate into BETA phase they migrate the entire game to ARMA 3 Engine.. and hopefully solve 90% of these Graphics & Other stupid issues with the unstable garbage ARMA 2 engine.
to the op: the mechanism you described is well known and doesnt have much to do with netcode. It is in fact one of the oldest issues with game engines like arma. Most folks believe that the GPU is the most important factor in rendering 3D scenes; they are wrong. The CPU needs to do most calculations, in fact, it is the CPU that continually checks and refreshes the positions of all the "points" in a 3d space which then forms up your "objects". The GPU task, is basically just to apply the texture to the objects that the CPU has drawn and moved. So the equation is very basic: the more objects appear on the scene, the more calculations the CPU has to do. More calculations means slower output from the CPU. And in fact, the GPU work is not increased much, since the textures which make up your scene are already stored in its memory. As you can see, this equals to a GPU that gets less work to perform, if the CPU is under load. Don't let others fool ya into thinking that netcode is responsible, this basic principle is as much as valid in single player games / apps
You are absolutly right in what you say, but that still doesnt excuse the lack of CPU utilization. At best my CPU works at a 25-30%, and that is where the problem persist.
I think this FPS-Drop when looking to the forest ist also because of this loot-render-engine.
This engine loaods/renders loot you cannot see (even in houses..). So, I think it's because of this. There is also a big report here with this problem.