This can happen if a continue statement is immediately followed
by a break instruction in a switch case.
Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>
We might have to emit to different bind point than our binding entry
suggests due to DXR, so pass down information explicitly to leaf
functions.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Refactor push constant invalidation to SetPipelineState,
it is technically more correct to only invalidate when actually pushing
constants, but we need to do full state invalidation when transitioning
between RT pipelines and non-RT pipelines due to bind point aliasing
shenanigans in D3D12, so it makes more sense to invalidate state based
on active bind point there.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Enabling VK_EXT_debug_utils comes at some overhead in Wine due to the object tracking required. There is also likely a non-zero overhead in some native implementations also.
By enabling this conditionally, we can also avoid additional overhead from apps that set debug labels on both the Vulkan and front-end side.
The default condition is to enable it when building with Renderdoc integration or in debug builds.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
This thing has no right to exist.
We don't get this information in D3D12 and it's getting in the way of me refactoring config flags.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Simplifies this to make it easier to add new properties/features
so we don't have a bunch of pointers to things that are just a child
of the device info structure.
Fixes warnings when compiling without traces too.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
When emitting push constants for graphics, these should invalidate push
constants for compute and vice versa. In Vulkan, vkCmdPushConstants is
not tied to a bind point.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Gives a massive boost on NVIDIA for some reason.
RADV defers push constant update, so ALL_STAGES doesn't have
that much of a perf hit.
~20% uplift in RE2, ~5% uplift in CP77 from some quick and dirty testing.
Seems to be heavily content dependent either way.
Also a bug fix, since we would clobber graphics push constants from
compute and vice versa if both graphics and compute used the same root
signature.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
As per MSDN, SetName is just a wrapper around SetPrivateData and a specific GUID.
Some apps and tools will use this to retrieve their name back.
So instead, just forward the name to Vulkan in the SetPrivateData call.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Instead, infer the required stages from the D3D12 shader visibility
field from all root parameters that we map to push constants.
Signed-off-by: Philip Rebohle <philip.rebohle@tu-dortmund.de>
There are pragmatic reasons for not following spec 100% here.
The only known case where UpdateAfterBind robustness is not exposed
seems to be somewhat bogus, and we cannot run D3D12 correctly without
robustness either way.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
Can only support a subset in Vulkan without extra heroics. The DXR API
lets you query things that you technically should know apriori in the
application. We might need to allocate some side-channel buffers on
demand, but let's defer that until actually needed ... :\
DXR is also very awkward in that we have a query which is resolved in
UNORDERED_ACCESS state instead of COPY_DEST state, so we'll have to
ping-pong through some barriers redundantly.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
When building acceleration structures, we need to have an
VkAccelerationStructureKHR object, but the D3D12 API just uses a plain
VA = ID3D12Resource::GetGPUVA() + offset.
For this to work, we need to resolve the VA back to VkBuffer + offset.
The only VkBuffer we can lookup is the original backing memory
allocation in the VA map, and that allocation itself must own a view
map, since we cannot tie the VA to any specific ID3D12Resource.
Since creating an RTAS is not the common path, we allocate the view map
on-demand with CAS.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>
RTAS must stay in this resource state forever. The only way to
synchronize them is UAV barriers.
Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no>