Relevant for swapchain since a swapchain resource can be presented right
away without ever having been touched by an API call.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
For correctness, we will need to defer any initial resource state
handling to the queue timeline. Here, we will build an UNDEFINED ->
common layout barrier if (and only if):
- The resource is marked to care about initial layout transition.
- We are the first queue thread to observe that initial_transition
member is 1 (atomic exchange).
- The first use of the resource was not marked to be a discard.
E.g., if the first use of the resource is an alias barrier, we must
not emit an early barrier. The only we should do here is to clear the
initial_transition member, and leave it like that.
A command list maintains a list of d3d12_resources which *might* need a
transition. For the first frame a resource is used (or so), it will not
have the flag cleared yet, so multiple command lists might add the
d3d12_resource to its own transition list. This is fine, as the queue
will resolve it.
If multiple queues see the same initial transition, there might be
shenanigans, but the application must ensure there is either a
submission boundary or fence boundary between the uses. Any initial
layout transition will only be submitted after a Wait() is observed, as
submission of the transition command buffer will be in-order with other
submissions.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
When building natively on Windows we use dllexport/dllimport for vkd3d/vkd3d_utils public exports.
When building natively on Linux we simply make those visibility default.
Nothing changes for standalone here.
Closes#152
Signed-off-by: Joshua Ashton <joshua@froggi.es>
For debugging purposes, it can be extremely useful to be able to
pinpoint and replace specific shaders for testing hypotheses.
To make this practical, change the shader dumping to use hashes rather
than monotonically incrementing indices.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
These are technically supposed to be defined in winerror.h,
but current MinGW headers do not support these yet.
Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>
winpthread is slow on Wine as it requires OS synchronization
objects, which involves wineserver.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Works by mapping a memory block on disk, and then we simply increment
u64s. The caller code only needs to use VKD3D_REGION_{DECL,BEGIN,END}
macros.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
vkd3d-shader is currently kinda buggy and crashes when you try to trace
DXBC. This used to never be run since it was guarded by
VKD3D_SHADER_DEBUG, but with the move to a static build we merged all
debug logging under VKD3D_DEBUG. Reintroduce different debug channels in
a way that is compatible with a statically linked vkd3d.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Replace this hack with a more versatile one that works for multiple compilation objects.
Consolidates this hack across all the code bases (soon to be used in a D3D12 standalone patch)
Signed-off-by: Joshua Ashton <joshua@froggi.es>
We shouldn't potentially override stuff in the std library and this allows us to map directly to __ATOMIC_* memory orders which is more correct.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Creates linking problems if we want to build vkd3d-shader statically given this links back to something in vkd3d-common.
We don't need this distinction anyways...
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Philip Rebohle
Joshua Ashton
Hans-Kristian Arntzen
Georg Lehmann