locked
Fullscreen applications taking full control of cores RRS feed

  • Question

  • So I really want to take more fine grained control of the threads and cores under Windows when running our game. 

    I can understand that because Windows maybe running multiple applications in a normal windowed environment that it would be a really bad idea to allow applications to take total control of a number of cores.

    Every app would want to do it and the machine would pretty much instantly become unresponsive.  However in full screen mode I don't see this to be the case.

    So in order to really make efficient use of the parallelism of modern processors, I'd like to be able to take complete control of a number of cores in full screen mode. Up to a maximum of say one or two cores less than the total processor core count.  Windows and the other running processes would then run on those one or two cores leaving the full screen app to use the other cores unhindered and uninterrupted.

    At the moment thread affinities don't really work as other threads from the third parties and from other processes jump in and hog the cores causing stalls and other issues.  Also thread priorities don't really work (for this use at least) as you only have five levels and typically your application itself will legitimately need to use all five levels.  Also the OS will just override those priorities anyway.

    At the moment I'm really only left with the option of setting the ideal processor for a thread. This leaves the us in a complete multithreaded bun fight for resources which you can only hope the processor itself is powerful enough to overcome. Not ideal!

    Saturday, September 7, 2013 10:08 AM

Answers

  • The fact is, that you won't get what you want on typical Windows installation.

    I don't think such thing is necessary. Without any meddling with priorities, affinities and ideal processors, even on 10 years old scheduler of Windows XP, using default system thread pool, I can schedule thousands of parallel operations per frame, at 60 fps, on a fairly typical 2-core HT machine. What is it that you want/need so fine-grained control?

    Also, there is actually 32 priorities on Windows OS, not five, see Scheduling Priorities
    (my opinion is that there aren't many legitimate reasons to use more than one, below normal)

    If you see stalling or twitching in your engine, I would look for problem elsewhere.
    First, try to remove all the code in which you are trying to affect default scheduling.

    For industrial and embedded systems I would approach the issue differently, of course, like using Windows Embedded with one of the commercial real-time extending drivers. But that is obviously not your case.

    • Proposed as answer by Pavel A Sunday, September 8, 2013 12:28 AM
    • Marked as answer by Xiaoliang Chen - MSFT Monday, September 16, 2013 8:55 AM
    Saturday, September 7, 2013 2:24 PM
  • However I haven't tried putting the game into the high priority class.  I shall do this and see if with affinities that helps the situation. 

    Not only priorities. There's also Multimedia scheduling  (since Vista) and some new "Real time work queues" in Win 8.1 to play with...

    -- pa

    Monday, September 9, 2013 3:37 AM

All replies

  • The fact is, that you won't get what you want on typical Windows installation.

    I don't think such thing is necessary. Without any meddling with priorities, affinities and ideal processors, even on 10 years old scheduler of Windows XP, using default system thread pool, I can schedule thousands of parallel operations per frame, at 60 fps, on a fairly typical 2-core HT machine. What is it that you want/need so fine-grained control?

    Also, there is actually 32 priorities on Windows OS, not five, see Scheduling Priorities
    (my opinion is that there aren't many legitimate reasons to use more than one, below normal)

    If you see stalling or twitching in your engine, I would look for problem elsewhere.
    First, try to remove all the code in which you are trying to affect default scheduling.

    For industrial and embedded systems I would approach the issue differently, of course, like using Windows Embedded with one of the commercial real-time extending drivers. But that is obviously not your case.

    • Proposed as answer by Pavel A Sunday, September 8, 2013 12:28 AM
    • Marked as answer by Xiaoliang Chen - MSFT Monday, September 16, 2013 8:55 AM
    Saturday, September 7, 2013 2:24 PM
  • Thanks for the reply and I thought that was the case.  I suppose this is more of a feature request. 

    I know there are 32 priority levels and that effectively 16 are reserved for the system, its just an app only has access to five of them.  However I haven't tried putting the game into the high priority class.  I shall do this and see if with affinities that helps the situation. 

    Fundamentally though this is a case of high performance and being able to guarantee frame rate.  With the current situation any time critical sync points in anyone of our games multiple schedulers can be knocked out by another thread coming in and using the processor core the sync points dependent threads are running on.

    I'd like to stop context switching as much as possible as well as its quite slow.  Therefore I'd like to sandbox all the Windows threads onto one core and then guarantee total control over the other cores when in full screen mode.


    Sunday, September 8, 2013 9:27 PM
  • I understand what you are trying to achieve, but I believe it is futile fight.
    Even if you somehow manage that (e.g. by deploying custom kernel drivers) it will cause huge pain to you (and at least hundred of hours of development time) and to your users, because running such thing would definitely require administrators token (read UAC) thus effectively locking out folks without such privileges, and there will always be people with odd unsupported and untested configurations clogging your tech support.

    Guaranteeing frame rate was always challenge on Windows.
    The question is, if you want to really go through all that effort just to eliminate occasional bumps.

    Anyway, if going high priority gives you enough improvement, please don't forget to go idle (or at least normal priority) when player Alt+Tabs onto the desktop :)

    Monday, September 9, 2013 8:01 AM