With upcoming refactor, we might have to compile code on the fly.
To avoid any race conditions on fallback compile storing code[i] <-> StorePipeline reading code[i],
explicitly mark that code[] should be ignored.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
When we have the ability to load PSO from identifiers only, we need to
retain DXBC blobs for later.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
- Try to load SPIR-V from cache
- Fallback compile to SPIR-V if necessary
- Parse PSO metadata obtained from either compilation or cache lookup
Also moves SPIR-V compilation to end of PSO init.
Prepares for refactor where we completely decouple PSO creation info
setup and SPIR-V compilation.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Simplifies the code somewhat. Only iterate over the shader_stages LUT
once.
Adds concept of duped DXBC blobs as well.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Not super useful to create a local pipeline cache if we're not going to
compile early, but it's super rare, and cleans up the code either way.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
For deferred compilation, we need to dupe the structs.
XFB is kinda rare, so it's okay to eat allocations here.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Prepares for a situation where we can move this code into
vkd3d_create_shader_stage itself.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Make use of private references to hold on to the root signature object.
This is important in situations where we end up compiling pipelines
late.
With private references like this, there is no longer a need to
distinguish a "private_root_signature", so just rename.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Makes sure that we drop private root signature device references when
public pipeline state refcount hits 0.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
This is basically required for not horrible stutter and performance and
is widely supported.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
For this case, we want to block and teardown the debug ring thread.
It's okay to fish for dead messages in the ring, since we know there
won't be more GPU work submitted.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
If we expect device losts (breadcrumb debug), we need to use DEVICE uncached/coherent,
since we might not be able to flush GPU caches properly.
We also need to remove the idea of being able to copy out the control
block back to host. This is too brittle and we should instead just place
the control block in PCI-e BAR instead. Rethink how we pass messages
from GPU to CPU to make it more robust.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Some implementation can support marker, but not explicit coherency.
Buffer markers are often uncached either way, so should be fine ...
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Spec says that in device lost, driver must return DEVICE_LOST in finite
time, but this does not happen on NV drivers. Use a long timeout instead
in this scenario.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
AMD path for this commit.
Idea is that we can automatically instrument markers with command list
information we can make some sense of in vkd3d-proton.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Rather than having to take writer lock on serialize calls from the
outside, we should just take locks when accessing the internal hashmaps
instead.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
If outer code has taken a reader lock, we don't need to lock again.
Also allows a reader lock to go GetSerializedSize + Serialize with one
reader lock.
This will be relevant for magic cache implementation.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
It's redundant to add an UNDEFINED transition here for committed
resources. We need it for sparse and placed resources to handle aliasing
rules, but that's it.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
On some implementations, it doesn't matter for performance what we use,
and we can avoid a lot of ugly barriers this way.
Opt-in to use this extensions on GPUs we know handles it well,
otherwise, keep using the tracking paths.
With VK_KHR_dynamic_rendering, this is now feasible to do since we no longer
have to deal with shenanigans related to VkRenderPass layouts and
complicated compatibility rules.
To make this work with the existing framework, just need to consider
that GENERAL can be a common layout alongside DEPTH_STENCIL_OPTIMAL,
which are both common layouts that do not need to be tracked at all.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
In pipeline libraries, the library holds on to private references of the
libraries so that they can be rapidly loaded on-demand.
This behavior is verifed by API tests.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
When we store pipeline state in libraries we have to manage lifetime a
bit differently, which requires internal refcounts of some sort.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Required extension by VK_KHR_fragment_shading_rate and
VK_KHR_separate_depth_stencil_layouts, but we don't care about enabling
any features or use it directly.
Needed to silence validation errors.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
When performing a decay of a DSV resource, make sure to transition all
subresources, not just the particular aspect being transitioned.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
We require separate DS layouts.
Fixes validation errors where we transition from read-only, but our
neighbor aspect might have been optimal.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
These only existed for VRS attachment, which is no longer
necessary with VK_KHR_dynamic_rendering.
Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>