In DEATHLOOP, there is a render pass which renders out a simple image,
which is then directly followed by a compute dispatch, reading that
image. The image is still in RENDER_TARGET state, and color buffers are
*not* flushed properly on at least RADV, manifesting as a very
distracting glitch pattern. This is a game bug, but for the time being,
we have to workaround it, *sigh*.
For a simple workaround, we can detect patterns where we see these
events in succession:
- Color RT is started
- StateBefore == RENDER_TARGET is not observed
- Dispatch()
In particular, when entering the options menu, highly distracting
glitches are observed in the background.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
HZD issues an aliasing barrier for an alias of a resource that it
still needs.
Because D3D12 requires you to call DiscardResource or a full resource
clear/copy, we can just rely on those to do the actual image layout
transition and treat the aliasing barrier as a pure sync + flush.
This behavior is also observed in a test case where D3D12 drivers
do not seem to discard / fast-clear anything in an aliasing barrier.
Signed-off-by: Robin Kertels <robin.kertels@gmail.com>
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Co-authored-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Mesa RADV translates these legacy entrypoints to the 2 variants. Using
them directly will cost a bit less CPU cycles.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Mesa RADV translates these legacy entrypoints to the 2 variants. Using
them directly will cost a bit less CPU cycles.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Otherwise, we accidentally merge ranges from different pools if
the indices happen to align.
Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>
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>
Hans-Kristian Arntzen
Robin Kertels
Samuel Pitoiset
Philip Rebohle
Arkadiusz Hiler
Georg Lehmann
Joshua Ashton
David Gow