Thanks for the good info...
Ed
Don Burns wrote:
One more piece of information that might be important. When you run a
Producer::CameraGroup based application you will get at least these
threads:
main (includes CameraGroup)
KeyboardMouse
BackgroundThread for Each RenderSurface
Thread for Each Camera
Your KeyboardMouse and Background RenderSUrface threads should run at
high priority as they spend most of their time asleep in I/O. Camera
threads should run at normal priority and main should run at normal or
low priority.
Your main's thread is accessible by default, KeyboardMouse,
RenderSurface and Camera are all derived from OpenThread::Thread so
calling getThreadID() on each of those will work.
-don
On 9/8/06, *Don Burns* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Hi Ed,
Management of process/thread priority/scheduling is actually
orthogonal to what OSG does. Beyond simple affinity assignation
within OpenThreads, there is little support for use of hard
real-time tools.
However, the good news is that an OpenThread::Thread has a method
called getThreadID(). You can then use this to allocate to CPUS,
raise priorities to real-time, non-preemptable levels, etc. via
the tools available on RedHawk. I think these might be
implemented in the pthread interface, but I can't remember. There
should be some good docs on that and the API is fairly small and
easy to get familiar with quickly.
Let me caution you on one detail. It is often the temptation to
think of the rendering thread as the "most important" and
therefore the one we want to raise the priority on. Actually, the
opposite is true. The threads/processes for which you want
highest priority are the ones that use the CPU the least, but need
quick response. These are normally threads that are doing
critical I/O, like waiting on a joystick, a network packet, or
keyboard/mouse entry. The rendering thread is going to be
hogging most of the CPU during frame time and if you raise its
priority, the little time it takes to sleep in I/O waits, is the
only time the other components will get to do their job. This can
cause a system to feel unresponsive or eratic.
Keep your rendering thread at normal priority and raise the
priority of the light-weight tasks. Spend as little time as
possible in critical real-time sections.
-don
On 9/8/06, *Ed* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
[Anyone - Please correct me if my terminology or understanding
is incorrect]
My limited experience with Real-time programming has been with
RTLinux/RTCore. If I understand correctly, the way to write a
real-time
task with RTCore, is that it is written as a kernel
module. You have a
small main() which initializes a pthread where you task work
is done.
If I do need my rendering to be done in a real time task, is this
something that can be done with OSG? Is that how it's done under
RedHawk? Sorry this is so off topic....
Is there an example which shows how to have a separate thread,
from the
main app thread, which does all the OSG stuff?
Ed
Don Burns wrote:
> Hi Ed,
>
> Ive used OSG on RedHawk. In fact, many trips around the sun
ago, I
> used to be a systems engineer for Concurrent
Computer. IITSEC of 2003
> I put my hang-glider simulator in Concurrent's booth and drove a
> cluster, using the ccur running RedHawk as the master
channel. The
> role of graphics does not really call for hard-real time, but
some of
> the other activities associated with the simulator did,
including the
> frame scheduler and synchronization of the slave channels
with the master.
>
> The real-time extensions that CCUR brings to the Linux kernel
are the
> same ones they've been using since SVR5mp in the early
nineties, and
> conform to Posix 1003.b and 1003.c real-time standards. The
extensions
> allow for a fully preemptable kernel with resource allocation
and very
> good thread priority support.
>
> My experience was quite positive with Red Hawk.
>
> -don
>
> On 9/6/06, *Ed* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> I am working on a project which has as its end goal a
hard real-time
> system using OSG for the rendering. I have been
considering RTLinux
> Pro and RedHawk Linux as my RTOS. Anyone have any
experience, good or
> bad, with OSG on RTLinux or RedHawk? Anyone out that
using OSG in
> hard real-time?
>
> Ed
>
> _______________________________________________
> osg-users mailing list
> [email protected]
<mailto:[email protected]> <mailto:
[email protected]
<mailto:[email protected]>>
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> osg-users mailing list
> [email protected]
<mailto:[email protected]>
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected] <mailto:[email protected]>
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
------------------------------------------------------------------------
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
