Mesa OpenGL Threading Now Disabled For Small Hybrid CPUs

[phoronix]

Phoronix: Mesa OpenGL Threading Now Disabled For Small Hybrid CPUs

Landing today in Mesa 23.2-devel is support for big.LITTLE CPU detection or more broadly hybrid CPU core detection where little cores (e.g. E cores) are defined as having less than 50% the capacity of the largest CPU core on the system. This is done since Mesa's OpenGL threading is now being disabled for small hybrid processors...

https://www.phoronix.com/news/Mesa-GLThread-Disable-Small

[skeevy420]

Reading the MR comments makes me wonder if this is more of a Linux scheduler issue and not necessarily a Mesa issue. Anecdotally, because I don't have any of them, it just seems like e-cores, low powered cores, cause nothing but headaches if the OS or drivers aren't aware of them. Hardcoding Mesa with some if/thens to handle different use-cases seems like the easiest, quickest solution, not necessarily the best solution.

This seems like something that should be handled by the scheduler and a hint from the program; maybe passing something like CFS_OMIT_ECORES=1 from the user-end.

[Anux]

Michael
> ion added now with the initial user of this code being f
user -> use

Is there some internal benchmarking happening to determine if a core has 50% capacity?

[BrokenAnsible]

Reading the MR comments makes me wonder if this is more of a Linux scheduler issue and not necessarily a Mesa issue. Anecdotally, because I don't have any of them, it just seems like e-cores, low powered cores, cause nothing but headaches if the OS or drivers aren't aware of them. Hardcoding Mesa with some if/thens to handle different use-cases seems like the easiest, quickest solution, not necessarily the best solution.

This seems like something that should be handled by the scheduler and a hint from the program; maybe passing something like CFS_OMIT_ECORES=1 from the user-end.

To your point, what happens when tomorrow's E-core is as fast as today's P-core? Seems like they need a CPU id mask for this.

[schmidtbag]

I think it totally makes sense to disable GL threading when there aren't enough cores, but, I think it actually makes the most sense for the E-cores to handle these workloads. They ought to be plenty capable and it's a good use of cores that otherwise don't really help games.
Meanwhile, if GL threading could be prioritized to strictly E-cores (where available), this could help foreground userland software with scheduling issues to stick with only P-cores.

[milkylainen]

Reading the MR comments makes me wonder if this is more of a Linux scheduler issue and not necessarily a Mesa issue.

You can always blame the scheduler for everything. It's a technically valid point.
Or you can realize that ever growing complexity in assymetric hardware leads to very complex handling.
And with that comes the inevitable pitfalls when things are hard to predict.
Ie. They cause headaches even when everything is aware of them.

There are reasons for disabling hyperthreading, e-cores, assymetrical cache vs. frequency cores when running a particular load.
And this is going to vary over firmware, archs, implementations, generations and whatnot.

[billyswong]

To your point, what happens when tomorrow's E-core is as fast as today's P-core? Seems like they need a CPU id mask for this.

Or could we use a more general label such as AVOID_CORES_BELOW_PERF=0.5 ? Then cores with performance below 0.5 of the performance core will be avoided from being scheduled to run that task. Depending on the task nature, one can also set 0.25 or 0.75. The OS scheduler then determine the actual mask by CPU model.

Tomorrow's E-core being as fast as today's P-core does not matter. If the E-core is 1/3 the speed of P-core, it may be still bad idea to multithread certain tasks on hand to those E-cores, when those tasks will be bottleneck to overall computation.

[pieman]

Reading the MR comments makes me wonder if this is more of a Linux scheduler issue and not necessarily a Mesa issue. Anecdotally, because I don't have any of them, it just seems like e-cores, low powered cores, cause nothing but headaches if the OS or drivers aren't aware of them. Hardcoding Mesa with some if/thens to handle different use-cases seems like the easiest, quickest solution, not necessarily the best solution.

This seems like something that should be handled by the scheduler and a hint from the program; maybe passing something like CFS_OMIT_ECORES=1 from the user-end.

with my 13700kf, the only game i've ran into where i noticed e core being prioritize over my p cores has been warcraft 3 reforged. i don't mind because the game actually still performs very well (100fps+ and FAR less power usage), but its been the only one. battlefield v, rust on deadlock server, fallout new vegas, satisfactory, factorio, cyberpunk all schedule on the p cores correctly. i think no matter what big.LITTLE will always have scheduler problems. comes down to how well the thread dispatcher works and communicates with the scheduler and i don't think either will ever be perfect.
even windows 11 isn't perfect too. before i installed linux as my only OS, i had windows 11 on here for a month just to do my normal stability testing when i build a new computer (makes rmaing easier if hardware problems are found) and i had issues with command and conquer remastered going onto the e cores instead of p cores with it.

[schmidtbag]

You can always blame the scheduler for everything. It's a technically valid point.
Or you can realize that ever growing complexity in assymetric hardware leads to very complex handling.
And with that comes the inevitable pitfalls when things are hard to predict.
Ie. They cause headaches even when everything is aware of them.

There are reasons for disabling hyperthreading, e-cores, assymetrical cache vs. frequency cores when running a particular load.
And this is going to vary over firmware, archs, implementations, generations and whatnot.

What I don't get is why there hasn't been some sort of profiling system by now that automatically sets core/thread affinity, where there is a database of every CPU architecture with its strengths and weaknesses defined and applications that are told which cores/threads they're allowed to use. Then, you have a set of default behaviors depending on the user or the directory the binary came from.
So for some examples with a 13th gen Intel CPU:
A typical game would be dedicated to P cores, no logical threads
Code compilers would be dedicated to P cores and their logical threads, maybe E cores if they're idle
FUSE would be dedicated to E cores
Unlisted userland applications default to P cores with logical threads
Unlisted kernel processes default to E cores.
If one set of cores is idle and the other is fully utilized, shift priorities.
And so on.

[stormcrow]

I think it would be instructive if we knew how MacOS handles P/E core CPUs, because it's the only platform that seems to be doing it well enough without user intervention. In Windows you have to babysit processes if you find performance is lacking by stopping the Windows scheduler from dropping the processes to "efficiency mode" when it's unnecessary or unwanted (and you have to deal with any thermal or battery life issues if you do). Linux isn't immune to this problem on such CPUs, either. It's just slightly better at it than Windows. Makes me glad I'm sitting on an AMD desktop without those issues for the foreseeable future. My MBP just kinda chugs along without me having to notice how it's balancing performance and efficiency C/GPU cores. Ideally this should all be user-invisible, but the practicality with these chips is that it's obviously not entirely so for the current Intel CPU PCs.

More off topic: If you've read the review articles, this problem is coming home to roost as some news outlets that have traditionally been Intel friendly are now pointing out that there's no compelling reason to buy 13th Gen CPUs compared to 12th Gen because the (Windows) performance characteristics for productivity tasks are nearly flat given the price differential. It's something many have already been pointing out, it's just kinda shocking to see media reporters who usually drive the hype on any Intel CPU release train poo-pooing them.