Engine Stuttering: Related to texture settings and?
Dictator93
Join Date: 2008-12-21 Member: 65833Members, Reinforced - Shadow
Join Date: 2008-12-21 Member: 65833Members, Reinforced - Shadow
Hi Everyone!
Being obsessed with good performance and under Ironhorse's watch I have decided to try and delve into the engine stuttering that NS2 suffers from.
To get some things out of the way let me first list some points that this "stuttering" is not.
1. This stuttering is not related to stuttering from pre-caching
2. This stuttering is not related to HDD vs. SSD debates
3. The stuttering is not related to SLI or mGPU.
OK so what relevant factors are tied into this?
1. Texture settings: High textures stutter, no matter what (on my RIG).
2. VRAM amount. I have access to 1280 MB VRAM, of which windows most definitely uses about 50-100 mb. NS2 pushes this over the edge some times.
3. GPU utilization. This means how much your GPU is being pushed. High GPU utilization is pretty much always a godo thing (unless you are in a menu). This problem is exacerbated by high GPU utilization.
OK, my test methodology is as follows: Run around biodome, take the same path, takes about a little more than a minute.
1. Test the game on the lowest settings @ 1080p with low textures.
2. Test everything on the lowest settings @ 1080p with HIGH textures.
3. Test everything at the highest settings @ 1080p with low textures.
4. Test everything at the highest settings @ 1080p with medium textures.
5. Test everything at the highest settings @ 1080p with HIGH textures.
I am emphasizing the high textures so much here because that represents a special case. High textures are not only associated with stuttering on my config, but they are also causing a VRAM problem that may or may not be related to the general stuttering.
Results for the different scenarios, respectively:
1. on LOW, with textures on low there is no stuttering really at all. GPU Utilization is incredibly low. VRAM utilization is @ 400 mb.
2. on LOW, with textures set to high there is stuttering when rounding corners. GPU utiliation is incredibly low. VRAM Utilization is @ 1270 mb.
3. on High, with textures set to low there is NO stuttering of any reasonable amount that I have noticed. GPU Utilization is high. VRAM Utilization is at around 500 mb.
4. on High, with textures set to medium there is some stuttering occasionally when rounding corners. The waiting for frame buffer though is relatively low and the stutter is less severe. GPU Utilization is of course high. VRAM Utilization is at around 700- 800 mb.
5. on High, with high textures, stuttering occurs so frequently that the game is unplayable. Not only while rounding corners as new textures load in, but also during general movement sporadically. GPU Utilization is High (with the game performing well (100fps or so) excluding the stutter). VRAM Utilization is near my 1280 mb limit.
What have I deduced from this? Well here is a picture of my frame rate at different texture settings when everything is otherwise set to High.
When my VRAM utilization is at around 1270, my FPS is eratic (toward the end of the graph, when I set textures to high). going from 120 one second, to 50 the next. When the textures are set to low, my Frame rate fluctuates, but within OK bounds 100 fps - 150.
Similarly, here is the difference between everything on high, with medium vs. High texture settings:
The red portion of the graph (high texture settings), shows incredible differences in FPS constantly. The average FPS drops to 50 for example because the 1 frame when the stutter occurs takes about .5 to .7 seconds to display, therefore dropping the average.
The blue portion of the graph (medium texture settings), shows fluctuating FPS differences at the same points as the red portion, but they are far less severe. Note here that my VRAM limit is not being reached with medium textures.
WHAT DOES THIS ALL MEAN?!
1. High GPU utilization with increasingly higher texture resolution induces stuttering. Even when the VRAM wall is not being reached. Even medium textures stutters when rounding corners as the above graph shows.
2. Low GPU utilization scenarios only stutter with High texture settings. This shows either that NS2 is misallocating its VRAM allowance with its texture streaming @ high textures. Or that something is broken with the high texture setting causing texture streaming to stutter the game.
WHAT DO I THINK NEEDS TO BE DONE?!
1. NS2, no matter what texture settings, should never cause HDD thrashing and VRAM breaking. Texture streaming exists to prevent this whilst maintaining texture quality. The downsides to streaming should be temporarily muddy textures due to a smaller VRAM cache. NOT stuttering and HDD thrashing.
2. The stuttering that is tied to texture res (even on medium) and High GPU utilization shows that the way textures are brought in to be rendered (streamed) has some performance problem. Regardless of VRAM amount. The stuttering from rounding corners is when the game loads in new geometry (vis portals) as well as new textures. This needs to be looked at.
Being obsessed with good performance and under Ironhorse's watch I have decided to try and delve into the engine stuttering that NS2 suffers from.
To get some things out of the way let me first list some points that this "stuttering" is not.
1. This stuttering is not related to stuttering from pre-caching
2. This stuttering is not related to HDD vs. SSD debates
3. The stuttering is not related to SLI or mGPU.
OK so what relevant factors are tied into this?
1. Texture settings: High textures stutter, no matter what (on my RIG).
2. VRAM amount. I have access to 1280 MB VRAM, of which windows most definitely uses about 50-100 mb. NS2 pushes this over the edge some times.
3. GPU utilization. This means how much your GPU is being pushed. High GPU utilization is pretty much always a godo thing (unless you are in a menu). This problem is exacerbated by high GPU utilization.
OK, my test methodology is as follows: Run around biodome, take the same path, takes about a little more than a minute.
1. Test the game on the lowest settings @ 1080p with low textures.
2. Test everything on the lowest settings @ 1080p with HIGH textures.
3. Test everything at the highest settings @ 1080p with low textures.
4. Test everything at the highest settings @ 1080p with medium textures.
5. Test everything at the highest settings @ 1080p with HIGH textures.
I am emphasizing the high textures so much here because that represents a special case. High textures are not only associated with stuttering on my config, but they are also causing a VRAM problem that may or may not be related to the general stuttering.
Results for the different scenarios, respectively:
1. on LOW, with textures on low there is no stuttering really at all. GPU Utilization is incredibly low. VRAM utilization is @ 400 mb.
2. on LOW, with textures set to high there is stuttering when rounding corners. GPU utiliation is incredibly low. VRAM Utilization is @ 1270 mb.
3. on High, with textures set to low there is NO stuttering of any reasonable amount that I have noticed. GPU Utilization is high. VRAM Utilization is at around 500 mb.
4. on High, with textures set to medium there is some stuttering occasionally when rounding corners. The waiting for frame buffer though is relatively low and the stutter is less severe. GPU Utilization is of course high. VRAM Utilization is at around 700- 800 mb.
5. on High, with high textures, stuttering occurs so frequently that the game is unplayable. Not only while rounding corners as new textures load in, but also during general movement sporadically. GPU Utilization is High (with the game performing well (100fps or so) excluding the stutter). VRAM Utilization is near my 1280 mb limit.
What have I deduced from this? Well here is a picture of my frame rate at different texture settings when everything is otherwise set to High.
When my VRAM utilization is at around 1270, my FPS is eratic (toward the end of the graph, when I set textures to high). going from 120 one second, to 50 the next. When the textures are set to low, my Frame rate fluctuates, but within OK bounds 100 fps - 150.
Similarly, here is the difference between everything on high, with medium vs. High texture settings:
The red portion of the graph (high texture settings), shows incredible differences in FPS constantly. The average FPS drops to 50 for example because the 1 frame when the stutter occurs takes about .5 to .7 seconds to display, therefore dropping the average.
The blue portion of the graph (medium texture settings), shows fluctuating FPS differences at the same points as the red portion, but they are far less severe. Note here that my VRAM limit is not being reached with medium textures.
WHAT DOES THIS ALL MEAN?!
1. High GPU utilization with increasingly higher texture resolution induces stuttering. Even when the VRAM wall is not being reached. Even medium textures stutters when rounding corners as the above graph shows.
2. Low GPU utilization scenarios only stutter with High texture settings. This shows either that NS2 is misallocating its VRAM allowance with its texture streaming @ high textures. Or that something is broken with the high texture setting causing texture streaming to stutter the game.
WHAT DO I THINK NEEDS TO BE DONE?!
1. NS2, no matter what texture settings, should never cause HDD thrashing and VRAM breaking. Texture streaming exists to prevent this whilst maintaining texture quality. The downsides to streaming should be temporarily muddy textures due to a smaller VRAM cache. NOT stuttering and HDD thrashing.
2. The stuttering that is tied to texture res (even on medium) and High GPU utilization shows that the way textures are brought in to be rendered (streamed) has some performance problem. Regardless of VRAM amount. The stuttering from rounding corners is when the game loads in new geometry (vis portals) as well as new textures. This needs to be looked at.
Comments
When the stuttering occurs, I can log some higher loadtime on the dds files. This can easily count up to 20ms per dds file. Odd thing is, it does not seem to be the same DDS files!
I attached a xlsx file from 2 runs of not similar length. But it illustrates that it is not the same files always.
If you countup the same dds files, you will often see the values reach something like 0.020ish which is 20ms.
I tried to order it a bit in nice reading material, but eventually couldnt be bothered anymore as the time I usually spend in excel is 0, and I forgot where all the bloody options are. :P
I had a second look in my process monitor saves.
it seems much of these slower loading processes are getting paged. So a hypothesis.
gpu gets more full > dumps stuff to ram > which gets paged > slow?
Perhaps ill ramdrive the dds later to check.
Note that this is written during win XP BUT should still be relevant as some limits simply not change.
I will copy paste some stuff but the entire page is gold:
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
Now to respond to @Soul_Rider.
Windows is always paging to manage memory. So your stutters can be because ns2 is trying to pull something out the page file which it did not keep in physical memory.
See album:
http://imgur.com/a/bo54S
pic1: gpu dedicated memory is close to cap but not hitting it. Note the commit charge is quite larger.
pic2: ns2 is using a lovely 1.4GB
pic3: Note the difference between the physical size (RAM) and the virtual size (RAM+pagefile). Page faults is the amount it paged it its lifetime. Page Fault Delta is the amount of pages in its lifetime.
Note it also shows other stuff which, in theory, could hit limits but is far below. (like GDI)
pic4: system wide GPU. Showing ns2 is pretty much having it all.
pic5: some IO spikes, usually related to the harddisk. Guess that moment had some nifty paging!
pic6: system physical & virtual memory in use. Note while I use 3+ GB of physical memory, memory as a whole (including pagefile) is already at 5GB!!
I have 2.3GB of physical memory left. (It just occurred to me that it show more info if I wasnt to lazy to loadup symbols first)
So the question would be.
HOW much are you paging?
Is it happening during stuttering?
Incase anyone wonders, NO you do not want to disable the page file. Programs use a forsaken amount of memory. Like LOADS. The reason you have free memory IS because it pages. Depending on what you do, you would hit out of memory way to fast!
Options would be either to speedup paging (SSD, I use, still stutter)..
Or see (devs) if they can make certain stuff a higher memory priority so it gets paged out less fast. (assumption)
I myself have been able to link my stutters to a increase in DDS load times, which seem related to paging. As paging to a SSD is still loads and loads slower then memory...
Odd thing is, why should it matter? The game should show some vague textures or something if its not done loading.
So yes, it could be a correlation as more memory usage includes much more paging.
EASY to test if you are somewhat techy!.
http://www.sysinternals.com
grab process monitor and process explorer.
Set monitor up with a filter for path contains .dds. Also set it up to monitor a duration of like larger then 0.00099 to filter out the quick loading dds.
Run the game.
Keep process explorer open. Tab out after crashes or spikes and check the memory values in process explorer. Note you can click a process properties before you actually load into a map for faster looking.
Great posting. As I mention in my OP, the texture streaming should prevent stuttering... not induce it... it should display muddy crap textures... not stall the game.
Great to hear the .dds pulls (most likely from paging) seems related. I will try your system to monitor it to see if that is the same behavior as on my rig.
http://imgur.com/a/FWZGj#0
I tried my best to break the 2GB virtual size limit. Either I cant do it solo, or ns2 just wont let me.
tbh it makes me wonder if these programs truly are using more then 2GB per program as a 32b app. Then again, could just be because its not using more.
I will edit when I tested this with another game.
>edit.. one game down and I couldnt even get close to 2GB in another shiny single player game.
Guess I shall try skyrim tomorrow orso. Modded the crap outta that one.
Ok so skyrim used far less then I hoped. :P
I was unable to push ns2 further then 2GB although in theory on 64b it should be able to if needed. (dont know if it actually does, but it should)
Yes, the current build is flagged large adress aware, I checked.
Stuff I DID notice!
http://imgur.com/a/54gLQ
* regardless of system GPU memory and Committed GPU memory, ns2 stutters. I had it happen on both screenshots. It seems as the memory use is around 1.1. Which very roughly seems to correspond with around 70% use. (No I didnt calculate this through but my vidcard program from gainward said 70ish)
* Memory fragmentation on the ns2 heap is..everywhere. This can seem like its leaking memory (its not, its fragmenting.). It would also partially explain high memory usage.
Now the question remains.. IS this making the game stutter?
Fragmentation.. is bad. high loadtimes on ssd due to paging... is bad. But if this is the main cause of the stutter?
Its odd that vram doesnt get that close to max. On such amount of free vram, it should not stutter.
Ive been poking @Ironhorse to let more folk test this all, just to see if results compare.
I may test lateron today or in the week if I get the same results with lower texture quality! (omg, new idea)
EDIT..
results for more weirdness!
testing with low, medium and high textures shows no real difference in dds load times. (still paging, still suck)
http://imgur.com/a/8rSPK
* changing low to mid memory shows a noticable jump in both RAM and VRAM usage. (note in my tests I had no stutters on medium textures)
* both low, medium and high are gpu capped with around the same ms wait.
* the memory jump from medium to high is lower (but will rise in time due to usage). The vram shoots up like its nothing, same for gpu commit.
So we need someone who has more then 1.8ish GB of vram to test. My card wont allow further tests as I dont have.
It seems more vram related then memory. (although I still claim fragmentation is baaaaad)
I spent the first few minutes just running around the empty map trying to fill up the texture stream. Then created team buildings for both teams to try and max out the texture usage on eclipse. I hit 1400mb VRam texture usage. Not bad considering I only have a 1gb card...
I was profiling but not getting huge hitches, although initial testing wasn't consistent. However, when I turned on Ambient occlusion to full, then I began to see some hitches. When I turned it down to medium, I was also getting hitching, but then I was killed.
I can't edit the file, because the quality loses too much, but there are some big bars that crop up relating DX9:WaitingForBufferedFrames, and others.
I am uploading the full video to youtube. At around 17mins, that's where I start to use the profiler, I make the change to Ambient Occlusion High about 18:30, switched to marine at around 25mins. 30mins, switched to Medium AO.
I would only recommend watching from 25mins onwards. I will do some more testing later, but the hitches I record here seem to involve excess time fragments where waiting code is running, but no code takes up the time doing anything..
Will take a while to finish uploading and processing...
Now we have a place to investigate further and test out theories etc.
This is on our wishlist for the future and I have made the CDT aware of it
@Soul_Rider
WaitingForBufferedFrames is 100% the furthest i have been able to isolate this issue using profiling / plogs
@DC_Darkling
What is your pagefile size and setup? Is it on the same HD as your OS or NS2?
I may play around with the settings to test
Some extreme examples when reproducing this :
I discontinued the hypothesis that its purely paging! @Ironhorse.
As the same paging speed happens with and without the stutters, it is unrelated. It is ok for textures to load slower if this does not affect performance.
Even if I do the tests 40 times and have 1 time where there are no stutters with these loads speeds... if it doesnt happen, its not the reason!
I continue to say that memory fragmentation is a bad thing and will lead to more paging. OF course MORE paging may still produce stutters, but this is always a result of increased use in memory.
As a earlier test showed both vram AND memory increase with upping texture quality. So A increase in paging with higher textures is likely. Not worth it to invest paging, worth it to keep a eye on memory use and vram use!
For completion to your question however.. my pagefile and ns2 are both on a crucial M4-CT128 which is connected to a marvel 91xx 6G controller, installed with the latest drivers for the controller in question.
Steam itself is on a raid1 (mirror) array on a intel x59 chipset. The mirror consists of seagate hybrid desktop drives. Considering the heavy usage it is highly likely steam files are cached.
Plans I have for this problem:
* make insane detailed textures to mod random walls in like biodome. (I think of pasting part of a colour graph in, so that each pixel is a individual unique colour)
* compare ingame texture on low, mid and high to see what happens. Bug @Ironhorse about results to confirm what happens is what SHOULD happen.
- this is due to the, quite insane, increase of vram between medium to high textures. Are they upscaled, downscaled? Are they saved in different dimensions? (I couldnt find those)
* Try to make even more ridiculous textures then already ingame in terms of KB and see how this affects vram and performance. (aka, make the problem worse, what will break first and how)
* Bother to finally install something to make and check plogs.
* think of new ideas
Hence the long .dds cache reads from paging.
Also, I can scarcely mention how happy I am this is finally getting looked at. IMO, the last nail in the "strange performance coffin" that NS2 has been at times.
It may be a additional nail in the coffin, but seems in no way related. (Ya know, more test.. more info, so scrapping old ideas)
So far that is the ONLY element that i can reliably pin down.
I managed to remove my OC for my CPU and thus kept the same settings in NS2 (High textures etc) but because i was no longer GPU bound i did not experience the hitching.
@DC_Darkling Yea i tried every setting possible with page files, doesn't seem to effect the outcome whatsoever.
Interestingly, and this is a side note. I have been going around saying how I don't use AA and AF, as you can tell by all the jagged lines on my screen...
Turns out, I have both on maximum, so I am beginning to think they don't even work :P
I bet you the only reason is because it's increasing waiting on gpu time (which makes sense)
r_stats is running throughout that whole video above
My latest tests show:
* min fps during stutter is WELL within limits. (70+ on a 60hz)
* Limiting the fps by external means (like nvidia inspector) to 60 still EVENTUALLY produces stutter. (as my min is normal higher I had constant fps within around 5 frames of 60). I also severely upped the max prerendered buffers. Unfortunately this is a max, not a minimum. So no way to test if ns2 actually buffered more. Tripple buffering during this test was also on.
* Indeed many buffered frames in profiler. (waitforbufferedframes) (begin render)
* wait for gpu > near nothing (1 to 10ms), even on severely limiting fps.
* Also a D3D9Device: Present, which is high often. (Finish render)
* Finish is in the frame before buffered.
* Look at the frametime difference on a stutter:
frame, frametime, difference with previous frame
9120 154.391.123 19.352
9121 154.570.057 178.934
9122 154.581.579 11.522
So what can we conclude so far?
* making the GPU work less by limiting fps does nothing.
* wait for GPU may increase the problem but does not seem to cause it.
* of course DURING the stutter you can see wait for GPU, simply because the frametime for that single frame explodes.
* frametime explodes.
* nothing weird with previous frames, or frames after.
* SOME spikes have a smaller spike with finish render in front of them.
Questions:
* is profiler accurate? Aka, does it lie?
* WHAT happens on waitforbufferedframes? (is this literally only waiting for a buffered frame itself, or does more happen?)
* Did anyone actually dig through anything related to waitforbufferedframes for coding errors?
* Can we see in detail what the buffer contains in the frame before this stutter, and the one its waiting for?
* Is this D3D9 only?
Assumptions:
Cards which can easily hold fps in fights on maps heavy littered with entities suddenly lose their ability to present 1 to 2 frames at a time. I wonder what happens in that single frame? WHAT is new what makes it stutter/wait?
I do not believe its purely graphical, or the card would present this problem in heavier fights. So I assume it is coding related. Without knowing what exactly happens in the code, this gets rather vague quite fast. (I know its lua for all to see but I know near nothing about code)
If we think its graphical it would mean we are waiting on a frame because the GPU isnt done making it. (as its looking at the ceiling, sleeping, this is unlikely)
If we think its coding it would mean we are waiting on a frame because the game failed to provide the info into to make the frame. Normally I would assume the GPU should just draw without that info, but now it makes me seriously wonder.... would it?
>quick stealth edit before zzzzz, sleepies<
read this:
http://joostdevblog.blogspot.nl/2011/10/what-no-one-told-you-about-videocard.html
First question raised... the profiler, does it show the 'current' frame or this 'previous' frame?
Because if it does NOT show the 'previous' frame then... what is that previous frame doing, and isnt that the one we are waiting on?
Assumptions all round but nice to grind over!
So it appears that if your CPU is too fast for your GPU you wait for Buffered Frames. That is definitely my case, as my CPU is 4670K, while my GPU is only a 560Ti 1GB.
What I can't tell is if this is a problem with the way DirectX is coded, or the way the engine is coded to work with DirectX. I also have no idea what would need to be done to mitigate it either. That's a very interesting article you linked to @DC_Darkling
Although, there is one thing I should make clear, I definitely do not use V-Sync..
I am just about to do some testing with the Maximum pre-rendered frames setting in the nVidia control panel. I am setting it to 1, 2, 3 & 4 and testing on all settings to see if I can come up with any consistent fluctuations in frame times etc...
Even though that seems reasonable (goihng down to 70 fps), that is merely the average. The actually frame being waited upon has like a 40ms time while the rest in the second have like 12.2ms time to render/display.
Average FPS belies the reality of what stutter means in some ways. Even on 60 hz, going to down to that average of 70 would be painfully obvious due to the high amount of time the one frame takes.
Keep paying attention.
I know this already, why else would I have bothered to lookup frametimes? its even in a different part of the same post you partially quoted!
Hehe, no hard feelings.
@Soul_Rider
After I OCed my cpu a while back I also pushed myself to GPU cap. Now I could OC that also perhaps, but thats not solving the issue, merely showing the cap into another direction again.
I do use windowed mode, but I also do not use vsync. Frametimes show this as I am not 30/60.
@IronHorse
Look at the likely cause we may have found. And look its related to a gpu capped system as you suspected. And look, buffered frames in profiler!
I think we are onto something here. (Im not patting myself with this post, I merely forgot to @ link you last night)
fresh mind after sleep, new ideas and questions.
* first of.. the nvidia setting controls MAX prerendered frames. If prerendered frames are to low, the CPU is waiting on the GPU. If its to high needlessly it will create input lag. This is what few realise.. It doesnt create realistic input lag unless its to high needlessly! Because any stutter would produce more input problems then a higher prerender would. Of course depending on the person and system, results would vary.
* Max prerendered frames is 3 or 4 by default.. (I truly can not remember). But this is MAX. How many does ns2 actually use? IF ns2 never bothers to use more then, lets say, 2.. then many of us are starving the GPU of work! (I guess a low min and high max value would allow users to tweak this better themselves but I aint sure)
Possible todo: (YOU can help!)
* Make a high quality short vid containing the same or more frames per second then ns2 plays on maximum. So if max fps is 100, you would need a vid with a fps of 100.
* Find the frame which is being so damn slow.
* Compare, what does it contain.. What is the frame?
So why the framerate thingy in the vid? The vid needs to be able to capture the ONE specific frame. IF you have 100fps and 1 frame is having insane frametimes you still stutter. If you record on anything less then 100fps in your video... you may not record the one frame in question. OUCH.
Capping max fps may help in lessening fps needed in the vid. I suggest short videos because really.. even on 30 fps, thats already 120 frames (pictures) to look through after only 4 seconds! OUCH.
PROBLEM on recording frames!
If you do not start recording frametimes (like with fraps) AND do not start recording a video AT THE EXACT SAME TIME, then you can not use the framenumber to quickly go to the laggy frame. This would mean you would need to manually dig through loads and loads of frames. (I am hoping fraps can benchmark and record when pressing the same key, will try tonight I hope).
For users who can use nvidias Shadowplay, not me.. my card is to 'old', you are probably more suited for the job.. As I assume that nvidia captures the actual frames, and not record over it. I hope I am right. This may allow someone to finetune the vid around the moment of stutter lateron, and then start digging those frames.. unfortunately again one at a time.
I have the slight hope UWE or a community dev has some brilliant insight in this all, perhaps seen a coding error or something how ns2 handles frames/buffer, so we dont need to manually dig each frame.
I believe NS2 is locked to 1 prerendered frame since some mouse lag optimization. You would probably waste your time.
I already tested that. Note its a MAX pre-rendered. It had 0 effect, hence my earlier question about what ns2 allows.
Also.. LOOK AT THIS, SUCCESS!:
http://imgur.com/a/Vde4M
What are you looking at? This is what I did.
* start fraps and link benchmark and vid to the same key. I had to record the vid on half size to make it 'keep up' with ns2, hence the lower quality.
* Analyse log. The frametimes showed the following stutter:
726 12694,839 15,942
727 12935,944 241,105
728 12958,498 22,554
From a frametime of 15ms to 241 is a HUGE stutter. frame 727 took a whopping 241ms. That means frame 726 was displayed for over 1/4th of a second!
727frames / 60fps (727/60) = 12,11 seconds, so my video should show the problem within the 12th second of capture.
* loadup video in VLC player.
* went to start of the 12th second.
* 'played' frame by frame. (There is a advanced menu which allows a button to play frame by frame by clicking it)
* fraps recorded 60fps while I set NS2 fps to 60max by nvidia inspector.. Logic would then make us assume that every click of this button = 1 frame. The first picture you see IS this 241.105 long frame! It was lasting for 14frames! That means that 'normally' it would have showed 14 additional frames! and look, 1/4th of 60frames is... 15 frames! Where did we see 1/4th before? Thats right... 241,105 is well around 1/4th of a second.
So that small calculation shows the video capture is pretty spot on with its 14 frame estimate.
Picture 2 is me flying to the same area, from the same side, in a newly loaded map, ns2 closed and started again. As you can see I can easily hold 100fps in that area normally!
I would say this is sound evidence about not only the existance, but also the likely direction in which we should search for this problem. IF it was a mere render error, we should always get the same fps in the same area. This is not the case.
Do discuss!
@Ironhorse for the poke.
@matso @fsfod for the hitching poke, as I heared you are on the task.
I would be contributing more to this thread right now but I am hammered with reading and work for Uni. So sorry if some of my more "driveby posts" have been uninformed or too rash. Thank you for working on this everyone.
Anyone tried messing with details in Nvidia Inspector? Like with VRAM etc?
I would not bother. fraps captures the input after the engine is done but before its passed to directx. (according to graphs ive seen online)
Fraps shows the problem, hence its a problem earlier on:
http://www.extremetech.com/gaming/154089-after-almost-20-years-gpu-benchmarking-is-moving-past-frames-per-second
See, the driver and direct X dont come into the picture until later. So for us in this situation (not stutters in any game), we can only point to something in the game/engine.
Different people seem to have different results in terms of % of vram in use vs stuttering and/or quality of textures.
We would need many more people to test both low, mid to high textures to see how that would matter. More then the folk in this topic. Besides, I remember something of you testing once with wireframes and still have stutters?
Also vram will not go up and up and up and up nonstop. On my tests I had far less memory in use then real games. (basicly only anything marines get on start game + aliens & spurs.
If its a vram problem, id expect it to become worse as texture use goes up. It doesnt, strong stutters occur even early on.
The stuttering does get worse as more rounds /maps are played consecutively.
Textures don't matter in my experience - they only matter so much in that they increase waiting on gpu time.
Using vsync (which resets every map) in conjunction with maxfps command will eliminate the issue at the cost of mouse input delay.
This is why I've concluded the only thing that truly 100% of the time can reproduce is waiting on GPU.
Which doesn't make sense why max pre rendered frames never helped...
vsync forces a 15/30/60/120 fps limit. As the stutter is just on one frame, having less frames will in reality create less stutters. Problematic frames may have been dropped in favor of the vsync.
Its not prerendered frames, its MAX prerendered frames. Meaning I can set the max to 8 for all I care. If ns2 does not allow the user to configure this but forces a max of lets say 2, then it wont ever do any good. What you would need for this test is a MIN prerendered frames, a setting which does not exist.
Also prerendered frames and tripple buffering helps 'a bit'. Like vsync it lessens the chance. Only this time it does it by having more backup frames. The reason it still does not work 100% is simple. The gap is to big! my test showed a fps gap of 14frames for one frame. No amount of tripple buffering or prerendering would remove that gap. It may lessen it but never remove.
The mouse input lag is a bit like beating a dead horse. max prerendered frames are supposed to be used when you NEED to fill in the small gaps due to fps fluctuations, NOT stutters. a fluctuation in fps is far worse for input then the increase in prerendered would be.
The same counts for vsync. A drop to 15fps on vsync is far worse for input then tripple buffering.
Both features work fine in their desired task.
Note that vsync does nothing more then limit fps but then linked to refresh rate. So if I run a refresh rate of 60 and manually force the max fps to 60 it should produce the same end result in terms of this problem. The problem occurs on 60fps.
30fps I dont test as noone should be playing ns2 on 30fps anyway. (some games run fine on 30, not ns2)