winevulkan: Add FSR for fshack. #116

Signed-off-by: Huw Davies <huw@codeweavers.com>

…ata. Signed-off-by: Huw Davies <huw@codeweavers.com>

The client should check that the lower SEQUENCE_MASK_BITS are zero before reading the data and confirm that the number is unchanged when it's finished. Signed-off-by: Huw Davies <huw@codeweavers.com>

…hanges. Signed-off-by: Huw Davies <huw@codeweavers.com>

Signed-off-by: Huw Davies <huw@codeweavers.com>

…tes. Signed-off-by: Huw Davies <huw@codeweavers.com>

Signed-off-by: Huw Davies <huw@codeweavers.com>

…age request. Signed-off-by: Huw Davies <huw@codeweavers.com>

Instead of doing it on every get_message request.

Now that PeekMessage may return quickly we don't want to check for driver events on every call.

Because with esync and fsync the wait happens on the client-side, so we need to make the request to do the server side effects.

So that the thread queue isn't incorrectly flagged as hung.

As well as menu owner / menu size window handles.

When the current thread is requested.

In the same way GlobalFree does already.

This will be used in LFH to recycle the thread local data.

And set extended_type heap field when HeapCompatibilityInformation is used.

This is a high performance multithreaded heap implementation that tries to minimize memory fragmentation as well. It takes inspiration from rpmalloc / tcmalloc and other thread-local heap implementations, while avoiding the complexity of a cache. The low fragmentation part is achieved by using two layers of pools, or arenas, classified by block size: * The first, coarse grained, pools are called "large" arenas, and are allocated directly by mapping 4MiB of virtual memory for each pool, which is then split into blocks of fixed size. The large arena classes are configured to support block sizes in a range from (64KiB - hs) up to (2MiB - hs), increasing by 64KiB steps, where hs is the arena header size. * The second pool layer, called "small" and "medium" arenas is built on top of the first, using the exact same mechanism (and code). Each pool is allocated by acquiring a block of (64KiB - hs) size from an arena of the first "large" class. The "small" arena classes are configured for block sizes in a range from 32 to 2048 bytes, increasing by 32B steps. The "medium" arena classes are configured for block sizes in a range from 2048 bytes up to ((64KiB - hs) - hs) / 2, increasing by 512B steps. Any memory allocation that is bigger than what "large" arenas can provide will be directly mapped from virtual memory. The multithreaded part is achieved by keeping thread local heap structures to hold the currently allocated classified arenas: * Whenever a thread needs it, a new thread local heap will be acquired from a global orphan list - using an interlocked singly linked list of unused heaps - or allocated from virtual memory. Whenever a thread terminates, it will release its thread local heap to the global orphan list. * Every alloc is done by using the current thread heap, and by allocating a new block from its arenas. The virtual memory mapping that may eventually be called is already thread safe and does not require additional locking. * Every free is deferred to the thread that allocated the block, by using an interlocked singly linked list. * Every time a thread allocates a new block, it will first cleanup its deferred free block list. The thread local heaps may not be always associated with an live thread, so this means that deferred blocks may have to wait for the orphan heap to be adopted by a new thread before they are actually released.

To prevent crashing in buffer overflows, and as Windows default heap apparently does as well. Journey does some at the very end of the game, and it sometimes silently corrupts the heap until it crashes. CW-Bug-Id: 18894

Signed-off-by: Rémi Bernon <rbernon@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org> (cherry picked from commit 8591c2a)

Signed-off-by: Rémi Bernon <rbernon@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org> (cherry picked from commit 97d2802)

Signed-off-by: Rémi Bernon <rbernon@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org> (cherry picked from commit 3b87444)

Signed-off-by: Rémi Bernon <rbernon@codeweavers.com> Signed-off-by: Jacek Caban <jacek@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org> (cherry picked from commit b18a48e)

Signed-off-by: Rémi Bernon <rbernon@codeweavers.com> Signed-off-by: Jacek Caban <jacek@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org> (cherry picked from commit d9d478e)

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. CW-Bug-Id: #18918 CW-Bug-Id: #18958

Some games such as Horizon Zero Dawn use this registry value to correlate values from rtdsc -> real time. In my testing across a few devices, 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. Fixes: #4125 (Slow motion bug) Signed-off-by: Joshua Ashton <joshua@froggi.es>

This calculates the TSC frequency once at the very start of wineboot. This avoids needing to calculate this multiple times which can lead to stalls. Signed-off-by: Joshua Ashton <joshua@froggi.es>

…Counter.

Requires kernel patches to have effect.

Some games are hanging on startup, with futexes waiting forever (even with timeout values). This is because the timeout values are been passed as Windows Epoch, instead of UNIX one. Convert the values so timeouts work again. Also, use realtime clock instead of monotonic one, so we don't need to issue another syscall do to this conversion.

In the current version of futex2 patchset, there's a proper entry point for 32bit apps that correctly parse 32bit pointers. Remove the padding hack used to make 32bit apps use the 64bit entry point.

…Odyssey out of order dialogues bug.

