[Feature Request] Bind compiler threads to selected cores

[qinlili23333]

I'm using Intel 13th gen processor with P cores and E cores.
E cores are too weak for game logic threads, but they are suitable for shader compiling.
If a new feature that binding compiler threads to user-selected cores can be added, we can configure compiler threads on E cores only so game logic threads can use P cores with priority. This may reduce lags caused by compiler threads "chasing" logic threads to E cores.
I think it's possible to bind threads to target cores by SetThreadAffinityMask. But I'm not sure whether it's possible to implement such feature.

Maybe add the configuration like:

# Bind compiler threads to selected cores 
#
# Supported values:
# - 0 (disable, default)
# - single cores: 11,12,13,14,15,16
# - core ranges: 11-14, 18-20

# dxvk.compilerBinding = 0

[doitsujin]

This has been considered before, but I'm not sure this is really practical. There so many potential caveats:

• We need to do this programmatically in some way, I don't think requiring user interaction for this to work is acceptable. which means we need a robust way to figure out which cores are E-cores and which aren't specifically on these CPUs that works reliably on wine.
• SetThreadAffinityMask also needs to work on wine, not sure if it does (although given that WINE_CPU_TOPOLOGY exists in Proton and pins threads, it probably does).
• We'd have to deal with all sorts of weird P/E-core splits while still spawning enough shader compiler threads to avoid stutter.
• Whether or not it's beneficial or even detrimental to pin threads also heavily depends on what the game is doing.
• Windows APIs get all sorts of messy when there's more than 64 logical cores present on a system. While not common, it's not exactly outlandish anymore to have more.

And most of all, someone would actually have to test all of that.

[qinlili23333]

On Intel CPU, CPUID intrinsic can be used to determine E cores. https://www.intel.com/content/www/us/en/developer/articles/guide/12th-gen-intel-core-processor-gamedev-guide.html
But I'm not sure how AMD (and maybe even Qualcomm) implement this.

Maybe in short term, we can implement by assigning compiler threads from highest core number, as currently all big.little processors put P cores from CPU 0 and E cores at the end. This can ensure there will be enough threads for compiling, while using E cores with priority. On devices without E cores, this should have no negative impact as when compiler threads use last cores system automatically move logic threads to other cores.
But this implementation may bring negative impact on multiple-socket devices as cores may exist on different sockets which may produce a high latency, so it should be disabled when multiple CPU sockets detected.

# Assign compiler thread affinity reversely 
#
# When enabled, compiler threads are assigned from last core
# Supported values:
# - auto: default, only enable on single socket device
# - true: assign from last core
# - false: do not assign thread affinity

# dxvk.reverseCompilerAffinity = auto

The messy API for systems with more than 64 cores is really a problem, I'm also confusing about Microsoft's document.