The scenario of:
* App binds multiple descriptor sets
* App binds a pipeline that uses a subset of them
* App binds a pipeline that uses more of them
was broken. We were only copying the descriptors for the accessible
subset before, but then clearing all dirty bits, so simply changing
the pipeline wouldn't result in more descriptors being copied.
When running not-bindless, the right thing to do is to copy *all*
descriptors if we're copying any. When running bindless, each parameter
is set separately, and more importantly, *can't* be set on the command
list if the root signature can't access them.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22371>
If the app passes us unaligned buffer offsets, we need to align them
down to the nearest aligned offset, and then put the difference into
the descriptor set buffer.
Fixes: 8bd5fbf8 ("dzn: Bind buffers for bindless descriptor sets")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22225>
Rather than trying to perfectly defrag, let's just allow re-use.
When a set is allocated for the first time, it locks in its range of
the heap that it'll use. If the last set in the heap is used, then
those descriptors go back to being free, but if a set in the middle
of the heap is freed, those descriptors remain assigned to that set.
A later allocation attempt can reclaim them, as long as the new set
fits.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21913>
When running in a bindless mode, we won't ever be using SRVs for these.
Change terminology for determining descriptor offsets from "writable"
to "alt" to match naming already used elsewhere.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21913>
A future change is going to add descriptor heaps *to* the dzn_device,
and having 3x ID3D12Device pointers in a single object just seems
wrong. All of the callers already had a device, so just pass it
along where needed.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21913>
Fix: Acquire/release should have one valid access/sync and one set
to none.
Workaround: D3D doesn't like simultaneous access resources leaving
COMMON layout, nor does it like setting UAV/RTV access bits for the
COMMON layout.
Use UNDEFINED -> UNDEFINED layout transitions, where the access bits
just aren't validated.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20919>
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>
This is the standard pattern in the kernel for providing vfunc tables
for C objects. We're using it in the pipeline cache code but we're
about to start adding more stuff and so it really helps if we have it
for command buffers as well.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18324>
Most other init functions follow the Vulkan API convention of putting
the parent object first.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18324>
