Turns out that respecting the order of parameters is important.
Reported-by: Michael Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Fixes: 5425968d2e ("anv: Implement VK_EXT_custom_border_color")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6175>
This field enables MSAA, either writing samples to separate surfaces, to
a single large-bpp surface, or implicitly resolved and to a single
surface.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6161>
RADV_PERFTEST=aco no longer exists, ACO is the default compiler.
RADV_PERFTEST=llvm is deprecated, use RADV_DEBUG=llvm instead.
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/5662>
This patch fixes the case where less number of reference surfaces created and destoyed
on need basis. The problem comes when we are refereing old assoiciated data for newly
created target buffer with same address. Here old target buffer destroyed as that
surface is no more used as reference for next frames and when we create a new surface
for the next frame to process we will get the surfaceid and same target address
of destroyed surface.
When new surface/surface->buffer/target ,target->codec is null as we cleared when we
destroy this surface, but per ref_mapping logic, it was taking null associated data
i.e.0 as curr_ref_idx. Hence total reference mapping table goes wrong with wrong data.
Beacuse of this, we have seen corrupted vp9 decoded frames.
Signed-off-by: SureshGuttula <suresh.guttula@amd.corp-partner.google.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5452>
Incorrect implementation has been found during code surfing.
v3d implementation used for reference.
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Reviewed-by: Icenowy Zheng <icenowy@aosc.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6076>
This was meant to handle incoherent accesses by always flushing them,
but it accidentally checked for the coherent variant instead. As a
result e.g. a vkCmdClearImage() followed by a renderpass using the image
didn't get any flushes, resulting in the same sort of corruption seen
with sysmem renderpass clears. This happened to be exposed via some
tests that used multiview.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6009>
Baremetal jobs filter the variables they get from .gitlab-ci.yml, and
TRACIE_UPLOAD_TO_MINIO and others weren't being let through.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Fixes: d4ca45eca2 ("ci: Upload traces' reference and actual images to MinIO")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6171>
Some changes unintendedly slipped into an unrelated commit before it was
merged.
This caused kernel modules to be built and installed in the ramdisk,
which caused some devices to fail to boot due to the ramdisk size limit
being surpassed.
These changes weren't in effect until a subsequent commit triggered a
rebuild of the ramdisks.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Fixes: a9560939e0 ("ci: Build-test Panfrost tools")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6167>
Now that we have MinIO, we can distribute traces better than by direct
downloads from git.
With a caching MinIO instance local to the DUT, total run times should
be noticeably impacted.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6136>
The OpenGL flavor of SPIR-V allows for samplers inside structs. This
means that our simple array-of-array handling isn't sufficient and we
need something substantially more complex for generating NIR types.
Fixes: 14a12b771d "spirv: Rework our handling of images and samplers"
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6065>
Example:
../src/freedreno/ir2/instr-a2xx.h:384:1: note: offset of packed bit-field
‘const_index’ has changed in GCC 4.4
384 | } instr_fetch_vtx_t;
It's apparently due to bitfields that would cross the width of their type.
Just expand the types of the affected fields so that the compiler quiets
down.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6165>
2D path is using the same hardware as the 3D path, with the advantage of
separate register state, but here it requires WFI and extra cache flushing
and invalidating, so it should be better to just use the 3D path. There are
also some cases where the 3D path would be much faster, since it can clear
multiple attachments at once.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5775>
It was clearing the flush bits, which are used by both GMEM/SYSMEM paths,
but emitting the flushes inside the cond_exec, where they would only run
for the sysmem path.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5775>
One day, we may want copy_prop_vars or other passes to be able to see
through certain types of casts such as when someone casts a uint64_t to
a uvec2. However, for now we should just avoid casts all together.
Fixes: d8e3edb784 "nir/deref: Support casts and ptr_as_array in..."
Tested-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6072>
The old pass only handled intrinsic load_constant, while the new
nir_opt_shrink_vectors handles ALU ops, nir load_consts, along with all
the load intrinsics.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6050>
This should do much more trimming than shrink_load, and is a win on i965's
vec4 and nir-to-tgsi. For scalar backends like this that don't need ALU
shrinking, it still gets more load intrinsics covered.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6050>
This manages to make some extra vec operations that would turn into movs
go away.
brw shader-db:
total instructions in shared programs: 3895037 -> 3893221 (-0.05%)
total cycles in shared programs: 113832759 -> 113792154 (-0.04%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6050>
Ideally we'd also handle unused middles of vectors and reswizzle ALU-only
uses of it so we could write fewer channels, but that's future work/
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6050>
A630 doesn't have the HW format we use to sample stencil, so it needs a
workaround. It also has a bug around the AS_R8G8B8A8 format, which doesn't
work when UBWC is disabled, so use 8_8_8_8_UNORM instead when UBWC is
disabled (using AS_R8G8B8A8 or 8_8_8_8_UNORM should only matter with UBWC)
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5438>
Fixes the following validation problem:
error: nir_intrinsic_align_offset(instr) < nir_intrinsic_align_mul(instr)
Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: Lukas F. Hartmann <lukas@mntmn.com>
Acked-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6127>
This is mainly for the benefit of automated syncing of changes from mesa
back to envytools, where the same subdir meson.build's are used, but the
toplevel meson.build is different. In the envytools case, we want these
depenendencies to be required.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6154>
The decode tools aren't too useful to install without the xml. But
since libxml2 can read compressed xml, we'll gzip them for installation.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6154>
Instead of building the adreno/foo.xml headers from the toplevel, split
out a subdir(). This fits better with how meson likes things to be
structured. But it does require fixing a bit about how gen_header.py
resolves imports, ie. it cannot assume the src file is at the root of
the $RNN_PATH.
This is needed for the next patch, to add support for installing the
register database for use with installed tools.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6154>
Testing headergen2 will create .xml.h in the same location as the .xml.
But we don't want this to get accidentially committed.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6154>
No need for rnn_path.h, just construct the whole thing in meson and pass
via c_args. Also move where the path is constructed up one level. This
will be needed for syncing back to envytools, where the path will be
different.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6154>
libxml2 can load gzip compressed files, so lets look for these too.
This will be useful for installing the register database so that an
installed cffdump/crashdec can use them. But it isn't too useful
to be able to edit the installed register database, so we can gzip
them to use less disk space.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6154>