Drexir wrote:Usually micro-stutters like that are indicating either SLI or Crossfire setup is causing it. Or the processor is not keeping up with the graphics card.
Which may in fact be related to the swap of the buffering since that process is essentially tied both to the CPU and graphics card.
I've also seen micro-stutter happen related specifically to VRAM issues. I use to run 2x HD 5850's (1GB) in crossfire. Considering I was running a high res screen 2560x1600 it didn't take much to eat that video ram causing micro stutters. This game for me easily consumes over a 1GB of VRAM. Granted that may just be due to my high resolution. I recommend using a monitoring utility to see how much VRAM the game consumes.
I had checked GPU utilization and VRAM usage, but didn't post anything about it as it wasn't anything noteworthy. The GPU itself is at about 20-25%, GPU (dedicated) is at is at 450-600 MB (mostly depending on the multisampling setting in the graphics options), so about 50% is still available.
Drexir wrote:I remember in the catalyst control center there was always a one or two things I had to turn change to stop the micro stuttering. It was the crossfire setting and I had to set it to AFR Friendly. If I remember correctly it basically means one gpu renders a frame and the second gpu renders the second frame and it alternates. But you don't have dual 6850's so just make sure crossfire is disabled. There was another option I used in some games which was A.I Texture Filtering Quality and set that to Performance. I believe this just helped because it didn't consume as much VRAM. And also changing the power saving feature on the card in the control center sadly I don't know what they call it on AMD's side. As I use nvidia now. But mine says simply "Power Management Mode" depending on the game I will either set it to Adaptive or Prefer Maximum performance (the latter option completely disables power savings).
None of the Crossfire settings are available unless you actually have multiple GPUs. There are no (official?) power options for AMD cards (in the Catalyst Control Center), the only thing remotely related is the OverClock section (which is disabled). The only thing in the advanced windows power settings that could affect the GPU is the PCIe Link State Power Management (which is off for High performance by default).
I had already tested the Texture Filtering quality, since I have gone through most (if not all) of the Catalyst Control Center 3D options already (as mentioned before). And I do agree that it's likely that this helped for you is related to the reduced GPU memory requirement.
Drexir wrote:One more thing as Factorio auto detects your display. It auto sets your resolution and limits your frame rate to the refresh rate that was detected by the monitor. The problem can come in is if you have another program that limits your frame rate. Some programs that do have that feature is monitoring programs or overclocking software. For example EVGA Precision, MSI Afterburner, etc. If you do have one of those programs installed make sure that frame limiting is not enabled. As it can cause problems as you might imagine cause the external software is conflicting with the game.
No frame-limiting programs or GPU-Tweakers of any description are running (or installed). The only thing that does access the GPU is FRAPS for monitoring, to show the frame rate on my keyboard's LCD. Weather or not that is running also doesn't change anything (tested this as one of the first things). I'm usually running in windowed mode, so the resolution is set dynamically depending on the window size, but I've tried full screen with no change to the issue (as usual
).
Drexir wrote:The biggest concern and i probably should have listed this first. But Windows 7 has a power saving feature. It basically will park your cores on your processor. And if the core is parked and the core needs to unpark. While this process is extremely fast. It's not fast enough for gaming purposes. As it introduces stuttering. The quickest way to find out is if your computer is idling. Go to your task manger -> resource monitor. On the side panel you should see all your cores listed along with graphs. If they are currently parked it should tell you right below the Core #. Honestly this core parking thing is really for laptops as a battery saving feature. Has no place on the desktop. You should be able to disable it in your control panel then advanced power options. In their you should find something along the lines of Processor Power Management and in their you should find a minimum and maximum setting just set both of them to 100%. If for some reason that's a bit much to follow. You can alternatively download this program:
http://bitsum.com/about_cpu_core_parking.php
It essentially changes the same settings for you just with a cleaner / more intuitive interface.
Well, that is just half true to be honest. No, core parking is not just for laptops, though it's obviously more important there. It's also for desktops, and not just because a parked core does use less power than one just running on low clock speeds (via. normal clock scaling), which you may or may not care about. I have tinkered a bit with the options (no, it didn't solve or change the severity of the problem even if I disable core parking), and core parking can be expected to be actually helpful for performance on my system. I'm using an AMD 6-core (FX-6100), which also allows for 'Turbo' mode, increasing the clock speed by 300 MHz as long as temperature and TDP allow it, but
by 600 MHz if only half the cores are active. No matter how low I set the percentage in parkcontrol, there are never less than 3 cores active, which aren't even close to maxed out with factorio.
But there's more: My CPU essentially consists of 3 two-core-modules on the chip (both are real cores, this is not like hyper-threading), but both cores in one module share the level 2 cache. This is important, because when only 3 cores are awake, it's cores 1, 3 and 5 that are sleeping (0, 2, 4 are active), meaning that you're much less likely to get things like cache thrashing, as only one core puts strain on the cache and it's not really shared in that moment, reducing the chance of collisions significantly. This is most likely not a major performace boost, but might make some performance hits resulting from multiprocessing less likely.
Lastly, please check the
benchmark-article that is linked on the page of the utility you linked (parkcontrol). Unfortunately, they only have a single benchmark there, which is a WinRAR benchmark. But notice how not a single AMD processor has any performance difference with/without core parking there? Also worth mentioning is that the article is rather old (2011), and it came out less than a month after the processors hit the market (the AMD line mine belongs to at least). There were multiple patches for this mechanic since (by MS as well as by AMD). This doesn't mean that this can't cause problems (as it obviously does), but it is extremely unlikely to do so with games that aren't extensively multithreaded, and then you could relatively easily notice it by seeing cores constantly park/unpark while the game is running. Basically you need the "core-requirement" (i.e. number of active threads) to change often for this to be a possible issue as a core that is busy will never go to sleep.
Drexir wrote:On the slim chance none of that works... Well just post back here and I'll try to help you further troubleshoot it.
None of this works. Sorry
While I very much appreciate the effort and time you've put into the post, I did actually know most about these things (not that you could necessarily know that). Most likely this isn't even a graphics problem in the classical sense: None of the GPU parameters are anywhere near a 'problem zone' and the problem pattern would be very unusual if it were one. The points you mention wouldn't really explain such a huge delay either (100-150 ms) in a precise interval every few seconds. Waking up a sleeping CPU core is in the order of microseconds, not 100s of milliseconds (even for C6 aka. 'parked', where it
might reach the low ms, it's actually surprisingly hard to find any info on this).
As
slpwnd has pointed out, the problem seems to be in the VSync-related code, which for currently unknown reasons waits way too long (or does something that isn't VSync). Let me also emphasize again that it's only factorio that has this issue.
It might also be an unexpected interaction between factorio and some other program that happens to be running (let me emphasize again though that it's only factorio that has this issue). It's really difficult for me to nail down, and believe me I've tried. As stated in my initial post, there are times when the issue doesn't appear, though it's relatively rare. I first thought it was just having Chrome running (which also uses DirectX to render web pages), but then it still happened after a reboot with nothing started. I don't have a lot of programs always running/started at boot (like tools in the system tray). But I've tried checking them as well as I could, and couldn't isolate a culprit. Note that those that I do have are usually companions to driver (like Logitech Gaming Software for mouse&keyboard, AMD CCC thingy) or things like anti-virus and Steam (which I've all exited/stopped for tests).
The problem with testing is, that sometimes the issue doesn't occur, which means I can't test anything explicitly. But it also doesn't mean that it's not one of those things that are running when it doesn't occur, as there isn't anything more running when it reoccurs. I've been checking for a total of at least 4-5 hours now, and I just can't nail it down. I couldn't find any combination where it didn't occur after (re-)testing all your suggestions for example, there was basically nothing running anymore (less things running than after a reboot) and the problem was still there. I tried rebooting and since the issue hasn't come back consistently, but it did happen for a short time when I first started Chrome again, but then stopped occurring again with
nothing changed and most notably Chrome still running.
I'm just gonna wait for Kovarex to return and have a look. Maybe it'll jump out at him when he's looking at the code