Without this libva won't be able to find the driver without
LIBVA_DRIVER_NAME trickery, because the driver has a generic name.
But in the DRI case, even LIBVA_DRIVER_NAME won't do, because the driver
name needs to end with "_drv_video.so", which it doesn't.
So let's instead set up symlinks in the build-dir, like DRIL does.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40136>
We're setting this in the non-DRI codepath, but this was missed when we
started embedding the VA driver into libgallium. This means we no longer
were able to use VA-API from meson devenv, like we could before.
Fixes: 212d57f7e6 ("targets/va: Build va driver into libgallium when building with dri")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40136>
This change is useful when the compute shader is called multiple
times with the atomic operations enabled. It fixes some data
coherency issues. This is done by moving
evergreen_emit_atomic_buffer_setup() after r600_flush_emit().
This change is also a partial fix for compute_shader.pipeline-compute-chain.
In this specific case, it makes the memory barrier working.
This change was tested on cayman and barts; it makes these tests
fully deterministic:
khr-gl4[2-6]/shader_atomic_counters/advanced-usage-many-dispatches: fail pass
khr-gles31/core/shader_atomic_counters/advanced-usage-many-dispatches: fail pass
deqp-gles31/functional/synchronization/inter_call/without_memory_barrier/atomic_counter_dispatch_.*_calls_.*_invocations: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40037>
The alpha instruction always wrote to the same rendertarget as the rgb and the
original target was ignored (surprisingly the HW docs explicitly allows rgb and
alpha to write to different targets). This makes tesseract rendering a bit
better, but there are still some remaining issues.
Fixes: 1c2c4ddbd1 ("r300g: copy the compiler from r300c")
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40128>
When building with "-Dvideo-codecs=h264dec,h265dec,av1dec" va/encode.c
won't be built but it's still required because it's used from
picture.c
Fixes: c4f05bdf60 ("frontends/va: include picture_*.c based on selected codec")
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39482>
On GPUs with ETNA_FEATURE_S8, the hardware supports native 8bpp
stencil buffers. The blob driver samples these as R8I (8-bit integer).
This enables the stencil blit fallback to work with pure S8_UINT
stencil buffers, fixing
dEQP-GLES3.functional.fbo.blit.depth_stencil.stencil_index8_scale
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39936>
Previously, stencil-only blits were silently skipped with "cannot blit
stencil, skipping" because neither the BLT nor RS engines can
selectively copy individual channels from packed depth/stencil formats.
On HALTI5+ GPUs that support stencil texturing (S8X24_UINT), use
util_blitter_stencil_fallback() to perform a shader-based stencil blit.
This clears the destination stencil to zero, then copies each stencil
bit individually using draw calls with per-bit DSA write masks.
Fixes dEQP-GLES3.functional.fbo.blit.depth_stencil.depth24_stencil8_stencil_only
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39936>
After a BLT blit invalidates the destination's tile status,
ETNA_DIRTY_DERIVE_TS was not set, so etna_update_ts_config() would not
run before the next draw. This caused TS_MEM_CONFIG to retain stale
DEPTH_FAST_CLEAR/DEPTH_COMPRESSION bits from the previous draw, even
though the destination depth data was overwritten by the blit.
This fixes depth/stencil blit tests like
dEQP-GLES3.functional.fbo.blit.depth_stencil.depth24_stencil8_basic.
The RS blit path already sets this dirty bit.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39936>
Adds missing FLUSH_CACHE event, and combines the flushing with existing
barrier emit to avoid duplicating flushes.
Fixes some flakeyness seen with UBWC images on gen8.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40144>
Avoid creating a dummy batch in the non-TC (async-flush) path, if we can
re-use last_fence.
This avoids extra flushes with rusticl, which is not using TC.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40144>
When we have a sequence of batches to flush (ie. some batch, and all
it's dependent batches), attach a fence to the last in sequence. This
helps avoid fd_context_flush() from creating an empty batch when it
needs to return a fence, but has nothing else left to flush.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40144>
It would matter more if we used CP_RUN_OPENCL, as CP_EXEC_CS programs
these regs from the pm4 pkt payload. But might as well at least program
correct values.
This at least makes it easier to compare cmdstream to closed cl driver,
which uses CP_RUN_OPENCL.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40144>
Currently pre-a6xx is missing ir3 support for various things that rusticl
requires, leading to segfaults.
For now, block compute-only contexts on older gens.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40144>
The HW line rasterizer on some Vivante GPUs doesn't produce
spec-conformant results for wide lines. Correct emulation via
triangle expansion is complex and interacts poorly with features
like primitive IDs, shader side effects (SSBOs, atomics), and
varying interpolation.
Rather than carrying fragile emulation, limit the advertised
max line width to 1.0 on affected GPUs. The GLES3 spec only
requires support for width 1.0, so this doesn't affect conformance.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Daniel Lang <dalang@gmx.at>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40006>
In 1f83e73145, the pre-encode input picture size was also reduced.
However it was recently discovered that VCN FW uses the input picture
pitch as the pitch for this, which means that previous change broke
pre-encode.
Fixes: 1f83e73145 ("radeonsi/vcn: Reduce allocated size for pre-encode recon pics")
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40125>
These don't really fit in pan_texture anymore, so move them to a
separate pan_buffer-file.
Acked-by: Eric R. Smith <eric.smith@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39294>
Vivante hardware exhibits floating-point interpolation inconsistencies
at the diagonal seam when the blitter uses a two-triangle quad for scaled
NEAREST blits. Enable the single-triangle blitter mode to match the
proprietary driver's approach of using one oversized triangle
clipped by scissor.
Fixes dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_mag_*
Fixes dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_min_*
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39973>
When the blitter draws a textured quad using two triangles, the
interpolation at the diagonal seam between triangles can produce
slightly different texture coordinates for the same pixel position.
For NEAREST filtering this causes inconsistent texel selection at the
seam boundary, failing dEQP-GLES3 nearest_consistency_* tests.
V3D already works around a similar issue by reordering triangle indices
(use_index_buffer), but Vivante GPUs requires a stronger fix: drawing a
single oversized triangle and relying on scissor to clip to the actual
destination rectangle. This matches the approach used by Vivante's
proprietary driver.
Add a new use_single_triangle flag to blitter_context that drivers can
opt-in.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39973>
