Currently shouldSubmit will force the dxvk context to be flushed when
too many descriptor pools have been allocated. This heuristic does not
work when VK_NV_descriptor_pool_overallocation is in use because there
will only ever be a single pool.
This change updates the heuristic to use the number of allocated sets
when VK_NV_descriptor_pool_overallocation is in use.
The current D3D8 codebase in DXVK does not implement this
feature, i.e. setting this option is a NOP. It was
implemented in D8VK at some point, but was removed before
the big merge.
Remove any references to avoid confusion.
Since the enablement of invariant position by default the game suffers from white flickers on characters when you use the Next Generation Content option
This reverts commit 1811f4b995.
The D3D12 Beyond Good and Evil remaster uses the same exe name as the
original D3D9 game, so it turns out the separation was useful after all.
Fixes various visual issues with some effects in mods such as New Vegas Reloaded. White spots/shapes, black streaks across the screen (rain?) and probably more.
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.
