Windows has a function that allows you to set the priority of a process so
that something like a game gets more CPU time:
http://msdn.microsoft.com/library/psdk/winbase/prothred_9z1v.htm
Olivier A. Dagenais - Software Architect and Developer
Use nice with a negative value
Unfortunately you have to be root to do so
Aurelien Marchand> ----- Original Message -----
From: Olivier Dagenais [mailto:olivierS.dagenaisP@canadaA.comM]
Sent: Tuesday, March 06, 2001 12:29 PM
To: sdl at lokigames.com
Subject: [SDL] Increasing an SDL application’s priorityWindows has a function that allows you to set the priority of a process so
that something like a game gets more CPU time:http://msdn.microsoft.com/library/psdk/winbase/prothred_9z1v.htm
Do other operating systems have something similar? Would this be a good
addition to SDL? (or is it already there?)–
Olivier A. Dagenais - Software Architect and Developer
Olivier Dagenais wrote:
Windows has a function that allows you to set the priority of a process so
that something like a game gets more CPU time:http://msdn.microsoft.com/library/psdk/winbase/prothred_9z1v.htm
Do other operating systems have something similar? Would this be a good
addition to SDL? (or is it already there?)–
Olivier A. Dagenais - Software Architect and Developer
Priorities have been a feature of operating systems since Bill Gates was still
in high school. Of course all serious OS’s have ways to change priorities (in
Unix/Linux is called “nice” and to increase your priority you need root
privileges).–
Valerio Luccio - NYU, Center for Neural Science
Phone: +1 212 9983936 Fax: +1 212 9954011
URL : http://cns.nyu.edu/~valerio
"In an open world, who needs windows or gates?"Of course all serious OS’s have ways to change priorities (in
Unix/Linux is called “nice” and to increase your priority you need root
privileges).
nowadays it’s also called sched_setscheduler() (for posix.1b) and
the corresponding call for pthreads. To answer the original question:
Yes we may implement it if someone actually needs it, and needs a
platform-independent call. This is quite unlikely (and hard) since
priorities cannot easily be translated across platforms, nor the very
need of such a call
Windows has a function that allows you to set the priority of a process so
that something like a game gets more CPU time:
http://msdn.microsoft.com/library/psdk/winbase/prothred_9z1v.htm
Do other operating systems have something similar? Would this be a good
addition to SDL? (or is it already there?)
It’s not portable, unfortunately. Rather than provide something that won’t
be available most of the time, I’ve chosen not to include it in the API.
BTW, be careful when you do that, as it can starve other threads.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Windows has a function that allows you to set the priority of a process so
that something like a game gets more CPU time:http://msdn.microsoft.com/library/psdk/winbase/prothred_9z1v.htm
IIRC, this API has no effect on Win95/98 - but that might have changed with
ME. (In used to work only on NT, which has something more like a real
scheduler…)
Do other operating systems have something similar?
Yes, virtually any real multitasking OS does.
Would this be a good addition to SDL?
Yes, I think so.
SCHED_FIFO or similar (real time scheduling mode/priority) would be nice as
well, although most systems either just set the highest priority, or don’t
allow normal users to use it. (Linux really bypasses the time sharing,
enabling SCHED_FIFO threads to hog the CPU 100% indefinitely, as opposed to
for example NT, which still allows other threads to run every now and then if
a “real time” thread should hang.)
(or is it already there?)
Not that I know of… Can’t say I studied the threading API, though. 
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Tuesday 06 March 2001 18:28, Olivier Dagenais wrote:
Olivier Dagenais wrote:
Windows has a function that allows you to set the priority of a process
so that something like a game gets more CPU time:http://msdn.microsoft.com/library/psdk/winbase/prothred_9z1v.htm
Do other operating systems have something similar? Would this be a good
addition to SDL? (or is it already there?)–
Olivier A. Dagenais - Software Architect and Developer
Priorities have been a feature of operating systems since Bill Gates was
still in high school.
Seems like it took him a while to learn about implementing them, though… 
Of course all serious OS’s have ways to change
priorities (in Unix/Linux is called “nice” and to increase your priority
you need root privileges).
nice is a command line tool, rather than an API…
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Tuesday 06 March 2001 19:47, Valerio Luccio wrote:
How about procedural textures and texture caching? Is that possible to
implement without having the background thread steal CPU time from the
rendering thread? (That is; “What priority does a new thread get with the
current implementation?”)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Tuesday 06 March 2001 20:31, Mattias Engdeg?rd wrote:
Of course all serious OS’s have ways to change priorities (in
Unix/Linux is called “nice” and to increase your priority you need root
privileges).nowadays it’s also called sched_setscheduler() (for posix.1b) and
the corresponding call for pthreads. To answer the original question:
Yes we may implement it if someone actually needs it, and needs a
platform-independent call. This is quite unlikely (and hard) since
priorities cannot easily be translated across platforms, nor the very
need of such a call
Use nice with a negative value
Unfortunately you have to be root to do so
nice -5
That’s very non-portable (compared to SDL), and works only for processes;
not threads.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Tuesday 06 March 2001 19:46, Aurelien Marchand wrote:
Actually, the way things SHOULD work, is that other applications that don’t
need such high priority should be setting their nice values to positive
values. There’s no need to involve root access this way.On Tuesday 06 March 2001 10:46, you wrote:
Use nice with a negative value
Unfortunately you have to be root to do so
nice -5
nowadays it’s also called sched_setscheduler() (for posix.1b) and
the corresponding call for pthreads. To answer the original question:
Yes we may implement it if someone actually needs it, and needs a
platform-independent call. This is quite unlikely (and hard) since
priorities cannot easily be translated across platforms, nor the very
need of such a call
Could be soluted with fixed classes, like SDL_PRI_VERYLOW, SDL_PRI_LOW,
SDL_PRI_NORMAL, SDL_PRI_HIGH, SDL_PRI_VERYHIGH. But I don’t think
that is a good idea, because a good scheduler adepts the time needs and if there
is a thread, which gets more time, maybe he really needs it?
Just a thought,
Andreas Podgurski
David Olofson <david.olofson at reologica.se> writes:
Of course all serious OS’s have ways to change
priorities (in Unix/Linux is called “nice” and to increase your priority
you need root privileges).nice is a command line tool, rather than an API…
The API call on Linux is called setpriority() (and there’s an
equivalent getpriority() call as well.----------------------------------------------------------------------
Name
getpriority, setpriority - get/set program scheduling pri-
ority
Synopsis
#include <sys/time.h>
#include <sys/resource.h>
int getpriority(int which, int who);
int setpriority(int which, int who, int prio);
Description
The scheduling priority of the process, process group, or
user, as indicated by which and who is obtained with the
getpriority call and set with the setpriority call. Which
is one of PRIO_PROCESS, PRIO_PGRP, or PRIO_USER, and who
is interpreted relative to which (a process identifier for
PRIO_PROCESS, process group identifier for PRIO_PGRP, and
a user ID for PRIO_USER). A zero value of who denotes the
current process, process group, or user. Prio is a value
in the range -20 to 20. The default priority is 0; lower
priorities cause more favorable scheduling.
The getpriority call returns the highest priority (lowest
numerical value) enjoyed by any of the specified pro-
cesses. The setpriority call sets the priorities of all
of the specified processes to the specified value. Only
the super-user may lower priorities.
Return Values
Since getpriority can legitimately return the value -1, it
is necessary to clear the external variable errno prior to
the call, then check it afterwards to determine if a -1 is
an error or a legitimate value. The setpriority call
returns 0 if there is no error, or -1 if there is.
Errors
ESRCH No process was located using the which and who val-
ues specified.
EINVAL Which was not one of PRIO_PROCESS, PRIO_PGRP, or
PRIO_USER.
In addition to the errors indicated above, setpriority
will fail if:
EPERM A process was located, but neither its effective
nor real user ID matched the effective user ID of
the caller.
EACCES A non super-user attempted to lower a process pri-
ority.
Conforming to
SVr4, 4.4BSD (these function calls first appeared in
4.2BSD).
See Also
nice(1), fork(2), renice(8)
nowadays it’s also called sched_setscheduler() (for posix.1b) and
the corresponding call for pthreads. To answer the original question:
Yes we may implement it if someone actually needs it, and needs a
platform-independent call. This is quite unlikely (and hard) since
priorities cannot easily be translated across platforms, nor the very
need of such a callCould be soluted with fixed classes, like SDL_PRI_VERYLOW, SDL_PRI_LOW,
SDL_PRI_NORMAL, SDL_PRI_HIGH, SDL_PRI_VERYHIGH.
Yeah, maybe…
But I don’t think
that is a good idea, because a good scheduler adepts the time needs and if
there is a thread, which gets more time, maybe he really needs it?
Well, the problem is that “fair” time sharing is totally and utterly useless
for real time programming. That’s why Linux has a SCHED_FIFO mode, where the
thread entirely bypasses the timesharing system, and thus cannot be
preempted by anything but interrputs and higher priority threads.
Take the examples I mentioned before; procedural texturing and texture
caching: Both need a low priority thread that pumps textures as fast as
possible, using all available CPU time, while NOT being allowed to
interfere with the rendering and audio threads. That is, the background
thread is not going to sleep until there really isn’t anything to do (which
never happens if you’re doing heavy procedural texture effects - you just
want the highest “texture frame rate” possible.) If it had the same priority
as the rendering and audio threads, the timesharing scheduler would
eventually give it higher priority, resulting in massive audio drop-outs
and lots of dropped frames.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Tuesday 06 March 2001 22:41, Andreas Podgurski wrote:
Also, please don’t become trapped by the common misconception that a
thread that needs lots of CPU time should be given a high priority -
infact, the opposite is actually true:
i.e. thread_needs_more_cpu_power != give_thread_higher_priority.
High priority should only be used for threads that need to do (very
small amounts) of CPU intensive work at regularly defined instances.
Otherwise, if you give a CPU hogging thread a high priority your likely
to bring the system to a screeching halt… 
[For a more in-depth discussion (especially in regard to this topic on
BeOS) have a look at:
http://www.escribe.com/software/bedevtalk/m23359.html]—
David
Windows has a function that allows you to set the priority of a
process sothat something like a game gets more CPU time:
http://msdn.microsoft.com/library/psdk/winbase/prothred_9z1v.htm
Do other operating systems have something similar? Would this be a
goodaddition to SDL? (or is it already there?)
It’s not portable, unfortunately. Rather than provide something that
won’t
be available most of the time, I’ve chosen not to include it in the
API.
BTW, be careful when you do that, as it can starve other threads.See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Andreas Podgurski wrote:
nowadays it’s also called sched_setscheduler() (for posix.1b) and
the corresponding call for pthreads. To answer the original question:
Yes we may implement it if someone actually needs it, and needs a
platform-independent call. This is quite unlikely (and hard) since
priorities cannot easily be translated across platforms, nor the very
need of such a call
Could be soluted with fixed classes, like SDL_PRI_VERYLOW, SDL_PRI_LOW,
SDL_PRI_NORMAL, SDL_PRI_HIGH, SDL_PRI_VERYHIGH. But I don’t think
that is a good idea, because a good scheduler adepts the time needs and if there
is a thread, which gets more time, maybe he really needs it?
I think it would be VERY useful to be able to set thread priorities but
not with as high precision as is being suggested. Here comes my
reasoning: SDL is mainly focused at games but is not exclusively
game-oriented. ParaGUI is a library for building SDL applications not
games. Obviously you don’t want an application to steal all of the
processor BUT with a game you problably do.
How about just having SDL_PRI_NORMAL and SDL_PRI_HIGH?
This should be fairly portable since all multi-threaded OS’s have
some type of priorities. Plus I think this is all the precision
required for a library like SDL (it’s not Simple DirectThread Layer
-- David Snopek
/-- libksd –
| The C++ Cross-Platform Game Framework
| Only want to write it once??
| http://libksd.sourceforge.net
------------
Olivier A. Dagenais - Software Architect and Developer
“Sam Lantinga” wrote in message
news:E14aNId-0002Lb-00 at roboto.devolution.com…
Windows has a function that allows you to set the priority of a process
sothat something like a game gets more CPU time:
http://msdn.microsoft.com/library/psdk/winbase/prothred_9z1v.htm
Do other operating systems have something similar? Would this be a good
addition to SDL? (or is it already there?)It’s not portable, unfortunately. Rather than provide something that
won’t
be available most of the time, I’ve chosen not to include it in the API.
BTW, be careful when you do that, as it can starve other threads.See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
In article <d7bu7ef6.fsf at corwin.localnet.unwireduniverse.com>,
Derrell Lipman <Derrell.Lipman at UnwiredUniverse.com> writes:
David Olofson <david.olofson at reologica.se> writes:
Of course all serious OS’s have ways to change
priorities (in Unix/Linux is called “nice” and to increase your priority
you need root privileges).nice is a command line tool, rather than an API…
The API call on Linux is called setpriority() (and there’s an
equivalent getpriority() call as well.
By the way, IIRC from my own experiments with these API calls,
you can only call setpriority() to increase the priority value of
the process (i.e. decrease its effective priority), if you are not root.
Any attempt to lower it even to a positive value as a regular user will
fail, which would limit the way this could be implemented on Linux -
normal users would only be able to decrease the priority, without ever
being able to come back to the original priority.
If SDL is going include that kind of functionality, I guess we should account
for that :)–
Stephane Peter
Programmer
Loki Software, Inc.
But I don’t think
that is a good idea, because a good scheduler adepts the time needs and if
there is a thread, which gets more time, maybe he really needs it?Well, the problem is that “fair” time sharing is totally and utterly useless
for real time programming. That’s why Linux has a SCHED_FIFO mode, where the
thread entirely bypasses the timesharing system, and thus cannot be
preempted by anything but interrputs and higher priority threads.Take the examples I mentioned before; procedural texturing and texture
caching: Both need a low priority thread that pumps textures as fast as
possible, using all available CPU time, while NOT being allowed to
interfere with the rendering and audio threads. That is, the background
thread is not going to sleep until there really isn’t anything to do (which
never happens if you’re doing heavy procedural texture effects - you just
want the highest “texture frame rate” possible.)
Um, what? There’s no point in the texture frame rate going higher
than the real frame rate. Unless I totally misunderstand what you’re
saying.
If it had the same priority
as the rendering and audio threads, the timesharing scheduler would
eventually give it higher priority, resulting in massive audio drop-outs
and lots of dropped frames.
There’s an easy workaround: have the background threads sleep most of
the time when they get ahead of the main thread. That’s basically an
end-run around the scheduler, but the results should be much more
direct and predictable than doing it indirectly by mucking around with
thread priorities.On Mar 07, 2001 at 12:14 +0100, David Olofson wrote:
–
Thatcher Ulrich <@Thatcher_Ulrich>
== Soul Ride – pure snowboarding for the PC – http://soulride.com
== real-world terrain – physics-based gameplay – no view limits
But I don’t think
that is a good idea, because a good scheduler adepts the time needs and
if there is a thread, which gets more time, maybe he really needs it?Well, the problem is that “fair” time sharing is totally and utterly
useless for real time programming. That’s why Linux has a SCHED_FIFO
mode, where the thread entirely bypasses the timesharing system, and thus
cannot be preempted by anything but interrputs and higher priority
threads.Take the examples I mentioned before; procedural texturing and texture
caching: Both need a low priority thread that pumps textures as fast as
possible, using all available CPU time, while NOT being allowed to
interfere with the rendering and audio threads. That is, the background
thread is not going to sleep until there really isn’t anything to do
(which never happens if you’re doing heavy procedural texture effects -
you just want the highest “texture frame rate” possible.)Um, what? There’s no point in the texture frame rate going higher
than the real frame rate. Unless I totally misunderstand what you’re
saying.
There’s no point in regenerating slowly “mutating” textures every video
frame, even if the game runs at full frame rate. That is, the procedural
texturing engine should run at lower priority than the rendering engine,
generating textures at a frame rate independent of the video frame rate -
which would mean substantially lower frame rate, unless you have an extremely
fast CPU.
The point is to allow the game to keep running at a high and steady frame
rate, forcing the procedural texture animation to slow down when the polygon
pumping occasionally gets too heavy. (Similar to what a caching engine would
do if the disk is too slow to cope with the sector changes; tell the
rasterizer to use smaller mip-map versions until the right ones have been
loaded.)
If it had the same priority
as the rendering and audio threads, the timesharing scheduler would
eventually give it higher priority, resulting in massive audio
drop-outs and lots of dropped frames.There’s an easy workaround: have the background threads sleep most of
the time when they get ahead of the main thread. That’s basically an
end-run around the scheduler, but the results should be much more
direct and predictable than doing it indirectly by mucking around with
thread priorities.
It doesn’t work, unless the thread that’s supposed to have higher priority
can live with being starved for “extended” amounts of time when the “low
priority” thread eventually needs to do some work.
For example, in real time audio applications, audio latency should preferably
be less than 3 ms (no problems with Linux/lowlatency), whereas graphics
usually deals with frame periods in excess of 10 ms. Without priorities the
only way to do heavy video rendering (ie using more than a fraction of the
CPU power for video) while processing audio would require partial rendering
or similar hacks.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 07 March 2001 06:12, Thatcher Ulrich wrote:
On Mar 07, 2001 at 12:14 +0100, David Olofson wrote:
Take the examples I mentioned before; procedural texturing and texture
caching: Both need a low priority thread that pumps textures as fast as
possible, using all available CPU time, while NOT being allowed to
interfere with the rendering and audio threads. That is, the background
thread is not going to sleep until there really isn’t anything to do
(which never happens if you’re doing heavy procedural texture effects -
you just want the highest “texture frame rate” possible.)Um, what? There’s no point in the texture frame rate going higher
than the real frame rate. Unless I totally misunderstand what you’re
saying.There’s no point in regenerating slowly “mutating” textures every
video frame, even if the game runs at full frame rate. That is, the
procedural texturing engine should run at lower priority than the
rendering engine, generating textures at a frame rate independent of
the video frame rate - which would mean substantially lower frame
rate, unless you have an extremely fast CPU.
OK. For example, slowly swirling clouds. You probably don’t care if
the cloud swirl is a frame or two late now and then.
The point is to allow the game to keep running at a high and steady
frame rate, forcing the procedural texture animation to slow down
when the polygon pumping occasionally gets too heavy. (Similar to
what a caching engine would do if the disk is too slow to cope with
the sector changes; tell the rasterizer to use smaller mip-map
versions until the right ones have been loaded.)
I don’t think this is a good argument for thread priorities. If the
frame rate drops, then set a flag somewhere telling the procedural
texture thread to sleep instead of processing. Maybe that thread
needs to check the flag after every row generated or something (if
it’s a really CPU intensive calculation). Again, that should give
much more reliable results than hinting the scheduler.
If it had the same priority as the rendering and audio threads,
the timesharing scheduler would eventually give it higher
priority, resulting in massive audio drop-outs and lots of
dropped frames.There’s an easy workaround: have the background threads sleep most
of the time when they get ahead of the main thread. That’s
basically an end-run around the scheduler, but the results should
be much more direct and predictable than doing it indirectly by
mucking around with thread priorities.It doesn’t work, unless the thread that’s supposed to have higher
priority can live with being starved for “extended” amounts of time
when the “low priority” thread eventually needs to do some work.For example, in real time audio applications, audio latency should
preferably be less than 3 ms (no problems with Linux/lowlatency),
whereas graphics usually deals with frame periods in excess of 10
ms. Without priorities the only way to do heavy video rendering (ie
using more than a fraction of the CPU power for video) while
processing audio would require partial rendering or similar hacks.
Audio is a lot different than graphics, no argument here. With audio
you really do have a hard real-time constraint, and the thread that
feeds the audio FIFO may indeed need higher priority. That can be
buried in SDL somewhere though, if necessary. For graphics I really
don’t see the need for application-level thread priorities.On Mar 12, 2001 at 05:12 +0100, David Olofson wrote:
On Wednesday 07 March 2001 06:12, Thatcher Ulrich wrote:
On Mar 07, 2001 at 12:14 +0100, David Olofson wrote:
–
Thatcher Ulrich <@Thatcher_Ulrich>
== Soul Ride – pure snowboarding for the PC – http://soulride.com
== real-world terrain – physics-based gameplay – no view limits