Degraded Performance in Deposit on Mineshaft Since Build 244
-WildCat-
Cape Town, South Africa Join Date: 2008-07-19 Member: 64664Members, Reinforced - Shadow
Cape Town, South Africa Join Date: 2008-07-19 Member: 64664Members, Reinforced - Shadow
I've encountered quite severely degraded performance when standing near the center of the room in Deposit on ns_mineshaft since build 244 was released. In an empty server, I get between 110 and 190 FPS in the other parts of the map but in the center of Deposit (around the resource nozzle) my FPS goes down as low as 55.
I think the problem is related to shadows because r_stats shows that the number of shadow maps being generated while standing in that area goes up over 60. By slowly shifting my position and orientation, I was able to find a worst case where the number of shadow maps being generated was over 70 and exceeded the number of visible lights in the scene.
If I turn shadows off, my FPS goes up to ±170 in this area.
My system specs:
P.S. What is the name of the console command that displays the detailed, full-screen breakdown of all the performance figures?
I think the problem is related to shadows because r_stats shows that the number of shadow maps being generated while standing in that area goes up over 60. By slowly shifting my position and orientation, I was able to find a worst case where the number of shadow maps being generated was over 70 and exceeded the number of visible lights in the scene.
If I turn shadows off, my FPS goes up to ±170 in this area.
My system specs:
- MSI Big Bang MPower Z77 Motherboard
- Intel Core i7-3770K @ 4.5GHz
- Corsair Dominator Platinum 8GB DDR3 1866Mhz RAM
- nVidia Geforce GTX 690
- nVidia driver version 314.07
- Windows 7 Professional 64-bit
- In NS2: 1920 x 1080 @ 120 Hz fullscreen, v-sync off, texture streaming off, all graphics settings maxed
P.S. What is the name of the console command that displays the detailed, full-screen breakdown of all the performance figures?
Comments
I wasn't able to glean any further insight into the problem from it, though. Probably because I don't really know how to use it properly.
1. This screenshot highlights the process called ScriptGC_STEP:
2. This is the frame immediately before the one pictured above. Here, ScriptGC_STEP is taking much less time but now RenderScene::WaitForResults is taking ages:
3. The following screenshot is of the same frame as the one above but I've scrolled down and highlighted RenderScene::RenderLightPasses. You'll see that RenderScene::RenderShadowMaps is also taking quite long:
After taking these screenshots, I experimented with disabling the multi-GPU capability of my Geforce GTX 690. This is done by first going into the "Manage 3D settings" menu in the nVidia Control Panel and clicking on the "Program Settings" tab. Then, finding Natural Selection 2 in the list and changing the setting for "Multi-GPU rendering mode" from the default value of "nVidia recommended (Multi-GPU)" to "Single-GPU".
The first thing I noticed was that my usual FPS of 110 - 190 was down to 70 - 110. However, in Deposit, I no longer got the large slow-down to 55 FPS. Instead it just went down to about 70 FPS.
I hope this info can help you guys resolve the problem. Let me know if you need me to do any further testing or information gathering.
"This makes SFR the preferred SLI method for fast paced action games."
This is the waiting for buffered frames thread you are finding.. as you are adding another frame or 2 that sits waiting, giving the garbage collector time to clean up. (thats the ScriptGC_Step)
You could have exposed a certain method that doesn't play well with AFR or SLI though... we'll have to see (if you investigate further)
This all being said your screenshots do not follow the instructions i provided, so i don't think you've captured the culprit
"Select the tallest bar from the bottom of the screen" .. you seemed to have picked some of the shortest - in other words, some of the best performing frames - which doesn't give much info.
Interested to see what you find next!
In Deposit, there are 6 light fixtures hanging from the ceiling, which cast warm-colored light into the room. To create the actual lighting effects, the map author has used the following entity set up for each fixture:
1. A light_spot pointing downwards. This is the primary part of the lighting effect.
2. A light_point with a very small Max Distance right below the fixture to light up the fixture itself.
3. A light_point with a larger Max Distance near the floor, which is probably to simulate bounced lighting.
For some reason, both of the light_point entities in this setup have Cast Shadows set to True.
So, with six light fixtures, that adds up to 12 light_point entities that cast shadows. I'm guessing that each light_point entity generates 6 shadow maps, so that could amount to 72 shadow maps in a worst case scenario.
I tested setting Cast Shadows to False on these light_point entities and it fixed the performance drop in that area. (Shadows can remain enabled on the light_spot entities - no problems there.)
The reason why I did that was because the symptom of my problem is not momentary hitching or stuttering. Rather, my problem is that my FPS is constantly bad in that area. Every frame is rendering too slowly. Those one or two taller bars were probably caused by textures being loaded in or something...
What I found interesting was that the most costly processes were alternating every frame. Every odd frame, it would be the ScriptGC_STEP process and every even frame, it would be RenderScene::WaitForResults process. That's what got me thinking about disabling SLI.
To me, it's strange that multi-GPU performance is worse than single-GPU performance when the scene that needs to be rendered is very expensive, but multi-GPU performance is better than single-GPU performance in other cases.
I think the most important thing now is to find out whether the previous version of ns2_mineshaft had those shadow-casting point lights in Deposit. If the point lights were NOT casting shadows in the previous version, then we know why the performance degraded in Build 244. However, if those point lights have always been casting shadows in all the previous versions, then that suggests that something else might have changed in Build 244 that messed up multi-GPU performance in situations with longer rendering times.
I can't read half of what you wrote lol.
Interesting. Thanks for the info. There doesn't seem to be a way to select SFR from the nVidia drivers so I downloaded nVidia Inspector (which people were talking about in the thread you linked) and tinkered around in there. After changing NS2 to use SFR, however, I couldn't feel any difference. I switched back and forth several times but I can't tell them apart.
Additionally, I can't tell the difference between single-GPU mode and multi-GPU mode using AFR. I can't feel any increased input latency in multi-GPU mode.
Normally, I'm quite sensitive to increased latency. I can feel the difference when using v-sync in triple buffered mode. Double buffered is less obvious to me but still just perceptible. Maybe I'm just tired... stayed up too late last night. I'll certainly be testing this out more in the future.
"The reason why I did that was because the symptom of my problem is not momentary hitching or stuttering"
The height of the bars do not indicate hitching, but rather resources intensive frames, so it would still be better to see those frames.
If every frame was too low, then you could take a profile shot outside of that area, and then again inside to compare.
But yeah.. it looks like shadowmaps may be the cause.
You could double verify this by disabling shadows and marking the difference from deposit to a specific non deposit spot. But thats extra legwork.
I've seen many more shadowmaps than that and still not cause any issue so idk.. maybe its something related to mGPU and shadowmap performance? idk..
Definitely worth more investigating still
Though i'll point the mapper to this post regardless.
Thanks