Setting default expected values as default in the xml.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21105>
Currently, we postpone binning syncs until we record draw calls
and can validate if any of them require accessing protected
resources in the binning stage, however, if the draw calls are
recorded in a secondary command buffer and the barriers have
been recorded in the primary command buffer, we won't apply the
binning sync in the secondary when we record the draw calls
and so we must apply it when we execute the secondary in the
primary.
Fixes flakyness in:
dEQP-VK.api.command_buffers.record_many_draws_secondary_2
cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21162>
The CLE parser in the sim will read this many bytes for each instruction
in a CL, so we should ensure we have at least that many bytes available
in the BO when reading the last instruction, otherwise we can trigger
a GMP violation. It is not clear whether this behavior applies to real
hardware too.
cc: mesa-stable
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21162>
These are ignored by the pvrsrvkm KMD and don't exist in the new KMD.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Luigi santivetti <luigi.santivetti@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21132>
Fixes: 46b099e3
("meson: Ignore unused variables in release builds")
46b099e3 has some issues:
- it doesn't enable unused variables warning on release builds
with assertions enabled;
- it doesn't disable unused variables warning on debug builds
with assertions disabled;
- it doesn't disable unused variables warning when building
with MSVC and assertions are disabled regardless of buildtype,
see #8147. 3/4 regressions reported there have this limitation
alone as root cause.
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21154>
On integrated products this makes almost no difference but on discrete
it's pretty important.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Tested-by: Chuansheng Liu <chuansheng.liu@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21131>
navi21 can do separate image support, using tier 2 DPB messages.
This enables support for doing that in the vulkan video driver.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20388>
This adds support for H264 decode on VCN hardware.
It uses the full DPB method, and relies on the application
to allocate an arrayed texture for the DPB to be stored into.
RADV_PERFTEST=video_decode is required to enable this.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20388>
The video buffers need to have objects aligned at certain ranges,
this enhances the uploader to allow an alignment to be specified.
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20388>
The decoder context needs to know what engine it's associated with.
Nowadays, we have render, compute, blitter, even video engines being
used from the same driver. Rather than trying to have a single decoder
and thwacking the engine field back and forth between calls, we make
one per queue family, and stash a pointer in anv_queue for easy access.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21149>
In general we should only call it once, and then we should avoid to
call any lowering that introduce back copies. So far we were tracking
that manually out of the nir shader on several places.
Ideally we would like to add a nir_validate rule, but right now there
are some exceptions to this rule. For example right now the Intel
compiler calls nir_lower_io_to_temporaries as part of linking
tess_ctrl/mesh/task sahders.
One option would be to allow drivers to reset the value, but for now
let's not add that validation rule.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19338>
LLVMContextSetOpaquePointers() was a temporary workaround offered to
allow transitioning to opaque pointers. Mesa is ready for this now with
recent versions of LLVM (16+). Therefore we limit the workaround of
using LLVMContextSetOpaquePointers() to LLVM 15 now, that this C
interface was removed in LLVM 17.
Reference: 1270879376
Suggested-by: Dave Airlie <airlied@redhat.com>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8183
Reviewed-by: Roland Scheidegger <sroland@vmware.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21124>
This will be useful for RADV since it hashes the state.
v3dv changes:
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20731>
Some jobs failed during the re-enablement of Collabora's LAVA farm.
The trace job radeonsi-stoney-traces:amd64 produced some traces with
almost unnoticeable lighting spread difference, so I updated all the
traces.
Now the test spec@ext_texture_lod_bias@lodbias is failing after running
a couple of times.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20903>
described as "32 Execution Unit (EU) Super SKU" in:
Intel Atom x6000E Series, and Intel Pentium and Celeron N and
J Series Processors for IoT Applications
Datasheet, Volume 1
Document Number: 636112-1.6
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21129>
according to spec, the maximum number of acquired images can be calculated with
swapchain_size - VkSurfaceCapabilitiesKHR::minImageCount + 1
the previous calculation was both wrong and occurring in the wrong place,
so this corrects both issues
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21095>
GL Spec says that imageLoad from incomplete images must return 0.
This is not really spec compliant as for proper behavior nullDescriptor
and robustImageAccess2 is needed.
A workaround for lack of either of these requires a shader variant.
Clearing the null surface and hoping the app doesn't write to the image
is closer to spec, while avoiding a shader recompile.
KHR-GL46.shader_image_load_store.incomplete_textures tests this.
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21135>
simple way to reproduce this is to run these 4 together:
KHR-GL46.gpu_shader5.images_array_indexing
KHR-GL46.shader_image_load_store.advanced-allMips
KHR-GL46.shader_image_load_store.advanced-sso-simple
KHR-GL46.shader_image_load_store.incomplete_textures
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21134>
Eric Engestrom
José Roberto de Souza
Rhys Perry
Mike Blumenkrantz
Iago Toral Quiroga
Frank Binns
pal1000
Qiang Yu
Lionel Landwerlin
Dave Airlie
Rob Clark
Kenneth Graunke
Alejandro Piñeiro
Yuxuan Shui
Pavel Ondračka
Kai Wasserbäch
Konstantin Seurer
Guilherme Gallo
Jonathan Gray
SoroushIMG
Samuel Pitoiset