When calling glWaitSync (fence_server_sync), we added dependencies
in all batches (render and compute) on existing work. Even if
applications don't use compute at all, they theoretically could,
so we record that the compute batch depends on the render batch.
But if the application truly doesn't use compute, or rarely uses
it, we ended up recording dependencies on _all_ previous render
batches, racking up a massive list of syncobjs. Not only is this
pointless, it also meant that we never allowed the kernel to free
the underlying i915_request objects.
There are a number of solutions to this problem, but for now, we
take a simple one: when recording a new syncobj dependency, we
walk the list and see if any of them have already passed. If so,
that dependency has been fulfilled. We no longer need to track it,
and can simply drop it from the list, unreferencing the syncobj.
Android's SurfaceFlinger in particular was hitting this issue,
as it uses glWaitSync, doesn't typically use compute shaders,
and runs for long durations.
Thanks to Yang A Shi <yang.a.shi@intel.com> and
Kefei Yao <kefei.yao@intel.com> for their excellent work in
tracking down this issue!
Fixes: f459c56be6 ("iris: Add fence support using drm_syncobj")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Tested-by: Yang A Shi <yang.a.shi@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6463>
Swapping the order of the loops makes the logic much easier to follow:
for each point in our fence, if it hasn't gone by, make future work in
all batches depend on it. Both loops are necessary, and now it's
clearer why.
(This doesn't actually fix a bug but needs to be cherry-picked for
the next patch to apply, which does fix a bug.)
Fixes: f459c56be6 ("iris: Add fence support using drm_syncobj")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Tapani Pälli <tapani.palli@intel.com>
Tested-by: Yang A Shi <yang.a.shi@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6463>
I've been hacking on softpipe in the process of trying to delete a bunch
of core Mesa code, and want to make sure I don't regress desktop GL
either. The run takes under a minute and a half.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6466>
If the offset is large enough, it could affect the width. I'm also not
sure if the hardware masks the offset by 0x1f.
Found by inspection. No fossil-db changes.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6424>
This would move the old exec mask back into exec. This also fixes the
live_out_exec.
Issue found in dEQP-VK.graphicsfuzz.cosh-return-inf-unused
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Cc: 20.2 <mesa-stable>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6212>
The content of rsc->pending_ctx could be changed from multiple contexts
and thus from multiple threads. The per-context lock is not sufficient
to protect this list. Add per-resource lock to protect this list.
Fixes: e5cc66dfad ("etnaviv: Rework locking")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6454>
This function is not used, remove it.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: <mesa-stable@lists.freedesktop.org>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6454>
The VIVS_PE_DEPTH_CONFIG_DISABLE_ZS in PE_DEPTH_CONFIG caused depth
write hangs on HALTI5.
This is because the 0x11000000 bits in RA have to be toggled on
when setting this bit to zero. This combination will disable
early-z rejection on GC7000L, which was previously done through
a different bit.
Tested only on GC7000L so far.
Signed-off-by: Lukas F. Hartmann <lukas@mntre.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5456>
While TRAP_PRESENT is always at the same place, EXCP_EN can be
different between shader stages. This sets it properly.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6452>
PTB assumes that base instance to be 0 at start of tile, but hw would
not do that, we need to set it. It is worth to note that the opcode
name is somewhat confusing as what it really sets is the base
instance. We could rename the opcode, but then the name would be
different to the original Broadcom name, so confusing in any case.
This fixes several dEQP-GLES3 and dEQP-GLES31 tests that passes
individually, but started to fail depending on other tests running
before using base instance different to zero.
This is the backport of a Vulkan patch that fixed some Vulkan CTS
tests that start to fails after some other tests used an instance id.
CC: 20.2 20.1 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6447>
As with a6xx (commits beb02a78, 5785bcc8), the blob doesn't set this flag
for a5xx when fragcoords are used but not proper varyings. See for
example dEQP-GLES2.functional.shaders.builtin_variable.fragcoord_xyz.
The hope was that this would clear up separate_shader fails/flakes like it
helped with a6xx's flakes, but that didn't happen.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6464>
Return the actual number of planes in these formats (one) instead of the
number of planes used for lowering (two).
Fixes: d5c857837a ("gallium/dri2: Fix creation of multi-planar modifier images")
Acked-by: Anuj Phogat <anuj.phogat@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6449>
We got another flake, this time on
dEQP-GLES31.functional.compute.shared_var.atomic.compswap.highp_uint,
which blocked !4162 from merging. Mark the rest flaky so we don't have to
keep firefighting one test at a time.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6459>
All three passes have the same bug where, in the mov/vec case they
unconditionally return true even if they don't change anything. Throw
in a bit size check so they return false properly.
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6435>
It seems we do have some limits. Similar to older gens, # of tiles per
pipe cannot be more than 32. But I could not trigger any hangs with 16
or more tiles per pipe in either X or Y direction, so that limit does
not seem to apply.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6461>
Adds shader disk caching for nvc0 to reduce the need to every time compile
shaders. Shaders are saved into disk_shader_cache from nvc0_screen structure.
It serializes the input nv50_ir_prog_info to compute the hash key and
also to do a byte compare between the original nv50_ir_prog_info and the one
saved in the cache. If keys match and also the byte compare returns they
are equal, shaders are same, and the compiled nv50_ir_prog_info_out from the
cache can be used instead of compiling input info.
Seems to be significantly improving loading times, these are the results
from running bunch of shaders:
cache off
real 2m58.574s
user 21m34.018s
sys 0m8.055s
cache on, first run
real 3m32.617s
user 24m52.701s
sys 0m20.400s
cache on, second run
real 0m23.745s
user 2m43.566s
sys 0m4.532s
Signed-off-by: Mark Menzynski <mmenzyns@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4264>
Adds a function for serializing a nv50_ir_prog_info structure, which is
needed for shader caching.
v2 (Karol): strip nir when serializing
Signed-off-by: Mark Menzynski <mmenzyns@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4264>
Adds a function for printing nv50_ir_prog_info_out structure
in JSON-like format, which could be used in debugging.
Signed-off-by: Mark Menzynski <mmenzyns@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4264>
Adds functions for serializing and deserializing
nv50_ir_prog_info_out structure, which are needed for shader caching.
Signed-off-by: Mark Menzynski <mmenzyns@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4264>
Split out the output relevant fields from the nv50_ir_prog_info struct
in order to have a cleaner separation between the input and output of
the compilation.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4264>
The initial plan was to use this for OpenCL kernels, but back then the
plan was to convert from LLVM to TGSI. As it turns out, we didn't went
that way.
Right now for OpenCL we don't reqiure supporting multiple entry points
inside the same binary and if we want to support it later, we can add
this back.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4264>
We only need to assert this in the `io_lowered` case, which actually
uses num_outputs. This assert also doesn't appear to hold on iris,
where num_outputs is showing up as 0 (because it's likely not yet set).
Fixes assertion failures in edgeflag related tests on iris, which
doesn't use the io_lowered path currently.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3456
Fixes: 484a60d547 ("nir: generate lowered IO in nir_lower_passthrough_edgeflags")
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6450>
When using nir_lower_interpolation, we need to propagate the IO
semantics from the load_interpolated_input to the new
load_fs_input_interp_deltas intrinsics. nir_lower_io assumes
they will be filled out.
This fixes assertions in most tests on iris since commit
01ab308edc, where nir_lower_io
started reading this field.
Fixes: 01ab308edc ("nir: update IO semantics in nir_io_add_const_offset_to_base")
Fixes: 502abfce7f ("nir: save IO semantics in lowered IO intrinsics")
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6450>
Kenneth Graunke
Michel Dänzer
Samuel Pitoiset
Bas Nieuwenhuizen
Marek Olšák
Eric Anholt
Rhys Perry
Marek Vasut
Lukas F. Hartmann
Alejandro Piñeiro
Nanley Chery
Jason Ekstrand
Rob Clark
Indrajit Kumar Das
Mark Menzynski
Karol Herbst
Alyssa Rosenzweig