This is a weird way to do queries, but in multiview, each query
takes up N slots, where N is the number of views. D3D doesn't do
it that way, and only has one result, which fortunately is a valid
way to do Vulkan queries. We just need to take care to zero out
the other view results, and make sure they get "signaled" when
the cmdbuf is submitted.
Note that it is invalid in D3D to use ResolveQueryData on query
slots that have never actually been begun/ended, so we zero out
the data by copying zeroes into the buffer. This probably could
be optimized but oh well.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20650>
For draws, when we're emulating multiview, we need to loop them
and set up the right sysval. For clears, we always need to loop.
When not emulating, we also need to set up the right view instance
mask.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20650>
From the Vulkan spec, the WAIT flag on vkCmdCopyQueryPoolResults only
serves to increase the first synchronization scope to include query end
commands, but either way, the synchronization scope only includes
commands that occur earlier in submission order. In other words, we
don't need to enforce queue ordering, a pipeline barrier is all that's
needed.
Fixes deadlocks in the timestamp.misc_tests.two_cmd_buffers_primary test.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20617>
Since we don't support wide points, this isn't a useful feature, but the CTS
requires a particular point coord value for the single rasterized pixel, based
on where the original point coord fell within the pixel. Since we're not doing
a quad, we don't get free interpolation like the GL driver does, so split the
logic between vertex (transform point center into screen space) and pixel
(compute delta between current pixel/sample and point center).
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20400>
This allows us to *much* more accurately express the app's barrier
requests. Unfortunately, there's still a few mismatches, so in those
cases we'll end up conservatively over-synchronizing/flushing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20324>
While enhanced barriers is a *much* closer model to Vulkan's, there's
still one big mismatch: Vulkan's "transfer" concept supports clears,
copies, and resolves, while D3D's closest match only supports copies.
So when doing clears and resolves, we need to transition from the copy
layout to the correct layout, and then back.
Internal barriers are done for some meta scenarios as well as render
pass initial layout transitions. These look more or less the same as
non-enhanced, we just want to avoid mixing the two paradigms if possible.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20324>
We don't need to do the command list destroy/re-create dance if the
only reference to an allocator is a *closed* command list. Using
CreateCommandList1 gives us a closed command list to start with,
which better matches the semantics of Vulkan's begin/end for
command buffers.
Now that dzn's cmdbuf reset logic puts the cmdbuf back to the
*initial* state, move the command list reset to BeginCommandBuffer.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19537>
Instead, we return errors from each of the enqueue functions and record
those errors (if any) in vk_command_buffer::record_result. This also
involves some awkward changes to each of the three drivers that uses
vk_cmd_queue but those are resolved in later commits as we convert those
drivers to the common error tracking.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16918>
The currently available D3D12 API headers have incorrect C function
prototypes for these functions when compiling for non-Windows platforms.
Future changes here will move these helpers into the DirectX-Headers
project, but:
* The process of getting a fix into the headers is still ongoing
* I'd prefer to avoid taking an immediate dependency on just-published
headers again
So, for now add some helpers to work around this problem in Dozen
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17340>
It was previously done dzn_cmd_buffer_flush_transition_barriers(),
leaving the queue+flush case unhandled. Let's fix that by moving
this piece of code to dzn_cmd_buffer_exec_transition_barriers().
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/17314>
D3D12 wants Width, Height and Depth to be aligned on the block width,
height and depth size. But Vulkan allows the width, height or depth to
be unaligned at the image boundary if image.{width,height,depth} is
not aligned.
Let's explicitly align things in the copy paths.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17250>
D3D12_RESOURCE_STATE_DEPTH_READ only provides access for fixed-function
depth/stencil test. If we want the shaders to be able to read the
depth/stencil attachment, we need to combine
D3D12_RESOURCE_STATE_DEPTH_READ and
D3D12_RESOURCE_STATE_PIXEL_SHADER_RESOURCE.
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17250>
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>
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>
