proton: limit DIRT 5 to P-cores

[pzanoni-intel]

COMMIT

Older games or their libraries may have included code that somehow made use of the CPU identifiers or hashed CPU information and that code broke in heterogeneous CPU architectures, such as newer Intel processors that have P-cores and E-cores. They would detect the different CPUs and crash or close the game.

While some of the games were already updated and don't encounter this problem anymore, some games in the wild still have this issue. In this patch we add infrastructure to restrict these games to P-cores by reading sysfs files and then setting WINE_CPU_TOPOLOGY.

For now, the only game on the list is DIRT 5.

From what I understand, what we're doing here is what Windows allegedly does through their Compatibility Fixes system, and the compatibility is called ProcessorCountLieForHybridCPU. The list of games can be queried using the "Compatibility Administrator (64-bit)" tool, which is part of the Windows Assessment And Deployment Kit (ADK). We don't seem to require this workaround for all games that Windows applies this fix for, but I haven't tested all of them.

Link: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15193
Link: #4498 (comment)

EXTRA

Here is the list of games I tested:

• DIRT 5
• Assassin's Creed: Ordissey
• Total War: THREE KINGDOMS (Proton version)
• Tomb Raider (Proton version)
• Total War: WARHAMMER 2 (Proton version)
• Wolfenstein: Youngblood

I think it would be cool if someone with access to the other games on the ADK list could try them and see if they still require the workaround.

DISCLAIMERS

I should point that I didn't extensively test this on multiple machines, so although I tried to make the WA give up in case anything went in unexpected ways, I'm not 100% sure if we won't be able to find cpu_core/cpus files in processors where we wouldn't want the workaround.

Also, the way I tested this was by directly patching the proton script in my ~/.steam/debian-installation/steamapps/common/Proton* directories, not by installing Proton from the git repository.

[gofman]

The first question is, is the same issue reproducible on Windows on the same CPU? If no, we need to identify the actual problem first and try to fix properly and universally before hacking it around. Some chance the game already has a compatibility profile (can usually be viewed in Comparibility Administrator). If there is CpuCountLie compat shim or something like that, or the game crashes the same way on Windows with the same CPU, we might think we have no bug to fix and be looking at working this around.

Then, if we confirm that hacking it is our only option, WINE_CPU_TOPOLOGY=n should already be preferring performance cores to map (see dlls/ntdll/unix/system.c:fill_cpu_override() in Proton / Wine tree) and we could just add to 'default_cpu_limit' list in Proton script, if that works. If it maps to wrong cores for some reason on specific hardware then probably we have some bug in P cores detection and that is more important than game specific overrides, that what we report to games in the first place, and should be fixed first.

[gofman]

I just checked specifically for Dirt 5 and confirmed that Windows indeed has ProcessorCountLieForHHybridCPU specifically. That perhaps fully resolves my first question, we don't have an evidence of Wine bug here and can only resort to some sort of (similar) workarounds.

Doing something like WINE_CPU_TOPOLOGY=8 is not great for this class of workarounds as it needlessly limits cpu cores below what is needed. Perhaps we should extend the Proton / Wine side hack to support something like WINE_CPU_TOPOLOGY=p which would limit to all the available P cores, instead of implementing and partially duplicating that logic in proton script. And then extend default_cpu_limit handling in Proton script so we can specify "p" there. I think the changes on the Wine side might be as easy as setting cpu_override.mapping.cpu_count performance_cores_capacity for 'p' string if performance_cores_capacity is not 0 (and not performing mapping otherwise), while this change would need a check of course.

[pzanoni-intel]

The first question is, is the same issue reproducible on Windows on the same CPU? If no, we need to identify the actual problem first and try to fix properly and universally before hacking it around. Some chance the game already has a compatibility profile (can usually be viewed in Comparibility Administrator). If there is CpuCountLie compat shim or something like that, or the game crashes the same way on Windows with the same CPU, we might think we have no bug to fix and be looking at working this around.

This is explained in the commit message. The compatibility is called ProcessorCountLieForHybridCPU, and DIRT 5 is listed there.

Then, if we confirm that hacking it is our only option, WINE_CPU_TOPOLOGY=n should already be preferring performance cores to map (see dlls/ntdll/unix/system.c:fill_cpu_override() in Proton / Wine tree) and we could just add to 'default_cpu_limit' list in Proton script, if that works.

But then, how do we figure out the value of n?

If it maps to wrong cores for some reason on specific hardware then probably we have some bug in P cores detection and that is more important than game specific overrides, that what we report to games in the first place, and should be fixed first.

