It reduces traffic between CB, DB and TCP blocks if buffers
respect a certain alignment.
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/6482>
Cleans up indentation, and clears the metadata tracking flag that would
break if this pass was used in in NIR_PASS().
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6412>
This unindents a whole bunch of code, and fixes the lack of metadata
tracking in the pass (which wasn't called in an opt loop so it hadn't been
caught before).
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6412>
The nir_shader_lower_instructions() is really nice, but it's only for SSA
operations, and sometimes you want something more general. I've put it in
nir_builder.h so it can be inlined and retain the same performance
characteristics we're used to in our lowering passes even in the absence
of LTO.
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6412>
The warning is kind of silly:
Test case 'dEQP-GLES2.functional.shaders.indexing.tmp_array.vec3_const_write_static_read_vertex'..
==1874780== Source and destination overlap in memcpy(0xa261690, 0xa261690, 160)
==1874780== at 0x484D498: __GI_memcpy (vg_replace_strmem.c:1037)
==1874780== by 0x596FC07: copy_entry_remove (nir_opt_copy_prop_vars.c:296)
The "memcpy is undefined if they overlap" thing is surely meant to be
"memcpy with *partial* overlap is undefined", but let's keep anyone else
from having to debug this.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6178>
That initial sentence must have been written ages ago ^^'
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6130>
Inspired by `src/egl/main/README.txt`, which was severely outdated, but
still contained valid information.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6130>
SPIR-V dest sizes match the input, while nir is always int32. Insert
casts from the nir op to the expected SPIR-V dest.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6313>
Specifically the bit-finding routines always return int32. Don't complain
about the dest already being 32 bits when lowering to 32 bits, and
don't bother casting the dest if it's already right.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6313>
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>
