Question OVP and dualcores

[Mortov Molotov]

Hello,

Since more and more pc's are sold with a dual- or quadcore CPU, I was wondering:

as the future Orbiter-version(s) will consist of two modules (orbiter-core and graphics module), will it be possible to load the graphics module in a separate CPU?

Might speed up the game, no?

Awaiting your reactions,

Mortov Molotov

 

[cjp]

If the visualization module and the simulation module are separate processes, or if they are separate threads inside the same process, then the operating system should automatically assign them to different processors. This sounds like it will be a nice side-effect of the OVP design.

So, it should work automatically. However, you can never be sure in windows of course :dry:.

 

[SethEden]

It's more a matter of the way in which the graphics client is programmed. The graphics engine will easily eat up the most CPU to be sure, esspecially when combined with self shadowing meshes and multi-lighting models. Multi-threading is more a matter of programming style to allow different threads to handle different parts of the program. For instance, one thread might be required to run a console interface, 2 threads or more for the MFD's, another thread to process cockpit commands, 1 thread for loading and unloading data and memory management, system heap information, the stack, and video memory. 1 thread to manage buffers, such as the vertex buffer, texture buffers, and frame buffers, and finally one thread to manage the rendering and device context handles. Could even make multiple threads to do rendering for multiple monitors.

There is a lot to pull together and it will take some time. One thing is for sure, a properly programed rendering engine with thread-safe design should be fully capable of taking advantage of both multiple core GPU's and multi-core CPU's equally.

Seth
www.SethEden.com

 

[Artlav]

It could work multi-threading, but it's not automatic - the graphic client is in the same serial line the Orbiter core is (unless the core runs client in different process, indications of which i didn't found).

Running too much threads for simple things like console and controls are quite inefficient, but MFD's and data loading can be worth it. Getting memory&heap manager, buffers and context handling into separate threads will give you a nightmare of synchronisation and little actual advantage.

It is worth to put separate, but parallel computations into different threads IF there are more than 1 physical CPU entity - core or whole, so the system should be designed in such a way as to allow it to run in both serial and parallel mode, not forcing CPU to multitask if there are only 1 core.

Looking in the future, when we will have dozens of cores per CPU (as intel promises soon), any part of the code that could be easily synchronized could be separated into a thread.

For the graphic client, a rendering thread and a calculating thread should be good enough. Part of the latter will be on a GPU shader.

Making OVP clients completely in a separate thread will require some restructurisation to get top efficiency - one thing is that the core should collect all the scene data into 1 buffer, that will be available to the drawing thread, updated by the core on client's request. That way the core will be running most of the time without any interruptions for multiple synchronization checks, and a client could take whatever long and strong it needs to draw.

Doesn't sound like an easy solution, too many changes all over the interface, so it's for Dr. Martin to decide.