Similar to the first game it has a poor vsync implementation and physics issues when the frame rate is unlocked.
Locking to 60 FPS and enabling vsync externally provides a better experience after the ingame vsync is disabled
`GlfwWsiDriver::getInstanceExtensions` was creating an `std::vector` with a size argument in the ctor but then used `push_back` instead of filling the pre-allocated elements, leading to a bunch of nullptr entries at the start that caused an exception later on when accessed.
* Add dxvk.maxChunkSize 1 to Ubisoft Connect (UPlay)
* Add Origin Web Helper Service and fix Rockstar Games entries
* Revert Rockstar changes, improve Origin and Ubisoft
It ensures that for the same D3D commands the output VK commands
don't change between runs.
Useful for comparative benchmarking, can negatively affect performance.
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
This allows dependent projects to query the version and location of DXVK
via the pkg-config interface.
The include directories aren't yet set, because the headers aren't
installed; that will follow in a subsequent commit.
The naming of these pkg-config files is based on proposed Fedora packages
for DXVK 2.0, and is not compatible with older Fedora packages for DXVK
1.x (which used the naming convention dxvk-native-d3d9 and so on).
Packagers can create symlinks such as dxvk-native-d3d9.pc -> dxvk-d3d9.pc
if they want to retain compatibility with older names.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is necessary for compatibility with Meson's pkg module, which
generates pkg-config metadata containing "-lNAME" where NAME is the
first argument to shared_library(). Changing the name_prefix parameter
would break that.
Conversely, including .dll or .so in the first parameter would also
break that, so remove the `+dll_ext` part (in practice this is not a
functional change, because `dll_ext` is always set to an empty string).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Since we're not linking to the libraries anymore, it doesn't make much sense to
use find_library, and in fact we need to use dependency() in order to get the
right CFLAGS for includes, defines, etc, so use that instead.
As a result, we can remove the 'SDL2/' folders from the includes, making the SDL
includes more correct.
Removing these link-time dependencies is important for making a single binary that is compatible with either backend, regardless of whether or not each one is currently available to the program.
Rather than directly calling functions, the API now calls shared functions that call into a WsiDriver instance, which is allocated and implemented by the backend. Functionally this should be the same, it just has the extra allocation for the function table.
This prepares the WSI library for supporting multiple implementations in a single binary.
Unlike linear filtering this guarantees that we never read outside the source
region, and this also lets us perform color space conversion prior to filtering.
When linking pipelines, all pipeline libraries are required to declare
the exact same set of push constants, even for stages not part of the
respective libraries.
This invalidates all fossilize databases.
Without mods, Nier Replicant runs faster when going above 60 FPS.
The game had an official patch that implemented a framerate limiter to prevent this. This limiter is terrible, because it's not a stable 60 FPS, but a weird 57-58 FPS. There's no way to disable this in-game, it has to be done by editing a config file or through a mod.
So, why remove the default frame limiter from DXVK?
- In the default case (a user plays the game as it is), it does nothing, since 57-58 is lower than 60.
- If a user is going out of their way to edit the config file, why would they assume that DXVK already provides a frame limiter? They are going to follow [a guide](https://www.pcgamingwiki.com/wiki/NieR_Replicant#Framerate_limited_to_57.7E58_FPS) that says to set up a frame limiter, it doesn't say "set up a frame limiter, unless you are using DXVK, in that case it's already there".
- They are using [Special K in order to use a mod to play at high refresh rates at normal speed](https://wiki.special-k.info/SpecialK/Custom/Replicant). In this case, DXVK's default limiter is harmful, since it is not documented that it's there by default.
Since this default limiter is useless in the first two cases and harmful in the third, I think it should be removed.
The alternative would be to document this (e.g. in PCGamingWiki), but the instructions wouldn't look pretty... "After following the instructions to use Special K in order to play at higher framerates at normal speed, if are using DXVK/Proton, also do these things to disable its default 60 FPS cap: [...]"
Especially because that the game isn't broken in the default case, I don't think DXVK should tamper with these things in a way that requires documentation to revert.
Tested Special K's mod to play at higher refresh rates on Linux.
Drastically limits the amount of descriptor memory we allocate in situations
where an application renders without presenting anything to a swap chain.
The new limit is a bit tight for some real-world use cases (e.g. Ashes of the Singularity),
but at worst we will start calling vkAllocateDescriptorSets once per set and draw.
This is not a legal optimization inside non-uniform control flow due
to Vulkan's extremely permissive convergence rules, and apparently
breaks on Nvidia as a result.
Mesa drivers already do the same thing internally anyway.
When targeting ARM64EC, both __x86_64__ and _M_X86_64 are defined but
not all x86 intrinsics are present, treat EC as regular ARM64 so the
native intrinsics are used instead.
Dirt 5 does not crash without working ags anymore and Ethan Carter Redux also starts fine without a spoof.
This allows the built in AMD ags in Proton 9 to be used for these games.
The Hitman 3 config is redundant as it doesn't allow RT to be enabled without Nvapi anyway.
The uses deferred contexts for rendering if driver command lists are enabled,
but when AMDAGS is loaded, it will also unconditionally use MultiDrawIndirect
functions. Since the AGS version in use does not support deferred contexts,
this breaks rendering, so we will have to force it into the immediate context
path.
Testing also shows slightly higher performance (~3-5%) with this path in
CPU-bound scenarios.
Non-explicit conversion operators in general can participate in very
surprising conversion chains. Explicit bool operator is a good place to
start with, because even with explicit they do get automatic contextual
conversion in a lot of places, e.g., if conditions.
When assigning to a BOOL (which is an uint in disguise) and using explicit
bool conversion operators (introduced in a latter commit) an explicit cast
is required.
* The Settlers submits (possibly incorrectly) an SRV to ClearUnorderedAccessViewUint. The static_cast in the function does not translate correctly and crashes.
Native D3D11 behavior is to ignore the bad parameter entirely. It does not clear the SRV nor does it fault or even error with the DEBUG validator.
When a fence has been missed, we can avoid locking *most* of the time
via the double-checked locking pattern. We still lock before a second
check in case the scheduler caused us to miss the fence. If the
scheduler did cause us to miss the fence, we can drop the lock prior to
executing the callback function, as a second micro-optimization.
Signed-off-by: Richard Yao <richard.yao@alumni.stonybrook.edu>
Game engine physics/speed for Sonic CD is tied to frame rate so limit max frame rate to 60 fps. Otherwise, the game runs too quickly for high refresh rate monitors.
HDR in Control (a patch released by a developer post-launch, not
actually in the game sadly) tries to set a video mode with
DXGI_FORMAT_R16G16B16A16_FLOAT.
This seemingly works on Windows, and based on FindClosestMode etc
documentaton, this seems required to work for any format that scanout
it supported for.
It's really not like the bpp is meaningful on Windows with the
distinction of 8bit and 10bit not working in GDI modes at all.
Nor does it end up actually setting anything on Linux/Deck where
modesets are emulated.
So, treat DXGI_FORMAT_R16G16B16A16_FLOAT as 32bpp so the
FindClosestMatchingMode and EnterFullscreenMode calls succeed.
Game seems to be doing something horrible on its own, literally impossible
to make it run smoothly. This at least seems to limit excursions to ±10ms
and fix the camera flinging back and forth when running the game through
Gamescope.
This game (or nw.js) comes with a hard-coded frame rate limit that
behaves more like a random number generator which happens to average
out at around 16ms on a good day.
Fix this complete mess by enabling ours on top of that.
This reverts commit 79f6239df3.
Some engines use SEQUENTIAL presentation despite not making use of it, and
sparse binding is much slower than expected on Nvidia drivers, which leads
to massive performance regressions across the board.
For two reasons:
1) Some apps will only enable or attempt to enable HDR if BitsPerColor is >= 10.
2) Encouraging apps to create 10-bit swapchains for use in hardware dithering on Gamescope/Steam Deck and to have more precision thru scanout color transforms
This way, memory regions bound to consecutive pages are more likely
to end up in consecutive memory regions, which allows batching page
table updates more efficiently.
Player movement and animation can bug out at high fps like issues moving around objects and the players head detaching slightly when moving backwards.
Seems like it also helps some crash issues.
NVAPI is disabled now due to crashing issues in a wine-specific code
path within the game, but we still want it to detect the correct GPU
so that it doesn't complain about drivers and also allows users to
enable Raytracing.
Disable stdcall aliasing and enable kill-at to ensure our exported
functions don't have the @8, @40, etc suffixes.
This still keeps `--enable-stdcall-fixup` as otherwise the linker can
get confused trying to find exports from the .def. This does not result
in aliases being added, just for them to be found to add to the export
table.
This also switches d3d11 to use the MinGW provided dxgi.lib for linking
and d3d10 to use the MinGW provided d3d11.lib for linking.
Unfortunately the .a's we output seem to still have the @blah that we
killed so we cannot use them for internal linkage since using kill-at.
Tested that what we get out of MinGW now is what we want with dllexp.
Supercedes: #3590
Exports
```
➜ build git:(master) ✗ winedump -j export src/dxgi/dxgi.dll
Contents of src/dxgi/dxgi.dll: 129505860 bytes
Name: DXGI.DLL
Characteristics: 00000000
TimeDateStamp: 64C97A2D Tue Aug 1 22:33:33 2023
Version: 0.00
Ordinal base: 9
# of functions: 9
# of Names: 5
Addresses of functions: 00423028
Addresses of name ordinals: 00423060
Addresses of names: 0042304C
Entry Pt Ordn Name
00007C17 9 CreateDXGIFactory
00007BF3 10 CreateDXGIFactory1
00007B62 11 CreateDXGIFactory2
00007C3B 16 DXGIDeclareAdapterRemovalSupport
00007CD8 17 DXGIGetDebugInterface1
Done dumping src/dxgi/dxgi.dll
```
```
➜ build git:(fix-stdcall-32-bit) winedump -j export src/d3d11/d3d11.dll
Contents of src/d3d11/d3d11.dll: 263021637 bytes
Name: D3D11.DLL
Characteristics: 00000000
TimeDateStamp: 64C97A2E Tue Aug 1 22:33:34 2023
Version: 0.00
Ordinal base: 18
# of functions: 7
# of Names: 4
Addresses of functions: 005E3028
Addresses of name ordinals: 005E3054
Addresses of names: 005E3044
Entry Pt Ordn Name
00020045 18 D3D11CoreCreateDevice
000200AA 22 D3D11CreateDevice
0002010E 23 D3D11CreateDeviceAndSwapChain
0002025F 24 D3D11On12CreateDevice
Done dumping src/d3d11/d3d11.dll
```
Import of DXGI in D3D11
```
offset 005e1014 dxgi.dll
Hint/Name Table: 005E408C
TimeDateStamp: 00000000 (Thu Jan 1 01:00:00 1970)
ForwarderChain: 00000000
First thunk RVA: 005E4300
Thunk Ordn Name
005e4300 4 CreateDXGIFactory1
```
Some apps such as level editors such as Hammer World Editor, some GUI apps/launchers etc use window overrides in presentation.
Previously we'd remake a new surface every time, which was incredibly slow making these apps basically unusable.
Now we keep one surface + swapchain + image views around per window/window override we have, along with the frame latency objs + frame counter.
(Obviously an app may present to multiple windows in a frame, so for frame latency purposes we track that per-window.
The game has 3 v-sync options but doesn't explain what they do.
0 = 60 FPS
1 = Monitor Refresh Rate
2 = 30 FPS
Framerate is capped at 60 in missions and then up to monitor refresh in the main menu and tavern area
This PR would provide a better default experience for people using option 1 with high refresh displays
This trips up Stalker Anomaly for some reason, but initializing an output
is not meaningful anyway in this situation since we either know the output
in question already, or we don't and it cannot be in a non-default state.
Closes#3531.
