2019-12-07 11:55 EST


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0003160FSSCPgraphicspublic2015-05-28 23:57
ReporterGoober5000 
Assigned Tom_m 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformDell Precision M4800OSWindows 7OS Version
Product Version3.7.2 
Target VersionFixed in Version3.7.3 
Summary0003160: Periodic freezes when running under the NVIDIA GPU
DescriptionI alluded to this in ticket 0003130 but didn't elaborate as that was primarily about the beam crash.

When running a build using the NVIDIA GPU, the build will periodically and unpredictably freeze. Each freeze lasts from 5 to 15 seconds, and they happen every minute or so, with no apparent pattern. They occur in the main hall, in the tech room, and in the mission.

This occurs on builds compiled with 2005, 2008, and 2013. It does *not* occur on builds compiled with VS 6 (at least up to and including 3.7.2 final). This makes me wonder if it's due to a compiler option introduced post-VS6.

I doubt it's an overheating problem as the laptop has plenty of ventilation and doesn't feel particularly hot. And I doubt it's a driver problem as I updated the drivers about five times in the course of testing 0003130.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0016717

Goober5000 (administrator)

Interesting update. After Googling around using "Dell Precision M4800 graphics stutter", I ran across this thread:
http://forums.totalwar.com/showthread.php/147456-Issue-Stuttering-and-freezing-from-intro-cinematic-to-main-menu/page2

In the Task Manager, my process affinity was set to only use CPU 1 (the available choices where All Processors and CPU 0 through CPU 7, all with checkboxes). I messed around with the checkboxes a bit and when I set it to use All Processors, the stuttering stopped!

Is there a setting for changing the CPU affinity when the game starts up, just as there is for changing the GPU? If so, we could ensure that the CPU and GPU are changed in the same block of code.

~0016719

Goober5000 (administrator)

Incidentally, changing the CPU affinity does not prevent the beam crash bug. :sigh:

~0016721

The_E (administrator)

Solutions seem to exist (see: http://stackoverflow.com/questions/12803585/example-usage-of-setprocessaffinitymask-in-c-c for Windows, http://stackoverflow.com/questions/8486314/setting-processor-affinity-with-c-that-will-run-on-linux for Linux, unsure about MacOS).

~0016722

MageKing17 (developer)

Additionally, Windows should default to everything having affinity for all available processes; it sounds like you've got something setting Explorer's affinity to a single core: http://blogs.msdn.com/b/oldnewthing/archive/2005/03/21/399688.aspx

~0016723

m_m (developer)

FSO actively set the processor affinity to the second core when there are multiple cores on the system (https://github.com/scp-fs2open/fs2open.github.com/blob/master/code/osapi/osapi.cpp#L126). I can't think if any good reason to actually do this and messing with the OS scheduler isn't such a great idea.

@Goober: Does the issue still exists if you remove that line?

~0016724

MageKing17 (developer)

...What.

We have a registry setting for processor affinity? Is that documented anywhere?

~0016725

FUBAR-BDHR (developer)

Last edited: 2015-05-22 03:54

View 2 revisions

The affinity being set was added years ago do to a problem with certain processors not liking FSO being set to run on multiple cores. There is a thread on it in either the SCP forum or the internal.

http://www.hard-light.net/forums/index.php?topic=55990

~0016726

MageKing17 (developer)

This is also not the first time the automatic affinity setting has caused performance issues for somebody: http://www.hard-light.net/forums/index.php?topic=82620.msg1649312#msg1649312

~0016727

m_m (developer)

Forcing a process to run on a single core doesn't seem like a generally good idea, the scheduler should take care of that.
I'll see if removing that code causes any issues. Could we add a commandline option that forces the processor affinity instead of defaulting to use a single core?

~0016728

MageKing17 (developer)

I did some experiments with setting the registry entry to 0 (no preference) without any issues last night.

~0016729

FUBAR-BDHR (developer)

The issue only affected specific processors so in order to test you would need to find out which processor line(s) had the flaw and who still has one.

~0016730

Goober5000 (administrator)

@m!m: Yes, commenting out the line removes the stuttering, and I confirmed via Task Manager that all CPUs were selected.

~0016731

m_m (developer)

We now have multiple confirmed cases where setting the process affinity causes issues. I think that is reason enough to use the default affinity and only set it when a commandline flag is present.

~0016732

The_E (administrator)

Seems pretty clear-cut to me.

~0016733

chief1983 (administrator)

It can be set that late into the runtime?

~0016734

m_m (developer)

The documentation for SetProcessAffinityMask doesn't mention any restriction as to when this function may be called.

~0016735

MageKing17 (developer)

It's already set in response to a registry entry; it's hardly a huge difference in how long the executable has been running to set it in response to the commandline. In fact, parse_cmdline() is actually called earlier.

~0016736

m_m (developer)

Pull request with the discussed changes: https://github.com/scp-fs2open/fs2open.github.com/pull/131

~0016737

m_m (developer)

@Goober: Can you do a final test with the newest nightly now that the PR got merged?

~0016739

Goober5000 (administrator)

Newest nightly works without any stuttering.

~0016741

Goober5000 (administrator)

Marking as fixed.
+Notes

-Issue History
Date Modified Username Field Change
2015-05-22 00:07 Goober5000 New Issue
2015-05-22 00:08 Goober5000 OS => Windows 7
2015-05-22 00:08 Goober5000 Platform => Dell Precision M4800
2015-05-22 01:03 Goober5000 Note Added: 0016717
2015-05-22 01:12 Goober5000 Note Added: 0016719
2015-05-22 01:13 Goober5000 Status new => confirmed
2015-05-22 01:55 The_E Note Added: 0016721
2015-05-22 02:02 MageKing17 Note Added: 0016722
2015-05-22 03:29 m_m Note Added: 0016723
2015-05-22 03:38 MageKing17 Note Added: 0016724
2015-05-22 03:48 FUBAR-BDHR Note Added: 0016725
2015-05-22 03:54 FUBAR-BDHR Note Edited: 0016725 View Revisions
2015-05-22 04:04 MageKing17 Note Added: 0016726
2015-05-22 06:31 m_m Note Added: 0016727
2015-05-22 14:14 MageKing17 Note Added: 0016728
2015-05-22 14:25 FUBAR-BDHR Note Added: 0016729
2015-05-23 15:27 Goober5000 Note Added: 0016730
2015-05-26 13:34 m_m Note Added: 0016731
2015-05-26 15:54 The_E Note Added: 0016732
2015-05-26 16:38 chief1983 Note Added: 0016733
2015-05-26 16:42 m_m Note Added: 0016734
2015-05-26 17:36 MageKing17 Note Added: 0016735
2015-05-26 18:01 m_m Note Added: 0016736
2015-05-27 08:34 m_m Note Added: 0016737
2015-05-28 00:25 Goober5000 Note Added: 0016739
2015-05-28 23:57 Goober5000 Note Added: 0016741
2015-05-28 23:57 Goober5000 Assigned To => m_m
2015-05-28 23:57 Goober5000 Status confirmed => resolved
2015-05-28 23:57 Goober5000 Resolution open => fixed
2015-05-28 23:57 Goober5000 Fixed in Version => 3.7.3
+Issue History