This is needed so that we can handle two special cases:
* Dynamic buffer data is allocated out of a command-buffer-owned buffer,
rather than a descriptor-set-owned buffer, so the remapping puts them
in their own register space.
* Static samplers should be left alone and not converted to bindless.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21913>
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 operating in "bindless" mode, the device will own 2 descriptor
heaps, one for views, and one for samplers. Every time a view is
created (image view, buffer view), a slot is allocated for it out
of the device view heap for each usage type (sampled vs storage).
Then, in a future change, descriptor sets will just contain view/
sampler indices instead of actual descriptors. Instead of copying
these to a cmdbuf-owned descriptor heap, we can directly bind the
descriptor set as a buffer. We'll also modify shaders to perform
an indirection and index into the device heap.
Buffers also get views set up on creation. In a perfect world, we
could just put addresses/sizes in the descriptor set, but DXIL
doesn't support loading from addresses, we need descriptors. When
robust buffer access is disabled *or* descriptor set buffer views
reference the remainder of the buffer, we can just re-use a view
from the buffer and use an offset.
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>
Currently we can get one by looking up already-emitted resource
metadata, but in the future we'll want to be able to get this
info from a call site alone. Depending on the type of call site,
we'll have different sets of info, so add helpers for the
various different kinds of call sites we can support.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21913>
```
../src/freedreno/decode/rddecompiler.c:242:65: error: 'sscanf' may overflow; destination buffer in argument 3 has size 32, but the corresponding specifier may require size 33 [-Werror,-Wfortify-source]
if (sscanf(info->name, "%32[A-Z0-6_][%32[x0-9]].%32s", reg_name,
^
../src/freedreno/decode/rddecompiler.c:243:21: error: 'sscanf' may overflow; destination buffer in argument 4 has size 32, but the corresponding specifier may require size 33 [-Werror,-Wfortify-source]
reg_idx, field_name) != 3) {
^
../src/freedreno/decode/rddecompiler.c:243:30: error: 'sscanf' may overflow; destination buffer in argument 5 has size 32, but the corresponding specifier may require size 33 [-Werror,-Wfortify-source]
reg_idx, field_name) != 3) {
^
```
Reviewed-by: Rob Clark <robclark@freedesktop.org>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22015>
Fixes reg names with headergen2, so that if we have separate a6xx and
a7xx variants for a register we get REG_A6XX_foo and REG_A7XX_foo
instead of both being REG_A6XX_foo. Otherwise generated headers for the
kernel wouldn't compile.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22035>