[gofman]

This is explained in the commit message. The compatibility is called ProcessorCountLieForHybridCPU, and DIRT 5 is listed there.

Yes, thanks, I didn't understand the comment at once if that was checked for Dirt 5 specifically or just a generic fact that some games have it, but then I looked up on Windows and can confirm that too. In the previous comment I am suggesting to make WINE_CPU_TOPOLOGY to understand such a workaround exactly with WINE_CPU_TOPOLOGY=p instead of detecting the mapping in Proton script.

[pzanoni-intel]

Doing something like WINE_CPU_TOPOLOGY=8 is not great for this class of workarounds as it needlessly limits cpu cores below what is needed. Perhaps we should extend the Proton / Wine side hack to support something like WINE_CPU_TOPOLOGY=p which would limit to all the available P cores, instead of implementing and partially duplicating that logic in proton script. And then extend default_cpu_limit handling in Proton script so we can specify "p" there. I think the changes on the Wine side might be as easy as setting cpu_override.mapping.cpu_count performance_cores_capacity for 'p' string if performance_cores_capacity is not 0 (and not performing mapping otherwise), while this change would need a check of course.

WINE_CPU_TOPOLOGY=p makes sense, since there is already code for that. Would you prefer to do this implementation, or would you like me to attempt it? I don't mind if you do it, as if I were to do it, it would take some times since I'm new to this codebase.

The other thing to do would be to check the tames that I have not checked yet, to see if they also require the topology workaround or if their were updated with fixes to the issue.

Thanks!

[gofman]

Or perhaps we might also want to dig a bit of details of what ProcessorCountLieForHybridCPU does exactly, maybe it also limits number of cores and not necessarily reports the total amount of P cores to game? We probably want to do the same, if Windows does it, like support WINE_CPU_TOPOLOGY=4p meaning limit to 4 cores but only if we have p / e/ cores.

I can do that, it is easy either way, but I'd like to know / test that detail first on Windows. If you know already or want to figure out by testing on Windows with adding such a workaround to shim DB (fwiw a separate DB can be created and registered) that would be helpful and probably a bit more work than the actual change.

[pzanoni-intel]

Or perhaps we might also want to dig a bit of details of what ProcessorCountLieForHybridCPU does exactly, maybe it also limits number of cores and not necessarily reports the total amount of P cores to game? We probably want to do the same, if Windows does it, like support WINE_CPU_TOPOLOGY=4p meaning limit to 4 cores but only if we have p / e/ cores.

Unfortunately, specific information for this workaround does not seem to be publicly available (or I can't find it). Perhaps the best description of the general problem I can find is https://www.intel.com/content/www/us/en/developer/articles/guide/12th-gen-intel-core-processor-gamedev-guide.html#collapseCollapsible1655154304644 and the very last question of the FAQ at the very bottom of the page talks about compatibility issues.

I can do that, it is easy either way, but I'd like to know / test that detail first on Windows. If you know already or want to figure out by testing on Windows with adding such a workaround to shim DB (fwiw a separate DB can be created and registered) that would be helpful and probably a bit more work than the actual change.

I guess one way to test this would be to create an app, add it to the compatibility list, then have the app query the number of processors available? Unfortunately I don't have wide access to a variety of Windows machines as I have with Linux machines, I'll see what I can do, but feel free to go ahead if you have it more easily.

[gofman]

I guess one way to test this would be to create an app, add it to the compatibility list, then have the app query the number of processors available? Unfortunately I don't have wide access to a variety of Windows machines as I have with Linux machines, I'll see what I can do, but feel free to go ahead if you have it more easily.

Yes, that's how I was thinking to approach it. I have an Intel with P/E cores here with Windows, I will try to check that a bit later and workaround accordingly. Thanks for the contribution, and it is helpful even if the end patches end up being different, I suggest I reference this PR and your analysis in the commits.

[gofman]

I checked how that compatibility fix behaves on Windows, it does nothing on non P / E architecture, limits reported CPUs to all the P cores if no parameters present and can imit additionally (only on P / E arch) if the value is provided as fix parameter.

I implemented the similar thing as PROTON_CPU_TOPOLOGY=p[n] and added WINE_CPU_TOPOLOGY=P to overrides in proton script. That is in Proton Experimental bleeding edge: https://github.com/ValveSoftware/Proton/tree/experimental-bleeding-edge-11.0-382496-20260619-p6c5dd9-wde5152-d0dda09-v91b9ac