All drivers implement some sort of shader hashing, but each of
them does it slightly differently. Let's provide a generic helper
to avoid new copies of the same logic and encourage new drivers
to use one of the already implemented function.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17186>
Use util_sign_extend() to silence the following integer-overflow
error.
src/compiler/nir/nir_serialize.c:1333:40: runtime error: left shift of 1000165000 by 13 places cannot be represented in type 'int'
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17186>
Extend the packed_instr struct to support texops above
nir_texop_fragment_fetch_amd.
Fixes: 603e6ba972 ("nir: add two new texture ops for multisample fragment color/mask fetches")
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17186>
The postponed spill is predicated using the condition from the
last write, but this is only correct if the register was only
written once in the TMU sequence, or if it is always written with
the same predication.
While we could try to track whether this is the case or not, it
would make the postponed spill path even more complex than it
already is, so let's just avoid predicating these. We are already
discouraging TMU spilling of registers in the middle of TMU
sequences, so this should not be a very common case.
Cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17201>
If we are spilling a register that is used in the middle of a TMU
sequence, we postpone the spill until the TMU sequence finishes,
at which point we inject the spill and rewrite the original
instruction to write to the new temp.
However, this doesn't work if the register is written multiple
times during the TMU sequence. In that scenario, we need to ensure
that all writes are rewritten to use the new temp, not just the last
one.
Cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17201>
this was duplicated from the swapchain object for convenience, but really
it just leads to desync if a swapchain is shared, so use the swapchain
one instead
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17149>
if the swapchain has data, it has already passed through this function and
thus does not need to attempt to synchronize another swapchain acquire
for the same image
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17149>
Utgard supports MSAA 4x, so wire it up.
RSW bits were already REd by Luc, the only remaining part was storing
non-resolved buffers, reloading them (including for depth/stencil) and
doing MSAA resolve.
To store non-resolved buffer we need to set mrt_pitch and mrt_bits
registers in WB, and to resolve non-resolved buffer we need to reload
it into individual samples and then write out with mrt_bits = 0, it's
now done by lima blitter.
We also need to do resolve on transfer_map() of multi-sampled buffers,
so utilize u_transfer_helper for that.
As a side fix, it turns out that our wb_reg definition wasn't correct,
'zero' isn't always zero, it's set if we need to swap channels, and
it goes before mrt_bits. mrt_bits actually enables multiple MRTs,
so this commit renames 'zero' to 'flags' and changes its position.
If mrt_bits == 0 and MSAA is enabled, GPU does resolve
in place, to expose this functionality we set PIPE_CAP_SURFACE_SAMPLE_COUNT.
Fixes dEQP-GLES2.functional.multisample.*
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13963>
We have a lot of spilling coverage in a618 pre-merge, don't do it all (~2
minutes) here. Also, force-gmem touch testing should probably test less than
the default run does!
This should help make up for having added the tu-zink run.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17125>
The libvulkan-dev was needed for building zink, which ended up turning on
the vulkan tests in piglit. Split them out here.
Reviewed-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17125>
this invokes GLES-compatible point clipping, which is more consistent
with vulkan expectations and fixes a number of zink tests
Acked-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17259>
ralloc is not thread-safe. While a given context can only be accessed from a
single thread at once, multiple contexts can be created against the same screen
at once. The ralloc allocations against the shared screens will race. Depending
on the result of the race, the same block of memory can be returned as the two
new contexts in two different threads, causing a use-after-free when the context
is freed later.
We free the context explicitly when it's destroyed anyway. If screens are
getting destroyed without the contexts getting destroyed first, that's a state
tracker bug, not a Panfrost one.
This matches what Iris does.
Fixes crash in test_integer_ops.int_math on Panfrost.
Fixes: 0fcf73bc2d ("panfrost: Move to use ralloc for some allocations")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17234>
I had this in at one point to fix something, but now it somehow just
breaks fbfetch instead of fixing anything
cc: mesa-stable
fixes:
dEQP-GLES31.functional.blend_equation_advanced*
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17254>
We want to release the drawables of the context we're coming from, but
we were releasing them from the context we're switching to. This is
probably not a big deal normally because both contexts are likely to be
on the same display, which is all that driReleaseDrawables is really
sensitive to. But if the contexts are on different Displays this would
go quite wrong.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17176>
It's not needed and causes issues for mesh code (it doesn't
mark the output as per-primitive, which confuses brw_compute_mue_map)
Fixes many tests matching:
dEQP-VK.fragment_shading_rate.dynamic_rendering.*.ms
Fixes: 1542ab70eb ("anv: handle primitive shading rate for mesh")
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16196>
Otherwise passes which expect offsets to be in bytes (like
brw_nir_lower_mem_access_bit_sizes, called from brw_postprocess_nir)
may produce incorrect results.
Fixes 64-bit load/stores in task/mesh shaders.
Fixes: c36ae42e4c ("intel/compiler: Use nir_var_mem_task_payload")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16196>
The original code that was copied in was Boost licensed, so keep that
in. Since Yonggang Luo has code quite some work, keep their copyright
alongside the original one.
Fixes: b2ddec4e98 ("c11: Implement c11/time.h with c11/impl/time.c")
Fixes: e6392fcf3d ("c11: Move the implementation of threads.h into c source code")
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17232>
