These structures are not used outside this file, there's no point
sharing them with others. This also allows us to use the
mali_invocation_packed object instead of declaring a u32 array that's
big enough to contain this descriptor.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28170>
Dispatch the helpers where they are used, or inline them when they
are simple.
The only helper that's shared by the command buffer and pipeline logic
is panvk_per_arch(emit_viewport)(), and we move it to the cmd_buffer
file for now. If there's more to share, we might want to create
panvk_graphics_state.{c,h} for those.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28170>
Along with the various SW-descriptor definitions.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28170>
Note that we make DestroyBufferView() a per-arch function even if
it's not strictly needed, but given the size of the function, not
sure it's worth having a extra panvk_buffer_view.c file.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28170>
This is an attempt at splitting the driver code into logical blocks
like NVK did.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28170>
Move GetImageMemoryRequirements2(), GetImageSparseMemoryRequirements2()
and BindImageMemory2() implementations to panvk_image.c, so we have all
image related functions where they belong, and create a panvk_image.h
header for the panvk_image struct definition.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28170>
Any macro we might need and is not specific to a VkXxx object is put
in the panvk_macros.h file.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Rebecca Mckeever <rebecca.mckeever@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28170>
This will likely log more things because a bunch of them were missing.
This will also allow us to implement
VK_EXT_device_address_binding_report more easily.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28367>
In geometry shaders, calling EmitVertex() makes the contents of all
output variables undefined. We need to rewrite our layer ID and view
index outputs before each EmitVertex() call; assuming they'll preserve
their values is undefined behavior.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28067>
Currently, build_view_index and build_instance_id emit load_instance_id
intrinsics, which want the instance ID coming into the program, which is
the true instance ID multiplied by the view count.
The loop also remaps any load_instance_id in the original program back
to the true instance ID, which is the one coming in divided by the view
count. Because we call build_view_index and build_instance_id as part
of the loop, and emit the new load_instance_id instructions earlier in
the shader, we successfully avoid seeing those.
However, this is a bit fragile as it means you can't call
build_view_index or build_instance_id prior to the loop without
accidentally remapping things we don't intend to. To fix this
fragility, we save off the original instance ID (including the view
count) and directly reference that.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28067>
We were asserting that entry->dst.offset % REG_SIZE == 0, which is
easily tripped by a simple LOAD_PAYLOAD that writes a 16-bit vec2:
load_payload(8) vgrf1:UW, vgrf2+0.0:UW, vgrf3+0.0:UW
We create separate ACP entries corresponding to the values coming from
vgrf2 and vgrf3, with entry->dst set to the location within vgrf1 where
those sources get written to. So the second entry will have offset 16,
which is not REG_SIZE aligned.
It looks like this assert was originally added back in 2014 (see commit
1728e74957) and adjusted through the ages,
including at a point when we combined reg and subreg offsets into a
single byte offset, and over time also extended copy propagation.
Here the destination offset is already accounted for via rel_offset,
at the byte offset level, so things ought to work and there is no need
to assert that this is the case. Ian had already noted that the assert
tripped in commit e3f502e007, but checking
for inst->opcode == MOV here doesn't really make sense - it's just the
case that he found that broke.
Remove the erroneous assertion.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28067>
opt_copy_propagation() can sometimes propagate FIXED_GRF sources into
SHADER_OPCODE_SENDs as the message payload. For example, GS input
reads, which simply take a URB handle and have the offset in the
descriptor. For non-VGRFs, there isn't a payload to split, so just
skip past such send messages.
Fixes: 589b03d02f ("intel/fs: Opportunistically split SEND message payloads")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28067>
Originally was trying to copy a pps's scaling list when an sps's was
signaled.
Fixes: 8daa32963 ("vulkan/video: add helper to derive H264 scaling lists")
Signed-off-by: Charlie Turner <cturner@igalia.com>
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28352>
All UAVs which can be accessed via pointer need to be grouped together
starting at base 0, because nir_to_dxil emits the globals array from
[0, size], where size is the input number of globals, as well as one
for each SSBO. Images need to come after that.
Theoretically, nir_to_dxil could emit 3 arrays:
1. Globals
2. Constants
3. Printf
But constants get converted to globals early on so that'd be pretty
tricky to actually detangle.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26803>
These were intended to be shared with (e.g.) rusticl, but they're
unused and I expect they will continue to be. The spirv options
are also hardcoded to be what CLOn12 expects.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26803>
When a kernel input is a pointer to global or constant memory, it's expected
that the invoker provides the pointer value in the form of
(buffer_index << 32) | offset. The buffer index, however, is statically
knowable in the compiler, as long as a buffer is bound. Since it's
undefined behavior to dereference the pointer with no buffer bound,
we can replace any deref chain that terminates in an access with one
that uses a constant buffer index.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26803>
These handles can be emitted in control flow, which means that the handle
might be in a block which does not dominate a block that's processed
later on, which results in incorrect DXIL if we try to reference it.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26803>