This makes things a little more flexible for groups of fields that are
arch-dependent, and allows us to use existing per-arch constant macros
instead of open-coding their values.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35408>
The name of the struct that we're currently using is panvk_ssbo_addr.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35408>
This is needed for the panvk_descriptor_state struct. All of the current
sites already included panvk_cmd_desc_state.h, so it wasn't a visible
issue.
Signed-off-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35408>
Now that nothing calls the driver create/destroy surface hooks
anymore, we can get rid of what's left from the code.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
Use pipe_surface to get the necessary information for the
various clears.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
Use pipe_surface to get the necessary information for the
various clears.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
So it can be reused from different places in the driver when
etna_surface is gone.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
If a render resource already exists, we know that a earlier check already
determined that the resource isn't compatible with the PE requirements, so
there is no point in checking again. Simply return the render resource if
it exists.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
As we want to get rid of the etna_surface, stop caching the (fast) clear
commands for the RS engine on the surface. As the pipe_surface is no
longer a CSO, we were regenerating those commands on each framebuffer
state change anyway, so the additional CPU overhead of doing this for
each clear shouldn't be too much worse.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
As another step in the direction of getting rid of etna_surface,
plug the offset calculation into all places that need it and drop
the precomputed offset from the surface struct.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
This check and especially the XXX in the comment hasn't been valid
for a long time, as our mipmap layout and render shadow code makes
sure that all levels are properly aligned for PE usage.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
Fill the reloc data when the framebuffer state is set. Now that
pipe_surface is no longer a CSO, it doesn't matter that we need
to pay the price for the computation at state set time instead
of surface_create time.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
Same as with the color buffer addresses, we don't need to track the
ZS buffer relocs in different members per GPU generation. Simply
emit the part that's relevant for the targeted GPU instance. Again
TS depth surface base is always the same address as the first depth
pipe address, so we can reuse the reloc.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
Currently we track the color buffer address information in multiple reloc
members in the compiled framebuffer state, depending on the GPU generation.
This wastes some space, as some of the relocs will never be used on any
specific GPU instance and it complicates the framebuffer state code.
Stop doing that in favor of a single PE_RT_PIPE_COLOR_ADDR reloc array to
track this information and simply fill and emit the relevant part of that
array. Additionally the TS color surface base is always equal to the first
pixel pipe color address, so we don't need to store this separately, but
can reuse the relocs from the color pipe setup.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
There are a lot of places scattered through the driver where we check
if the GPU has more than a single pixel pipe and whether the single
buffer feature is supported. All of them are trying to work out if we
need to use multitiling for the PE render targets. Add a screen spec
flag to store the result of both checks and use it where appropriate.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35406>
We already scalarize them but they might get vectorized again when
running the optimize loop before the intrinsics get turned into the
ir3-specific ones.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34311>
PresentWait2 should be possible on any physical device, as it adds a
surface capability query that depends on common wsi code.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35414>
Add common code for PresentWait2.
Unlike PresentWait, PresentWait2 is exposed by a surface capability.
On Wayland, PresentWait (and PresentWait2) require the presentation-time
extension to be available for a proper implementation, but not all
compositors support this. PresentWait would either have to be exposed
nowhere, or have weird/complicated fallback paths to try to enable it
on systems where presentation-time is unavailable.
Since PresentWait2 has a surface capability, we can simply not expose it
on Wayland when present-time is unavailable instead of always having to
have a less compliant fallback path.
PresentWait2 also explicitly forbids waiting on an ID that hasn't been
queued for presentation, so we don't need to handle that weird case.
Signed-off-by: Derek Foreman <derek.foreman@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35414>
This reverts commit 57ea689273.
This optimization is only sound when the operands of iadd are unsigned.
It turns out this is not always the case.
While the particular failure I was seeing was fixed by changing the
unsigned shifts to signed ones, I don't believe this is sound either. So
it's better to disable it for now until we find a better solution.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 57ea689273 ("ir3: optimize SSBO offset shifts for nir_opt_offsets")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34324>
Don't use the CCS_CC modifiers when fast clears are disabled
through INTEL_DEBUG=nofc. anv already behaves this way.
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35417>
It seems this will try to link to LLVM because libvulkan_radeon links to
LLVM. Without the dep_llvm and with the GCC linker (instead of mold), this
will fail if you use a custom built LLVM and it can't find the shared object.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35495>
This already landed upstream, I just forgot to update this file.
While we're at it, update the vk 1.2-entry to only list V10+, to match
reality.
Fixes: 8ec846407d ("panvk: expose vulkan 1.3 support")
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35513>
vulkanMemoryModel was the last required feature we needed to expose
Vulkan 1.3, so let's enable it!
Reviewed-by: Caterina Shablia <caterina.shablia@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35502>
We have all the pieces lined up now, so let's enable the memory model
extension.
Reviewed-by: Caterina Shablia <caterina.shablia@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35502>
It seems like a good idea to optimize barriers, so let's do the same
thing as most other drivers do.
Reviewed-by: Caterina Shablia <caterina.shablia@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35502>
NONE-barriers also needs scheduling barriers, because otherwise we can
end up with memory loads and stores being reordered during scheduling.
Reviewed-by: Caterina Shablia <caterina.shablia@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35502>
The MEMORY_BARRIER instruction has some issues, where we end up
dead-code eliminating it before it gets to do what it's supposed to do.
But even if we fix that, we have issues where we can end up inserting
flow control into it, which isn't going to work because we have nothing
to emit here either.
So let's rework this to a special-cased NOP instruction, which is marked
as a scheduling barrier. The beneft here is that NOPs are already properly
handled when it comes to flow control.
Note that this isn't perfect either; this only prevents memory operations
from crossing the scheduling barrier. We should really prevent any
operation with observable side effects from crossing the barrier. This
includes things like reading clocks etc.
But that's a larger change, and it's a step in the right direction to get
this to no longer be dead-code eliminated. So let's put this band-aid on
for now.
Fixes: f77a50e45e ("pan/bi: add a MEMORY_BARRIER pseudo-instruction")
Reviewed-by: Caterina Shablia <caterina.shablia@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35502>
Currently a cs_maybe block affects the ls_tracker of a command stream
even if the cs_maybe block is later replaced by NOP instructions. This
can lead to missing WAIT instructions in the command stream.
* Add a WAIT at the end of the cs_maybe block if the block has changed
the ls_tracker state
* At the end of a cs_maybe block, restore the ls_tracker state to what
it was before the block
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13259
Fixes: 885805560f ("panvk/csf: fix case where vk_meta is used before PROVOKING_VERTEX_MODE_LAST")
Tested-By: Alexandre ARNOUD <aarnoud@me.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35460>
On GFX12, everything is compressed with DCC and it's completely
transparent to the userspace driver.
On GFX11-GFX11.5, DCC can compress everything with GENERAL and FMASK
has been merged with DCC.
On GFX10-GFX10.3, MSAA through FMASK can't be compressed with GENERAL
and this will hurt performance.
On GFX6-9, DCC can't be supported with GENERAL because no DCC stores,
so this will destroy performance.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35424>
