This is my first time contributing wine and there are a lot of things I'm not sure about, so any comments are welcome. :)
--
v11: kernel32: add simple sync barrier test
kernel32: impl sync barrier
https://gitlab.winehq.org/wine/wine/-/merge_requests/4372
--
v7: vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten structured control flow instructions.
vkd3d-shader: Rename shader_instruction_array_add_icb() to shader_instruction_array_add_opaque_param().
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
--
v3: wineboot: Compute and write the TSC frequency to registry ~Mhz.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409
This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\*\\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
```
In HKEY_LOCAL_MACHINE\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor
Squashed with patches from:
* Arkadiusz Hiler <ahiler(a)codeweavers.com>
Check if the kernel trusts TSC before using it for Qpc.
Even if the bits are claiming that TSC meets our requirements the
hardware implementation may still be broken.
The Linux kernel does a lot of quality testing before deciding to use as
the clock source. If it (or the user, through an override) does not trust
the TSC we should not trust it either.
* Joshua Ashton <joshua(a)froggi.es>
Some games such as Horizon Zero Dawn use this registry value to
correlate values from rtdsc to real time.
Testing across a few devices, is seems like Windows always returns the
TSC frequency in this entry, not the current/maximum frequency of the
processor.
Returning the nominal/maximum cpu frequency here causes the game to run
in slow motion as it may not match the tsc frequency of the processor.
Ideally we'd not have to measure this and the kernel would return
tsc_khz to userspace, but this is a good enough stop-gap until
https://lkml.org/lkml/2020/12/31/72 or something similar is merged.
CW-Bug-Id: #18918
CW-Bug-Id: #18958
```
--
v2: wineboot: Add comment about TSC trust check.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4409