While there seems to be no bug with the state things are today, I was
recently doing some debugging and put an iris_bo_wait() before a
bo_close() in iris_bufmgr_destroy(), which caused an issue since the
bo_deps_lock mutex had already been destroyed.
Since there are quite a few things we do with the bufmgr after
destroying the mutexes, I figured we should probably postpone mutex
destruction in order to be a little safer against future code
modifications like the one I just did.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13494>
This should make it easier to tune the runtime, and enable KHR-GL* tests
in the future. (Not done currently because something in KHR-GL* causes
oomkiller).
This drops the redundant FDO_CI_CONCURRENT settings, since the default on
these boards is 4 anyway.
Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13504>
The original implementation in os_memory_fd.c always uses memfds.
Replace this by using the already existing os_create_anonymous_file in
order to support older systems or systems without memfd.
Fixes: 1166ee9caf ("gallium: add utility and interface for memory fd allocations")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13331>
This seems simpler and probably faster.
This also fixes a warning for these CTS tests:
dEQP-VK.pipeline.creation_feedback.graphics_tests.vertex_stage_geometry_stage_delayed_destroy_fragment_stage_delayed_destroy
dEQP-VK.pipeline.creation_feedback.graphics_tests.vertex_stage_geometry_stage_fragment_stage
because we no longer set found_in_application_cache=false for pipelines
with NGG GS.
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/13528>
This was not quite correct in that our checks for the allowed cases
were not checking that there were no other peripheral access other
than the ones allowed.
For example, we allowed wrtmuc signal and TMU write other than
TMUC, and we also allowed TMU read and VPM read/write. But we
cannot allow wrtmuc with TMU write other than TMUC and at the
same time a VPM write for example, so we can't just check if we
have a combination of allowed peripherals, we still need to check
that those are the only ones in use by the combined instructions.
Another example is that even if we allow a TMU write (other than TMUC)
with a wrtmuc signal, the resulting instruction must still have just
one TMU write other than TMUC, but we were allowing the merge if one
instruction signaled wrtmuc and the other wrote to tmu other than tmuc
without testing if the combined result would have 2 tmu writes.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13527>
OpenGL 3.0 requires the driver can draw to 8 simultaneous render
targets. Similarly, OpenGL ES 3.0 requires the driver can draw to 4
simultaneous render targets. Fix the version computation logic to take
this into account.
On Mali T720, we support ~all features of OpenGL ES 3.1 except we only
support a single render target. Mali T720 should advertise OpenGL 2.1
and OpenGL ES 2.0 only. With the previous logic, it incorrectly
advertised OpenGL ES 3.1.
v2: Lie about the minimum for GL 3.0 to make freedreno a3xx happy. Add
Emma's reviewed-by.
v3: Update the Mali T720 CI expectations. There are tests that pass on
GLES3 but not GLES2. Unclear if these are dEQP bugs or Mesa bugs, lima
hits the same issues. Add them to the known fails
Note to mesa-stable maintainers: this downgrades the OpenGL version
advertised on Mali T720. As such, this patch should apply to the
unreleased 21.3 (Eric) but should NOT be backported to any released Mesa
versions (21.2 or older should NOT have this patch). This is a bit of a
compromise; Emma agreed with this plan on IRC.
Reported-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net> [v2]
Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> [v2]
Cc: 21.3 mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13455>
nir_lower_blend was written against the OpenGL ES 3.2 specification,
which does not support blending SNORM render targets. The ES spec
says that non-floating point buffers get clamped to [0, 1] before
blending. The story is not so simple: SNORM buffers are blendable in
OpenGL and must clamped to [-1, 1] rather than [0, 1]. Handle this case.
NIR does have the fsat_signed_mali instruction to clamp to [-1, 1], but
it is only implemented in Panfrost, and this pass is in common code.
Open code it instead. Panfrost optimizes the open coded version, so this
is good enough.
Fixes SNORM subtests of Piglit arb_texture_view-rendering-formats.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13499>
Some Mali GPUs can avoid storing to the tilebuffer if src alpha = 0, and
can replace blending with a store if src alpha = 1. This saves power in
the common case of alpha blending. Add predicates to check if these
optimizations are valid for a given blend equation.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13508>
Variable workgroup size works by compiling as much SIMD variants as
possible and then selecting the right one during dispatch (when the
actual workgroup size is passed to us).
Instead of replicating the logic in a separate function, reuse the
same logic for regular SIMD selection. And move function for that
together with the remaining simd selection functions.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/13249>
