This reverts commit 6f25d45877, replacing it
with GLSL_PRECISION_MEDIUM. The previous commit ended up not being the
right approach, as it affected only nir vars for spirv phis and not other
nir vars, and we want a tool that does both. The new
nir_lower_mediump_vars pass can do that for you.
No fossil-db change for my angle fossils run on radv.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18259>
(cherry picked from commit e1588cdf9e)
This is a counterpart to the previous commit. When we have multiple
depth attachments, in the secondary we currently don't disable LRZ and
so we may need a valid LRZ fast-clear base.
Fixes: 4b5f0d98 ("tu: Overhaul LRZ, implement on-GPU dir tracking and LRZ fast-clear")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18369>
(cherry picked from commit f640661e54)
In
dEQP-VK.renderpass.dedicated_allocation.attachment_allocation.input_output.94
we have the following:
- There is more than one subpass, but only one depth attachment.
- The first subpass doesn't use depth.
- The subpass that does use depth has a draw call in a secondary.
We wouldn't hit the case where there's more than one depth attachment,
but because tu_begin_resumed_renderpass() only looked at the first
subpass it wouldn't find the depth attachment and would leave LRZ
invalid and thus a NULL LRZ fast-clear base. Then
tu_begin_secondary_cmdbuf() would leave LRZ enabled and the draw would
have LRZ enabled, leading to a hang.
Fix this by making tu_begin_resumed_renderpass() match
tu_begin_renderpass() with how it finds the depth attachment.
Fixes: 4b5f0d98 ("tu: Overhaul LRZ, implement on-GPU dir tracking and LRZ fast-clear")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18369>
(cherry picked from commit bf09a5881b)
When a vec4 register only uses constant value of ignore
swizzles then emit zero as register ID.
Optimizing the register use in instructions that support this type
of swizzle may lead to the situation that the RA doesn't see the
register ID, because it is actually irreleant, in this case return
zero as register ID to avoid that the assembler uselessly reports
a high requirement for registers based on a stale register ID.
Fixes: 79ca456b48
r600/sfn: rewrite NIR backend
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18343>
(cherry picked from commit ed294e0863)
The third source exists logically but not architecturally. We still need to
print it. Caught by the assertion.
Fixes: 0ee24c46e0 ("pan/mdg: Only print 2 sources for ALU")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18338>
(cherry picked from commit 6fed616187)
Otherwise the transfer from the host might not be finished
when we try to read the data.
v2: always wait before readback, but also keep the wait after
a possible readback, Itherwise TF fails in the CI.
Fixes: e87186fc67
virgl: add virgl_resource_transfer_prepare
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18243>
(cherry picked from commit 6e2b01e5b8)
We've already allocated the pipe resource, so we ought to free it
before returning.
Fixes: d8a38edc48 ("crocus: fail resource allocation properly.")
Fixes: f3630548f1 ("crocus: initial gallium driver for Intel gfx 4-7")
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18311>
(cherry picked from commit 6c7916b7f6)
With this helgrind doesn't report any races in this code.
Cc: mesa-stable
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Pierre Moreau <dev@pmoreau.org>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10752>
(cherry picked from commit 35d28251d1)
At the moment the context uses the screens object, but in order to fix
threading without having to lock too much we will have to allocate those
objects per context later.
Cc: mesa-stable
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10752>
(cherry picked from commit 607a9e1fd2)
If task redistribution is enabled, then some mesh shaders read
garbage from task payload.
It may be a hardware bug, or it may be our bug. Who knows :(
This change will probably negatively affect performance of task
shader-enabled workloads on multi-slice GPUs, because mesh shaders
will be executed only on the slice where task shader was spawned.
Fixes: ef04caea9b ("anv: Implement Mesh Shading pipeline")
Acked-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16197>
(cherry picked from commit 4eaecd7965)
The following sequence would be broken if we don't re-emit viewports.
vkCmdSetViewport()
VkCmdBindPipeline(negative_one_to_one = false)
vkCmdDraw()
VkCmdBindPipeline(negative_one_to_one = true)
vkCmdDraw()
Found by inspection.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18245>
(cherry picked from commit 64045fcf7c)
It can be useful not just to create functions, but also being able to
call them. This adds the spirv_builder-helper for this.
Cc: mesa-stable
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18244>
(cherry picked from commit 47d67912bd)
This type will be reused later on, so let's have the name describe what
is *is*, not what it's *used for*.
Cc: mesa-stable
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18244>
(cherry picked from commit 41dfed6e12)
When SSBO instructions use constant address values the address loading
is immediately ready, scheduling the address loads early increases
the register pressure, so force a new instruction block to work around
this problem.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6975
Fixes: 79ca456b48
r600/sfn: rewrite NIR backend
v2: do handling in shader block to be thread save (hinted to by Filip)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Filip Gawin <filip@gawin.net> (v1)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18212>
(cherry picked from commit c81fe5b235)
Limit the number of tested instructions and the number of
ready instructions that might be taken into account.
This reduces the time needed to run the scheduler significantly.
Fixes: 79ca456b48
r600/sfn: rewrite NIR backend
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18212>
(cherry picked from commit 1f5dccb760)
Export instructions allow burst writes, so it makes send to try
to allocate consecutive registers, but for ring writes we don't
schedule the outputs correctly to exploit this, so for now
don't mark these instructions as export to let the RA restart
picking colors.
When the scheduler starts to emit the ring writes in the right order
to allow for bust writes we might revisit this.
This fixes
spec@glsl-1.50@execution@variable-indexing@gs-output-array-vec4-index-wr
Fixes: 79ca456b48
r600/sfn: rewrite NIR backend
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6975
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18212>
(cherry picked from commit fd71cd0b6a)
Linear PE has already shown to have some rough corner cases in the hardware
and also has performance implications. Add a debug option to allow to disable
the feature, so users can more easily check if some issue is caused by this
feature.
CC: mesa-stable #22.2
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18232>
(cherry picked from commit 43eb5e777e)
When linear rendering is used together with TS, the color tiles must be fully
contained in a single row of pixels. When wrapping around to the next row
TS gets confused and records wrong tile status information, leading to visual
corruption when the surface is resolved/decompressed.
The corruption can be fixed by increasing the stride alignment for linear
render targets, but that would break some existing use-cases, as some display
engines used together with Vivante GPUs currently don't support strides that
don't match the horizontal display resolution.
For now only enable linear PE rendering when the surface is properly aligned
already. This allows to use the optimization in a lot of common use-cases, but
falls back to the proven tiled rendering with subsequent resolve into linear
for the problematic cases.
CC: mesa-stable #22.2
Fixes: 53445284a4 ("etnaviv: add linear PE support")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18232>
(cherry picked from commit ea8fc9592c)
Conflicts:
src/gallium/drivers/etnaviv/etnaviv_surface.c
The decision whether to use fast clear aka TS currently checks for two
feature bits: FAST_CEAR and MC20. We check for MC20, as TS on MC1.0 bypasses
the memory offset and we don't have any way to fixup the GPU address to
account for that. It could be done with some support of the kernel driver,
but then GPUs with MC1.0 are very rare to find these days, so not sure if we
are ever going to bother with that.
Instead of checking two separate feature bits to determine if TS can be used,
mask out the FAST_CLEAR bit from the features when MC20 isn't present. This
way we only have to check for a single feature bit.
CC: mesa-stable #22.2
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Tested-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Guido Günther <agx@sigxcpu.org>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18232>
(cherry picked from commit 09953d7b75)
If we have modifiers, we can use those to convey the tiling of exported
resources. If we have the deprecated i915 GET/SET_TILING uAPI, we can
use that to convey the tiling.
If we have neither, then we have to fall back to linear.
Fixes: e658835436 ("iris/bufmgr: Do not use map_gtt or use set/get_tiling on DG1")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6938
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18240>
(cherry picked from commit 71ace23fa7)
Sync fd fence export implies a payload reset operation, and application
can immediately do another submission with the same fence after export.
Concurrent use of the same feedback slot is incorrect. Keeping a list of
feedback slots for sync_fd external fence is a bit over designed given
those fences are usually not checked or waited by the app, but will hand
off the ownership via sync fd to an external client.
Fixes: d7f2e6c8d0 ("venus: add fence feedback")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17975>
(cherry picked from commit 5457f4c0a4)
These would only have worked in GCC and Clang, which so far wasn't an
issue, but let's clean it up anyway.
Cc: mesa-stable
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18190>
(cherry picked from commit c66622de3a)
With the following SEND instruction :
send(1) nullUD nullUD g0UD 0x4200c504 a0.1<0>UD
This instruction although valid but somewhat nonsensical (SEND message
to write at offset contained in NULL register), triggers an error in
the validator.
The restriction is that we cannot have overlapping sources. The
validator not checking the type of register incorrectly thinks that
the null register (offset 0) is the same as g0.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17555>
(cherry picked from commit 3c6fa2703d)
tcs_out_lds_offsets is not sure to be 16 byte aligned, it's
calculated like this:
num_patches * patch_vertices * lshs_vertex_stride
num_patches and patch_vertices are not sure to be any value aligned,
lshs_vertex_stride is added one extra dword, so it's only 4 byte
aligned.
This may cause problem even before we switch to nir tess output
lower when write tess factor before read tail of input. But it's
more likely to cause problem after we switch to nir tess output
lower because the main body won't eliminate the low 4bit offset
but epilog will, so they use different offset to read/write tess
factor.
Fixes: 7598bfd768 ("radeonsi: replace llvm tcs output with nir lower pass")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7083
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18174>
(cherry picked from commit ff7c59672f)
For AMD we kinda have some modifiers with a max size ... (Which is
really a compositor/kms issue, but getting them to try kinda falls
into the unsolved "how to allocate/what pitch to use" bucket, so
we solve it on the allocating side)
Cc: mesa-stable
Tested-by: Michel Dänzer <mdaenzer@redhat.com>
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18139>
(cherry picked from commit bb2a444324)
