NVIDIA drivers apparently cannot support EXTENDED_USAGE linear
images for whatever reason, so attempt to create these images without
the creation flag.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
For 64-bit image atomics, we should at the very least add 64-bit format
to compatibility list to avoid potential problems.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
We can bind texel buffers at scalar alignment now.
The warning is misleading for placed resources, since 64k never aligns
with a float3.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
The creation with those extensions may fail in few cases:
* older 32 bit drivers
* missing or inaccessible /dev/nvidia-uvm
There's also a mysterious crash that some Debian users experience with
64bit titles and a correct /dev/nvidia-uvm.
Signed-off-by: Arkadiusz Hiler <ahiler@codeweavers.com>
We previously did not take into account the new relaxed format compatibility
rules that we allow with CastingFullyTypedFormatSupported being supported.
Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>
Halo Infinite uses &desc->Width for total_bytes.
We can't set total_bytes early because code after this relies on desc->Width.
Signed-off-by: Robin Kertels <robin.kertels@gmail.com>
Guardians of the Galaxy hits this case. Fallback is to disable depth
attachment entirely in a fallback pipeline.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
The 16-byte requirement is kind of a lie. The real requirement is tied
to how vectorized load-store instructions are emitted in the shader
itself since I guess it allows compiler to assume something about
alignment of the base pointer.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
In d3d12, input element alignment needs to be the _minimum_ of 4 and the size of
the type. See the D3D11 spec, section 4.4.6, which behaves similarly:
https://microsoft.github.io/DirectX-Specs/d3d/archive/D3D11_3_FunctionalSpec.htm#4.4.6%20Element%20Alignment
This is correctly taken into account when generating, e.g., the
vertex_buffer_stride_align_mask used for validation, but is not taken
into account when D3D12_APPEND_ALIGNED_ELEMENT is used to automatically
place input elements. Currently, vkd3d always assumes the alignment is
4.
This means that, for example, bytes or shorts should be packed tightly
together when D3D12_APPEND_ALIGNED_ELEMENT is used, but are instead
padded to 4 bytes.
Fixing this makes units appear in Age of Empires IV (see vkd3d-proton
issue #880 for examples.)
Signed-off-by: David Gow <david@ingeniumdigital.com>
Wine VKD3D version of my original commit.
Co-authored-by: Conor McCarthy <cmccarthy@codeweavers.com>
Signed-off-by: Robin Kertels <robin.kertels@gmail.com>
The Vulkan spec update 1.2.195 restricted these features to a very limited
format subset, and somehow this is supposed to not be an API break?
Anyway, let's follow the new rules.
Signed-off-by: Georg Lehmann <dadschoorse@gmail.com>
It's common enough that new games break on RDNA2 because of this that we
should enable this by default. This matches DXVK behavior.
SOTTR gets a special weird exception, just like DXVK. The shaders are
broken enough that the proper fix is actually precise, not invariant.
This will be addressed at some later point.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Hans-Kristian Arntzen
Arkadiusz Hiler
Philip Rebohle
Georg Lehmann
Joshua Ashton
Robin Kertels
David Gow
ifedorov