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]> 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.
-donOn 9/8/06, Ed < [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]>> 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]>
> 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/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