When not in desktop thread, instead of calling X11DRV_resize_desktop every time.

Because fshack doesn't actually change adapter modes, it's not possible to query current mode from fshack or real settings handler from another process.

So that fshack internal modes are updated in the desktop process too, from the current modes that have been written in the registry.

…ice. CW-Bug-Id: 18931

… XRandR provider. This assures that each Vulkan device has a LUID assigned (see X11DRV_InitGpu and VkPhysicalDeviceIDProperties). LUIDs are important for DirectX <-> Vulkan interop. VKD3D-Proton and DXVK's DXGI use that to identify which underlaying Vulkan device to use for the selected adapter. This change fixes GPU selection in Hitman 2 in DX12 mode. Without it VKD3D-Proton resorts to a heuristic (vid/pid matching, and if that fails use the first device in enumeration order) which can select the wrong one on some multi-GPU Nvidia setups due to nvapihack. This also fixes Forza Horizon 4 on Wayland as XWayland doesn't expose providers which results in missing LUIDs even for the GPU driving the outputs. CW-Bug-Id: #18737 CW-Bug-Id: #18925

CW-Bug-Id: 18931

This helps when dealing with the quirky c_dfDIJoystick2 format, which defines all the sliders as overlapping, i.e. rglSlider[2], rglVSlider[2], rglASlider[2] and rglFSlider[2] all share the same offset. With the Linux backends, if the device exposes enough axes (e.g. some HOTAS) we end up using rglSlider. Let's make sure we don't unnecessarily override the values there. Signed-off-by: Arkadiusz Hiler <ahiler@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org> (cherry picked from commit d10887b) CW-Bug-Id: #19048

This fixes Project CARS 3 brake problem - the game detects the controller and expects certain mapping of axes onto DIJOYSTATE2. The wheel is handled by hid_logitech_hidpp. Currently there is no way of combining accelerator and brake pedals on Linux, but on Windows that doesn't change the number or mapping of axes - it just alters the semantics of the accelerator axis. CW-Bug-Id: #19048

…trumentationCallback). CW-Bug-Id: 19085

…nInformation). CW-Bug-Id: 19085

…mationEx). CW-Bug-Id: 19085

CW-Bug-Id: 19085

…transform_create(). CW-Bug-ID: 19317

CW-Bug-ID: 19317

…a is available. CW-Bug-ID: 19317

…able. CW-Bug-ID: 19317 Fixes eFootball PES 2021 in game contents download.

…parser. Fixes race condition as wg_parser is used right away in the created thread.

Based on a patch by Andrew Wesie. Included to fix crash on startup of WRC8. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=44650 Link: https://github.com/wine-staging/wine-staging/tree/v6.3/patches/ntdll-Builtin_Prot Link: ValveSoftware#121 CW-Bug-Id: #19337

WRC8, when run in a win10 prefix, tries to load UWP/xinput1_3.dll that ships with the game. It seems to be mostly-compatible xinput implementation built on top of windows.gaming.input.dll. However if we try to replace it with the builtin the game crashes (that's the "mostly-compatible" part), so we need this override. Since our windows.gaming.input.dll implementation is just a stub controllers other than steering wheels (which are handled through dinput) do not work. It's possible to make the controllers work in the meantime by switching the prefix to win7 and adding `WINEDLLOVERRIDES="xinput1_3=b"`, as on win7 the game uses the regular xinput and is fine with our builtin. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51643 Link: ValveSoftware#121 CW-Bug-Id: #19337

WRC 8 and 9 assumes zero means no driver loaded. Link: ValveSoftware#121 CW-Bug-Id: #19337

The DIDC_FORCEFEEDBACK flag was set twice. Link: ValveSoftware#121 CW-Bug-Id: #19337

… OS version. CW-Bug-ID: #19343

…cases. CW-Bug-ID: 19335

CW-Bug-ID: 19384 Fixes Divinity The Original Sin 2 Definitive edition crash on start. This is a partial backport extracted from upstream commits 405666b, cdb1f3a (authored by Alexandre Julliard).

This game have the same issue as WRC8. Link: ValveSoftware#123 CW-Bug-Id: #19337

The compiler is completely non-functional as-is, and lives in libvkd3d-shader now. When a vkd3d release is made d3dcompiler will access it via the libvkd3d-shader public API. Accordingly there's no reason to keep it around in wine's d3dcompiler. Signed-off-by: Zebediah Figura <zfigura@codeweavers.com> Signed-off-by: Matteo Bruni <mbruni@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org> CW-Bug-ID: #15810

This probably isn't what it's going to look like upstream, for several reasons. CW-Bug-ID: #15810

Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

winevulkan: Add FSR for fshack. #116

winevulkan: Add FSR for fshack. #116

Commits on Aug 18, 2021

Commits on Aug 24, 2021

Commits on Aug 25, 2021

Commits on Aug 26, 2021

Commits on Aug 27, 2021

Commits on Aug 30, 2021

Commits on Sep 7, 2021

Commits on Sep 8, 2021

Commits on Sep 12, 2021