November 2023 - Wine-GitLab

[PATCH v3 0/1] MR4409: wineboot: Compute and write the TSC frequency to registry ~Mhz.
by Marc-Aurel Zent (＠marzent) Nov. 16, 2023

Nov. 16, 2023

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

2 7

Re: [PATCH v3 0/2] MR475: vkd3d-shader/hlsl: Add radians() and degrees() functions. - approved
by Francisco Casas (＠fcasas) Nov. 16, 2023

Nov. 16, 2023

This merge request was approved by Francisco Casas. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/475

1 0

[PATCH v2 0/2] MR475: vkd3d-shader/hlsl: Add radians() and degrees() functions.
by Akihiro Sagawa (＠sgwaki) Nov. 16, 2023

Nov. 16, 2023

-- v2: vkd3d-shader/hlsl: Add degrees() function. vkd3d-shader/hlsl: Add radians() function. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/475

2 2

[PATCH 0/2] MR475: vkd3d-shader/hlsl: Add radians() and degrees() functions.
by Akihiro Sagawa (＠sgwaki) Nov. 16, 2023

Nov. 16, 2023

-- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/475

4 13

[PATCH v2 0/5] MR4409: wineboot: Compute and write the TSC frequency to registry ~Mhz.
by Marc-Aurel Zent (＠marzent) Nov. 16, 2023

Nov. 16, 2023

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

3 6

[PATCH 0/1] MR4411: fusion: Bump version to 4.6.1590.0.
by Hans Leidekker (＠hans) Nov. 16, 2023

Nov. 16, 2023

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/4411

2 1

[PATCH 0/1] MR4410: uiribbon: Fix IUIFramework::SetUICommandProperty() prototype.
by Zhiyi Zhang (＠zhiyi) Nov. 16, 2023

Nov. 16, 2023

The last parameter should be REFPROPVARIANT instead of PROPVARIANT. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4410

2 1

[PATCH v2 0/3] MR4363: wined3d: Miscellaneous fixes.
by Zebediah Figura (＠zfigura) Nov. 16, 2023

Nov. 16, 2023

-- v2: wined3d: Provide a null counter BO for slots with no corresponding XFB buffer bound. wined3d: Create the XFB counter BO in wined3d_context_vk_bind_stream_output_buffers(). d3d8: Pass NOOVERWRITE to redundantly discarded maps. https://gitlab.winehq.org/wine/wine/-/merge_requests/4363

3 5

Re: [PATCH v5 0/2] MR3854: winmm: Avoid use of hardcoded return values.
by Alistair Leslie-Hughes (＠alesliehughes) Nov. 16, 2023

Nov. 16, 2023

On Thu Nov 16 08:34:17 2023 +0000, Huw Davies wrote: > ```c > default: > FIXME("Message %s needs unmapping\n", MCI_MessageToString(msg)); > break; > ``` Sorry, I was looking at my wine-string tree, which had it removed. I'll update the patches shortly. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3854#note_52496

1 0

[PATCH 0/5] MR4409: wineboot: Compute and write the TSC frequency to registry ~Mhz.
by Marc-Aurel Zent (＠marzent) Nov. 16, 2023

Nov. 16, 2023

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 ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4409

3 5