On 3/23/2025 at 5:52 PM, blingthinger said:

Any reason you don't use XP's built in limiter?

There's a limiter?

 

21 hours ago, UrgentSiesta said:

I'm paraphrasing, but IIRC, there's a quote from Austin saying his goal is to make your CPU and GPU run at 99% all the time.

While I'm all in favor of load balancing between CPU and GPU and minimizing the lag in transferring data between them, I'd be very worried if both ran at 99% all of the time for no reason. Because that's smack dab in synthetic stress testing territory.

20 minutes ago, Bjoern said:

There's a limiter?

--lock_fr=???

24 minutes ago, Bjoern said:

While I'm all in favor of load balancing between CPU and GPU and minimizing the lag in transferring data between them, I'd be very worried if both ran at 99% all of the time for no reason. Because that's smack dab in synthetic stress testing territory.

Like I said, I'm paraphrasing, and the quote is out there.

What Austin was saying is that he wants XP to "fully utilize" the available resources, and that's in reference to the well known issue that XP is largely CPU frequency limited and single-threaded where it can't take advantage of multi-core processors.

I know they've made some progress in this regard, and that it's obviously a non-trivial task 😉 .

I'm just hopeful LR can move it forward to the same degree DCS World and MSFS have been able to do in the last year or so (DCSW in particular has dramatically increased its performance after multi-thread/core update).

14 minutes ago, UrgentSiesta said:

DCSW in particular has dramatically increased its performance after multi-thread/core update

It really did. I was surprised at the jump. And they might see another bump when vulkan is finished. What's interesting there is that even after their threading update it still only uses a few cores on average. Hardly filling up the 8-16 cores modern CPUs offer. I struggle to see XP using 100% CPU any time soon. I can't see what would be added that would need that many cores, given how much work goes to the GPU these days. Maybe tons more AI traffic? A CFD weather model might take a good chunk of the CPU if they ever got there but I'd see that on the GPU over CPU.

24 minutes ago, blingthinger said:

It really did. I was surprised at the jump. And they might see another bump when vulkan is finished. What's interesting there is that even after their threading update it still only uses a few cores on average. Hardly filling up the 8-16 cores modern CPUs offer. I struggle to see XP using 100% CPU any time soon. I can't see what would be added that would need that many cores, given how much work goes to the GPU these days. Maybe tons more AI traffic? A CFD weather model might take a good chunk of the CPU if they ever got there but I'd see that on the GPU over CPU.

Agree.

What I'm going off is tests like X-Force PC have run (they focus on building Gaming PCs specifically for XP).

Those show that it's the CPU that's generally the limiting factor in performance, and that the CPU is rarely showing high utilization.

The main way they squeeze the most performance out is with a High GHz CPU regardless of the number of cores (even a four core i3 has been shown to be fine if it's clock speed is high).

As to what LR could do with it, IDK, but I do know that I can squeeze a lot more performance out of XP if I do things like reduce World Object count, tree count and such. Which AFAIK hit the CPU much harder than the GPU (but I stand to be corrected).

And going that deep into how many cores are needed, well i'm just a hard drive monkey so IDK 😉, but it seems like there's more than a few programs out there that can take advantage of multiple cores.

IIRC the single threadedness has mostly to do with correlating all the simultaneous events into the same pipeline, which ("hazily") makes sense to me.

Anyhow...as long as it runs well and keeps getting better, I'm all for whatever they're cookin up 🙂

57 minutes ago, UrgentSiesta said:

how many cores are needed

In these heady days of nvme monkeys, it's less a question of "needed" and more one of "available". One way to slice the problem: if the algorithm needs lots of logical branches (if-then, switch, etc.) the CPU is better suited for the job. If it's embarrassingly parallel it can go to the thousands of cores on a GPU because thousands are faster than a dozen. CPU is more and more a traffic cop these days.

I can see the flight model being "branchy" but that's already insanely efficient.

23 hours ago, blingthinger said:

--lock_fr=???

Oh, right, that one. I was admittedly looking exclusively in the UI...

 

22 hours ago, blingthinger said:

Maybe tons more AI traffic?

This would already be possible if XP wasn't using (a swlightly lighter version of) its flight model for AI. Traffic Global for example controls and displays tons more aircraft than default AI because it only computes their position and heading according to some simple rules.

 

20 hours ago, blingthinger said:

I can see the flight model being "branchy" but that's already insanely efficient.

You wouldn't want the (user aircraft's) flight model to be "branchy" because keeping branches A and B in sync is a nightmare.

What could work is doing all the management stuff on core A and all the (user) flight model stuff on core B, maybe plugin stuff on core C. The remaining cores are used for (default) AI and scenery loading anyway.

3 hours ago, Bjoern said:

You wouldn't want the (user aircraft's) flight model to be "branchy" because keeping branches A and B in sync is a nightmare.

There's tons of places for branchyness in this FM: if this element is in a wake path generated by this upstream wing, use x scale factor, else use y scale factor. I don't see a need to partition out the FM by itself though. It's already very fast. What could be split out more is the individual other Ai FM calcs. I've never heard of them being light versions of the default FM. Right now they go out in batches of 3-4 per thread. Even maxed out at 19 Ai, that's only 3 additional cores in use and only for a small chunk of the frame time.

Even batching out draw functions doesn't gobble more than a couple additional cores. Maybe divide up collision detection to one more thread?

Ok, so it might hit 100% for the 6 core CPU+fast GPU folks?