[osg-users] OSG & RTOS software architecture

[Robert Osfield]

Hi Jan,

On 28 September 2016 at 06:21, Jan Cools <coolsjan at outlook.com> wrote:
> This is a more high level software architecture question considering a combination of OSG with a RTOS. My application considers 3D visualization and navigation for automatic machine control. The machine control loop will be implemented on a RTOS. In this control loop also some functions of OSG will perform some 3D calculations. For the RTOS I'm looking into the Xenomai patches for Linux. However this API is written in C while the OSG API is written in C++. I'm familiar with both languages however never attempted to combine 2 API's of different programming languages. Is it even possible what I'm trying to attempt? Any good advice?

Mixing C and C++ libs is what the OSG already does so I wouldn't
expect any issues on this front.

On the real-time front OpenGL/GLES doesn't make any claims, or provide
any controls, for hard real-time.  The closest you can get would be
classed as "soft" real-time.  On the OSG side you have to work within
this constraint.  With "soft" real-time you are working with
operations that will completely within a reasonable time frame but you
won't have guarantees that it will always finish in this time.  Things
that cause big deviations would be when your system gets overload and
the driver/OS start having to juggle memory and threads.  Your job is
then is make the whole system work efficiently and well balanced so
you don't get close to point where frame time etc. suddenly increase.

OpenThreads that the OSG uses for threading has affinity support that
helps here, and by chance you happen to post while I'm actually
working on making the affinity support in OpenThreads and the OSG more
flexible and controllable, so I'd recommend keeping tabs on this work.

For your own project you'll want to decide what threads you'll be
wanting to run and on what cores.  Make sure the OSG/OpenGL side you
stick to efficient fast paths and keep the load well below the maximum
that the system can handle - i.e. you'll need to be conservative with
how much load you push through, so to get the visual quality you want
you may need to be creative to make sure things are done efficiently
rather than just brute forcing things.

I don't have any idea of how much graphics you'll need and how this
relates to the hardware target you have in mind, it could be that you
have simple needs on the graphics side and a very capable system so
you won't need to optimize heavily as you'll be running safely anyway.
So there is chance you won't need to spend time optimizing things on
the OSG/OpenGL side, it all depends upon the requirements of your
project.

If it does turn out you do need to optimize things then be prepared to
have to lean quite a bit about how the hardware/drivers/OpenGL/OSG all
manage data and processing, there are lots of different techniques for
optimizing things so it can be a bit overwhelming to dive in, so I'd
suggest taking it step by step, creating prototypes that flesh out
different bits of what your system needs to do, lean how to do these
tasks efficiently.

In the above, where I write OpenGL I mean desktop OpenGL or OpenGL ES.

Robert.