We needed to halve the number of tests in `zink-tu-a618` due to the
reduced number of a618-limozeen in Collabora's farm, let's create a job
in the nightly pipeline to keep track of zink tests.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28770>
Recently, `sc7180-trogdor-lazor-limozeen-cbg-2` was retired from the
farm, so we need to rebalance the jobs again. The current flow is
causing the job queue to be huge.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28770>
panfrost_initialize_surface is called when a surface is written to,
and marks that surface as valid. If the surface is a depth buffer
with a separate stencil, that separate stencil should also be marked
as valid; otherwise, readpixel will skip reading it (and hence the
stencil data will be read as uninitialized). This only affects
DEPTH32F_STENCIL8 formats.
Cc: mesa-stable
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28738>
Enable MSAA by default and update CI expectation.
The spec@ext_framebuffer_multisample test is buggy and switches from fail
to skip once we actually expose multisample capabilities, while it should
also have skipped before.
Some of the *copyteximage and spec@!opengl 1.1@depthstencil-default_fb*
tests require multisample resolve blits with parameters that can not be
supported natively with the RS engine and can also not be emulated by
u_blitter without texture multisampling, which is not available in the
GC2000 hardware. Accept those failures on this HW generation.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22439>
We must disable features before we fill our internal etna_specs
struct with etna_get_specs(..).
Fixes: d600b45ccc ("etnaviv: Switch to etna_core APIs")
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28757>
Remove a premature optimization. When PIPE_MAP_DISCARD_WHOLE_RESOURCE
is set we were setting create_new_bo, and then if that was set we skipped
a set of tests which if passed would cause a panfrost_flush_writer.
In fact we need that flush in some cases (e.g. when any batch is
reading the resource). Moreover, we should sometimes copy the resource
(set the copy_resource flag) and that again was being skipped if
create_new_bo was initially true due to PIPE_MAP_DISCARD_WHOLE_RESOURCE
being set.
Cc: mesa-stable
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28406>
X8Z24 surfaces have a don't care stencil channel, which is okay to be
cleared together with the depth channel. Set the depth clear bits
accordingly to allow those clears to use the fast-clear path when
only depth is to be cleared. This change aligns the RS with the BLT
ZS clear path.
Fixes: df63f188e8 ("etnaviv: fix separate depth/stencil clears")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28696>
Currently both TS and non-TS paths use the same place to store the compiled
RS commands to clear the surface. In the TS case the commands only initialize
the TS buffer, while the non-TS commands clear the whole buffer. The
assumption here is that a TS enabled surface will only ever be fast cleared,
which doesn't hold anymore, now that we can fall back to slow clears on TS
enabled depth/stencil buffers.
The fallback to a slow clear will overwrite the stored RS commands with a
full buffer clear. If we can transition to a fast clear later, the commands
to initialize the TS buffer will not be regenerated and a full buffer clear
will be submitted instead. In addition to the performance degradation, it
will also leave TS in an inconsistent state, as the TS buffer will not be
initialized, but the TS state still gets marked as valid.
To avoid this confusion and not introduce any more state tracking to remember
the target of the clear commands and regenerate TS clears if needed, simply
split the storage for compiled TS and non-TS clear commands.
Fixes: df63f188e8 ("etnaviv: fix separate depth/stencil clears")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28696>
Now that we switch dynamically between fast (TS) and slow (regular)
clears on TS enabled surfaces, we must trigger reevaluation of the
current TS state also after a slow clear, as otherwise the PE might
continue to use the invalidated TS state.
Fixes: df63f188e8 ("etnaviv: fix separate depth/stencil clears")
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28696>
With commit f2506780c8 ("mesa/st: Only set seamless for GLES3") ss->seamless_cube_map
should behave as wanted. For GLES2 it can only be set when PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE
is supported.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28669>
mem_access_base_pointer loads memory (the descriptor) and therefore
needs to be guarded. Fixes
dEQP-VK.spirv_assembly.instruction.terminate_invocation.terminate.no_null_pointer_load.
Fixes: fc8a83c ("gallivm/ssbo: mask offset with exec_mask instead of building the 'if'")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28614>
This removes the in-driver feature handling and switches to the one from
common.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28574>
This etna_feature enum will be used as abstraction layer. We will add
support for a hardware database - borrowed from the binary blob.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28574>
I am planning to make use of these headers outside of the gallium
driver.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28574>
Also remove the check for overflowing 16bit TGSI register index.
If that ever happens we are out of luck anyway, no need to waste CPU
cycles on RA...
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28663>
We can use any swizzle to access it, so if the inline constant is in
ADD,try to have the swizzle same as the second channel so that we can
potentially use presubtract later.
RV530:
total instructions in shared programs: 129366 -> 129306 (-0.05%)
instructions in affected programs: 10191 -> 10131 (-0.59%)
helped: 56
HURT: 12
total presub in shared programs: 8421 -> 8791 (4.39%)
presub in affected programs: 1523 -> 1893 (24.29%)
helped: 0
HURT: 102
total temps in shared programs: 17561 -> 17562 (<.01%)
temps in affected programs: 47 -> 48 (2.13%)
helped: 2
HURT: 4
total lits in shared programs: 3021 -> 3179 (5.23%)
lits in affected programs: 427 -> 585 (37.00%)
helped: 0
HURT: 37
total cycles in shared programs: 197845 -> 197512 (-0.17%)
cycles in affected programs: 18949 -> 18616 (-1.76%)
helped: 50
HURT: 19
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28428>
We want to move it after rc_remove_constants because we can't reswizzle
presubtract sources and we need to pack multiple uniforms into vec4
slots to be able to run glamor shaders on R400.
This mostly works OK, the detection logic just needs to recognize the
case when 2.0 was converted to inline constant.
RV530:
total instructions in shared programs: 129384 -> 129366 (-0.01%)
instructions in affected programs: 2078 -> 2060 (-0.87%)
helped: 16
HURT: 7
total presub in shared programs: 8404 -> 8421 (0.20%)
presub in affected programs: 423 -> 440 (4.02%)
helped: 19
HURT: 25
total omod in shared programs: 410 -> 429 (4.63%)
omod in affected programs: 10 -> 29 (190.00%)
helped: 0
HURT: 13
total temps in shared programs: 17560 -> 17561 (<.01%)
temps in affected programs: 34 -> 35 (2.94%)
helped: 3
HURT: 3
total lits in shared programs: 3006 -> 3021 (0.50%)
lits in affected programs: 267 -> 282 (5.62%)
helped: 13
HURT: 20
total cycles in shared programs: 197840 -> 197845 (<.01%)
cycles in affected programs: 4159 -> 4164 (0.12%)
helped: 13
HURT: 13
R420:
total instructions in shared programs: 103810 -> 103762 (-0.05%)
instructions in affected programs: 4176 -> 4128 (-1.15%)
helped: 29
HURT: 1
total presub in shared programs: 2724 -> 2878 (5.65%)
presub in affected programs: 478 -> 632 (32.22%)
helped: 6
HURT: 40
total omod in shared programs: 411 -> 421 (2.43%)
omod in affected programs: 3 -> 13 (333.33%)
helped: 0
HURT: 7
total temps in shared programs: 16841 -> 16852 (0.07%)
temps in affected programs: 814 -> 825 (1.35%)
helped: 5
HURT: 17
total cycles in shared programs: 162397 -> 162361 (-0.02%)
cycles in affected programs: 5746 -> 5710 (-0.63%)
helped: 30
HURT: 3
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28428>
And don't use presubtract in the first place instead of relying on the
dataflow swizzle pass to sort things up later.
Just two shaders in shader-db hits this, but this patch prevents some
regressions in dEQP when we later move presubtract after the dataflow
swizzle pass.
RV420:
presub helped: shaders/chromeos/24.shader_test FS: 6 -> 2 (-66.67%)
presub helped: shaders/chromeos/21.shader_test FS: 6 -> 2 (-66.67%)
cycles helped: shaders/chromeos/24.shader_test FS: 79 -> 78 (-1.27%)
cycles helped: shaders/chromeos/21.shader_test FS: 47 -> 46 (-2.13%)
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28428>
