#2332 Is the fastest multi-threading model chosen for all CPU/coure count/OS/aircraft?

[v s]

Bug report from a recent intro/review of Flightgear in linux-magazine.com on 2nd page (link ):

From 16 to 50 FPS when flying the F-15, after setting the multi-threading model to:

--prop:/sim/rendering/multithreading-mode=DrawThreadPerContext

System: Ryzen 1800X CPU (8 core), AMD RX 580 GPU, single monitor at 2540x1440. CPU bound, likely on C172p. with reported 50% GPU usage.

(There is also some incorrect statements on page 3 of the article about FG's flight dynamics when it comes to jets, one that could be sidestepped with better presentation on the main home page, and another incorrect one stating X-P is better despite being yasim like, but that's another1 topic).

---

I vaugely recall seeing the odd comment about threading mode selection in the forum e.g.:

Forum 1 lack of multithreading out of the box, which I blame for the reason why I got 30fps on my latest six-core Ryzen 5 and an RTX 2060 Super before I turned on AutomaticSelection -- FG chose one thread to max out by default [OS = Ubuntu going by forum profile]

These two are 6-8 core AMD CPUs on Linux. Is there some combination of OS/core count/CPU/aircraft for which there is a selection issue?

Kind regards

[Fernando García Liñán]

When using AutomaticSelection, the threading model is chosen by OpenSceneGraph, not FlightGear, so there is not much we can do here.

[James Turner]

One thing is we could make it dynamixally selectable, and default to 'something threaded', instead of automatic.

[Fernando García Liñán]

Also, OSG thread count won't make much of a difference on FG. See http://wiki.flightgear.org/Howto:Activate_multi_core_and_multi_GPU_support. I don't know why it does for this particular user, but that's not the norm.

[James Turner]

Hmm, I think for most people, threaading gets us a bit of a win: not a huge one but for some people it doubles it (I get about 60% more FPS depending on the mode). So it's not amazing but it's worth doing by default, I would say.

[Fernando García Liñán]

I guess that would be the case if the draw traversal times are huge, yeah...

DrawThreadPerContext is a safe default as the threading overhead is minimal with a single window, so people who don't need threading to see performance improvements won't have worse fps either.

[James Turner]

Right, for my 'slower' machines cull is bad but draw is really bad. So the overlapping there does help quite a bit. SO I'd suggest to default t DrawThreadPerContext or event CullDrawThreadPerContext. I /also/ think we can make it run-time settable (reset already does this) so people could change the property at runtime.

[Fernando García Liñán]

CullDrawThreadPerContext can be a bit risky with the Compositor ALS pipeline because it uses multiple slave cameras per context and it can decrease fps on better machines. I'd suggest to leave it at DrawThreadPerContext as a nice balance and allow an UI option as you mentioned.