As I wrote above I have a R5 3600 and the game settings say to use 6 threads.
NumWorkerThreads="6"
Last edited:
NVIDIA middle card
- Thread starter SergMx
- Start date
NumWorkerThreads="6"
Shadows do load the CPU.
BUT - you already said the CPU was not at 100% at most of the time. In other words, the CPU is coping with shadows already, you're not at the limit. Therefore turning shadows off doesn't help.
That means you are either GPU bound - the GPU cannot do any more processing and rendering no matter how much faster the CPU throws data at it. Or CPU<->GPU communication is a constraint, which prevents instructions and data getting to the CPU fast enough, even if the CPU is ready to send more.
It's all very well having data and pre-renders and whatnot cached in your VRAM, the CPU still has to pass instructions about what to do with that in a timely manner and if that doesn't happen, you start getting problems.
OK. I used "8" as an example. Replace "8" with "6" and that makes the maths more awkward but it doesn't change the point.
That setting means the game will try hard to keep 6 threads busy but it won't always succeed, because that is difficult to achieve.
Last edited:
That's weird. I also thought about the shadows and immediately two of these parameters turned down and nothing changed at all only the shadows in the game became spots.
And I thought that the new video cards have already learned to process shadows on the GPU.
There are a range of ways to deal with shadows which spread the load across CPU and GPU. It is increasingly common for AAA games to use techniques which get the GPU to help a lot. But we know from lots of discussion on this forum that ED's shadows engine is well off the pace, so it's very unlikely they're using the cutting-edge techniques.
It is possible "Ultra" is designed to the assumption you have a GPU where it will actually help so possibly that would ironically help take load off the CPU by turning the quality up, if you had a GPU good enough... which we have established you don't.
It is possible "Ultra" is designed to the assumption you have a GPU where it will actually help so possibly that would ironically help take load off the CPU by turning the quality up, if you had a GPU good enough... which we have established you don't.
Number of worker threads generally has a very minimal impact. The game seems to have one main game loop thread and then one or two render threads that do most of the work, irrespective of the number of worker threads.
Elite: Dangerous exposes almost no settings that are predominantly influenced by the CPU. Shadows have a modest impact, but are generally more GPU dependent than CPU dependent. Almost everything else results in the same CPU/memory limited frame rate, if there is enough GPU power for it to not be fully loaded.
Elite: Dangerous exposes almost no settings that are predominantly influenced by the CPU. Shadows have a modest impact, but are generally more GPU dependent than CPU dependent. Almost everything else results in the same CPU/memory limited frame rate, if there is enough GPU power for it to not be fully loaded.
I agree with you. I understand all these metering programs, etc. But there's still physics, and it's hard to cheat. And if I say that the CPU is cold and the load is not increasing, then it is. ( in other test programs you can see the CPU load, fan speed increase, etc.).
So outside of Elite it works correctly! But when Elite is running, it magically starts working incorrectly. I don't believe in such twists and turns.
Yes I agree that changing the CPU increases FPS, well yes a bad CPU running at 40% is slow, a good CPU running at 40% is fast but it's still the same 40%.
I think I'm making myself clear.
Another reason to use programs that poll ETWs. Very high temporal granularity and negligible overhead compared to other methods.
Many programs are not very parallel. Elite: Dangerous is one of these. It is never going to produce a high total load on a many core CPU. It's still going to be CPU limited essentially any time it's not completely GPU limited. Comparing it to easily parallelizable tasks is comparing apples to oranges. The CPU doesn't need to completely utilized to be the limiting factor.
ED 'works correctly', at least in the sense you mean here, and there is no cheating going on. Increasing CPU performance reduces the time CPU dependent tasks take and, if the CPU is the limiting factor, this will increase game frame rate.
Elite: Dangerous is fundamentally bottlenecked by one or two threads. Doesn't matter how many you spawn if the game doesn't have work for them to do, or cannot manage any more. Even within these few threads, there are frequently bubbles of inactivity, where the thread is forced to wait for other threads, or for memory accesses.
On top of all this, low polling rates can only show the average load of a logical core over the period it's polled. It won't show bursty loads, nor will it take into account that the OS scheduler likes to cycle affinity between cores much faster than typical polling rates. If you poll the CPU load every second, but a logical core spent half that time waiting on memory, or some dependency, and half that time running at maximum speed, you see ~50% load. If you poll the CPU load every second, and a thread is using every single cycle, but the OS scheduler moves the load between two logical cores every 100ms, you see ~50% load.
Logical conclusion : various test programs to measure performance and dozens of games do not work correctly and only one single ED works correctly.
I understand that it is quite difficult to write programs that work fast on the coolest CPUs and the top-end GPUs. But there are also notions of optimality and optimization, etc.
I read in a neighboring forum how people with 4090 complain about performance in Planet Coaster 2 compared to performance in Planet Coaster 1.
It reminds me of something ...
Last edited:
ED has major performance problems, but these problems aren't as mysterious or inexplicable as you've concluded.
The problem is mostly with your interpretation of what's being reported. Those programs don't measure game performance and metric you mostly seem to be focusing on is simply the fraction of non-halted CPU cycles over the duration of a given polling interval.
Likewise, the game has enough threads to keep all cores awake and active, but can only load a few of them appreciably. This results in significantly higher power than an idle CPU, but something far below peak loads. The CPU will settle at a moderate temperature based on whatever fan curve you have set.
Most modern games won't behave the way ED does, but your CPU and polling tools would respond to similar loads the same way. To see games that might use the CPU vaguely similarly to ED you generally have to go back to the dawn of DX11, if not earlier. Something like TES Oblivion or the first Crysis might be a good analog. ED's threading model probably hasn't been significantly updated since the game started serious development in 2012-2013 and was probably not cutting edge even then.
You've made your thesis clear. Yes, CPU schedulers respond to pressure and demand in strange ways, so one 40% is not, in fact, the same as another 40%. And ED does somehow fail to lean on the CPU properly sometimes and it goes "application-bound" even when there is headroom on the busy core. So that's still happening.
But, and I think I was pretty clear too, 16.66% CPU on a six core CPU is NOT the same thing as 16.66% on an eight core CPU, and the assumption of one thread one core is not a very safe assumption anyway. And the assumption that ED generates six threads and makes them all useful is just untrue as Morbad says.
I've also realised quite a lot of my apparent GPU bound is actually because me no have ReBAR on my GTX1060. So my bound is GPU behaviour but it's actually because I can't get data onto the thing in the first place.
I work with large servers and that's not really the case. I didn't write about heat dissipation (in fact, power consumption) for a reason. Nobody can cancel physics. I.e. either we get few cores 4-8 with high frequency, or many cores 12-24 etc. but with low frequency.
If one is looking at aggregate CPU load, 16.66% load on a CPU with twelve logical cores will often imply two fully loaded logical cores. The same reported 16.66% load on a CPU with 16 logical cores can imply that three cores are nearly fully loaded.
Nothing is defying physics with regard to Elite: Dangerous. On CPUs with more than six or so logical cores (where there are enough logical cores for the main game loop and the render thread to get their own) the game will only really push two of them. The video drivers for some GPUs might add another heavily loaded thread. However, most of those worker threads are doing next to nothing most of the time.
Not all loads are equal either. A CPU core can run at high frequency and still consume very little power/produce very little heat if each of those cycles isn't doing much. I can find 100% loads (i.e. CPU is in the C0 power state, at full speed, and there are no halted/idle cycles) that consume ~3W per core on a modern CPU. I can also find 100% loads that consume 15-25W per core, because they are doing vastly more work.
If you go to ~12:00 in the video I linked earlier, you can the per-thread load of a CPU limited scene in EDO. All cores are active, and all cores have work scheduled to them, but only two of the game's threads using the majority of cycles available.
Most of the CPUs in my gaming systems are 8c/16t and ED(O) will only spike power/temps on them for very brief periods during loading some loading transitions. The rest of the time, even during complex, completely CPU limited, scenes (e.g. large surface settlement CZs) total CPU load and thus power/heat is rather low. It's mostly the same story even with the 6c/12t parts I still have. Only once one gets down to four physical cores (maybe six without SMT) is a reasonably heavily total CPU load possible to sustain with this game.
Nothing is defying physics with regard to Elite: Dangerous. On CPUs with more than six or so logical cores (where there are enough logical cores for the main game loop and the render thread to get their own) the game will only really push two of them. The video drivers for some GPUs might add another heavily loaded thread. However, most of those worker threads are doing next to nothing most of the time.
Not all loads are equal either. A CPU core can run at high frequency and still consume very little power/produce very little heat if each of those cycles isn't doing much. I can find 100% loads (i.e. CPU is in the C0 power state, at full speed, and there are no halted/idle cycles) that consume ~3W per core on a modern CPU. I can also find 100% loads that consume 15-25W per core, because they are doing vastly more work.
If you go to ~12:00 in the video I linked earlier, you can the per-thread load of a CPU limited scene in EDO. All cores are active, and all cores have work scheduled to them, but only two of the game's threads using the majority of cycles available.
Most of the CPUs in my gaming systems are 8c/16t and ED(O) will only spike power/temps on them for very brief periods during loading some loading transitions. The rest of the time, even during complex, completely CPU limited, scenes (e.g. large surface settlement CZs) total CPU load and thus power/heat is rather low. It's mostly the same story even with the 6c/12t parts I still have. Only once one gets down to four physical cores (maybe six without SMT) is a reasonably heavily total CPU load possible to sustain with this game.
OK I don't really do argumentum ad authoritatem in general, but to be absolutely clear about where I am with this topic, I've worked with "large servers" since 1991, including many from the TOP500, and some that are utterly bizarre and don't do symmetrical multi-processing at all.
I think you're saying that the limiting factor of performance on a flagship consumer CPU is usually thermal in some way - OK, maybe in some cases. Marketing, yield, and diminishing returns on manufacturing gross margin are also factors. But I don't see what that has to do with how an application consumes threads and cores. The point is single-core performance is still important for games like ED.
If we disregard efficiency cores and assume symmetrical processing (which isn't true either, because all the performance parts are effectively MCM now, and don't have symmetric cache either):
- a six core CPU with two cores pegged at 100% utilisation will show 16.66% overall utilisation
- an eight core CPU with two cores pegged at 100% utilisation will show 12.5% utilisation.
And if those two parts were sold with "the same peak performance" then for any physics game, the six core part will slightly outperform the eight core part, because there are only two threads which can stay busy enough to saturate a core.
And we have efficiency cores in the mix now too, because of this. BECAUSE you cannot usually split a retail consumer-grade workload (and definitely not most games) over six or eight cores evenly, it makes sense to give those customers some large cores, to deal with the hungry threads, and some small cores, to deal with the multitasking nonsense in the background.
And all of those play so many tunes on adaptive clock speed, and work differently between different silicon vendors. Parts of the ARM architecture are very very close to a clockless design.
You can't even say that "load up all six core to 100% and it will get right up to peak design temperature" because in practice one or two cores will get slightly hotter due to differences in packaging and a bit of manufacturing RNG thrown in too.
Yes, processing information generates heat. Thank you Claude Shannon, who figured that out before we even had CPUs.
Sorry, I wonder if it's the game itself, or some process in the os ...
Highlighted fragment in black rectangle when I returned after walking around the station back to the ship. Got a clear 25 fps (instead of the usual 60)
CPU utilization showed 100%
GPU was also fully loaded there, with the performance cap reason being VRel, or reliability voltage, which is normal if there is no other limiter in play. Was probably evicting assess and loading/generating terrain.
Was this during or immediately after using the elevator to return to the hangar? That's a pretty normal place for CPU and GPU load to spike.
It was after boarding the ship. When I was already in the ship.
The ED game is very interestingly run. Sitting in the cockpit and switching through menus with stable 60fps. Then I switched to tab 1 (transactions), got a sag to 25fps. And decided not to touch anything with my hands this time. And 25fps stopped steadily. I waited about 30 seconds pressed the key and everything went back to 60fps. On the graph I highlighted this zone. I wonder how you can manage to write your own engine to make it work like this.
I think if I hadn't touched the keyboard for 5 minutes, I would have seen these 25 fps for all 5 minutes
Just pressing the key, takes the load off.