Sometimes there's no obvious mappings between a VkImageLayout and
a D3D12_RESOURCE_STATE, so let's just provide a helper that takes
before/after resource states instead of old/new layouts, and use it
to fix the resolve case.
Fixes: 35356b1173 ("dzn: Cache and pack transition barriers")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17250>
We are about to introduce the same function taking D3D12_RESOURCE_STATES
arguments instead of VkImageLayout ones. Let's rename the function
accordingly.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17250>
We want to pack ResourceBarriers() call as much as we can, so let's
not dzn_cmd_buffer_queue_transition_barriers() when we could still queue
new barriers.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17250>
Some Vulkan -> D3D12 API mismatches force us to do behind-the-scene
transitions to get resources in the right state when executing
non-native operations. In this case, caching the transition until the
resource is actually used might save us unneeded transitions.
The packing aspect is mostly useful to limit the ExecuteBarriers()
call overhead. Right now we do per-resource packing, and any hole
in the subresource range will trigger several ExecuteBarriers()
calls. This can be improved by collecting barriers in a separate
array, and flushing the collected transition barriers just before
executing the operation using the subresources pointed by those
barriers. While not impossible, it'd be more verbose than what we
have right now, so I'm not entirely convinced it's worth it.
Caching could be improved to avoid any unnecessary flush when we do
blit or copy operations and transition the resources back to their
original state, since the user might decide to transition the image to
a new layout just after that. But doing that would require keeping
track of all resources used by dispatch/draw operations, which in turn
implies keeping info about which of the descriptor set resources are
used by the graphics/compute pipelines. Not sure the it's worth the
extra complexity given D3D12 enhanced barriers are just around the
corner, and those map pretty nicely to the vulkan barrier+image-layout
model.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17274>
The original offset value is overwritten in our first for(i: num_states)
iteration, messing up the compute push constant update if stageFlags
applies to both compute and graphics.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17233>
Now that we have support for pipeline variants, we can take the dynamic
depth testing parameters into account and create a new pipeline state
using those dynamic parameters.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16971>
We were completely ignoring the primitive-restart case in the
index-rewrite logic used to emulate triangle fans. Unfortunately, this
case is way more complicated than a regular index rewrite:
- we need to skip all primitive-restart entries when turning the triangle
fan into a triangle list, which implies serializing the index buffer
rewrite procedure (at least I didn't find any clever way to parallelize
things)
- the number of triangles can no longer be extrapolated from the number
of indices in the original index buffer, thus forcing us to lower
direct indexed draws into indirect draws and patching the indexCount
value when the new index buffer is forged
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16971>
We can't hardcode the strip cut value to 0xffffffff, otherwise we break
support for 16-bit index buffers. Let's use the pipeline variant
infrastructure to deal with that case.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16971>
Some D3D12 states can't be updated dynamically and require the creation
of a new pipeline state. In order to support setting those dynamically
we will have to support creating pipeline variants at draw time.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16971>
This fixes a crash in this test:
dEQP-VK.renderpass2.suballocation.simple.color_unused_omit_blend_state
Fixes: 2d0798440b ("dzn: Add support for dynamic rendering")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17027>
This logic accidentally got flipped in a refactoring. Let's correct it!
Fixes: e293691a99 ("dzn: Get rid of the render pass logic")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16997>
VkRenderingAttachmentInitialLayoutInfoMESA provides information about
the initialLayout -> currentLayout that's expected when we begin a
render pass. Let's take it into account.
Fixes: 2d0798440b ("dzn: Add support for dynamic rendering")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16792>
The key is supposed to be the dzn_event pointer, not the VkEvent
object, even if they do match in practice on 64bit builds.
Fixes: a012b21964 ("microsoft: Initial vulkan-on-12 driver")
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16109>
Unfortunately it's not as simple as passing the indirect draw count
buffer to ExecuteIndirect. The compute job that populate the execute
buffer also needs to know the number of entries that need to be
patched. Instead of transitioning the indirect count buffer from
GENERIC_READ to INDIRECT_ARGUMENT we just keep at as a read-only
resource and copy the draw_count value to the exec buffer in the
compute job.
Acked-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15914>
The core provides generic render-pass -> dynamic-rendering wrappers,
so let's rely on them instead of implementing our own logic.
Suggested-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15913>
This is how D3D12 works, so nothing really complicated here. We just
add a bunch of states to the render state, patch the pipeline building
logic to support dynamic rendering, and add new functions to
Suggested-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15913>
Let the caller extract the image view from the attachment index, so
we can make this function framebuffer-agnostic and re-use it in the
dynamic rendering path.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15913>
This does quite a lot in one go, simply because C and C++ are too
different to cleanly move from one language to another. But hopefully
this won't create too many rebase-issues.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15816>
2022-04-19 15:39:48 +00:00
Renamed from src/microsoft/vulkan/dzn_cmd_buffer.cpp (Browse further)
