The only difference was that these rules incorrectly added a second
-fluster suffix to the expectation files after a refactoring.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39015>
This version notably also brings in vkd3d-proton support.
Also remove the redundant DEBIAN_TEST_ANDROID_TAG mention.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39015>
This fixes situations where the variable being split is a parallelcopy
definition.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38811>
For example, v6b at byte=2 should be split into v2b,v1 instead of v1,v2b.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38811>
get_regs_for_copies() might change tmp_file, so we need to create a new
one.
Recursively handle_call() with an modified register_file instead of
repeating get_regs_for_copies().
This also updates register_file for the caller.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38811>
collect_vars_from_bitset() from the caller should have already cleared
these.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38811>
For large constants inlined into phis, this would overread the remap[] array,
which could crash. No CTS tests affected though.
Christoph found the bug and fixed it for Bifrost over in
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39305. I just did a
quick CTS run of the obvious AGX backport over this morning's breakfast.
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reported-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39313>
Allows a shader to have multiple ray queries without spilling them to a shadow
stack. Instead, the driver provides the shader with an array of multiple
RTDispatchGlobals structs to give each query its own dedicated stack.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38778>
If two devices/instances are created, the VMID reservation will just
fail. It seems fine as long as it's reserved before SPM is used.
Fixes: a7a4abc8d8 ("radv: Move VMID reservation to vkCreateDevice")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39311>
Fixing subgroups will be a considerable time sink, so for now just disable
this optional feature until we have time to investigate and fix everything.
Signed-off-by: Aitor Camacho <aitor@lunarg.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39337>
The offset for the dynamic buffers needs to be computed with the currently
bound pipeline layout. This change fixes incorrectly selecting the offset
for a dynamic buffer if a descriptor with a lower index than the currently
being bound contains a dynamic buffer but said descriptor hasn't being
bound yet. It also prevents the binding to override the dynamic buffers in
order to preserve the already bound dynamic descriptors.
Signed-off-by: Aitor Camacho <aitor@lunarg.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39337>
We're making blorp use OpenCL shaders, and both crocus and hasvk
require blorp, so now they require CL.
Without this patch, when we build Vulkan with intel_hasvk or crocus
but not the other things that require CL, we get:
src/intel/blorp/meson.build:12:4: ERROR: Unknown variable "prog_mesa_clc".
Thanks to the report from Dancing Mirrors.
Fixes: b52b1a08bf ("intel/blorp: add blorp_shaders.cl")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/14660
Reviewed-by: Dylan Baker <dylan.c.baker@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39333>
We already mark all fragment shaders as always using blend constants so
this is handled by the existing code and our setting of push.count.
Also, this hack is wrong as it pushes way too much and might overflow
memory. Also, it will overflow the HW limit of 64 as soon as we
increase the size of panvk_graphics_sysvals.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39274>
Otherwise, we'll only mark the first location for matrix and array
variables. Ideally, someone would split these before we get here but we
should at least be correct.
Cc: mesa-stable
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39274>
Outputs may be re-mapped by VK_KHR_dynamic_rendering_local_read, in
which case outputs_written won't actually correspond to render targets.
Fortunately, we already have rt_written, which is properly remapped.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39274>
I'm not sure if this is the best way to enforce this as it's really a
restriction on the blend array pointer. Individual blend descriptors
only have to be 16B-aligned. But this seems to work and doesn't affect
the array stride, which is still 16B.
Also, I couldn't actually find the restriction in the v10 docs but it's
there on v11 and this is enough of a pain to debug that we're probably
better off playing it safe.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39274>
This is what the JM code is doing and it lets us assume we always have a
fragment shader. Right now, we're already making that assumption, we
just haven't been bitten by it yet because no one has tried to use a
shader-requiring blend configuration with no FS yet.
Cc: mesa-stable
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39274>
On Bifrost, we have to return the blend return offset in the compiled
shader info and that means we need to be able to index into an array by
blend target deep inside the compiler. Instead of assuming bound blend
targets and subtracting BIR_FAU_BLEND_0 from fau_idx, add a separte
blend_target to bi_instr and use that. This way what we return will be
based on the nir_io_semantics::location, regardless of where the actual
blend descriptor comes from.
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39274>
When doing sample comparisons on shadow images the compare value
should be clamped to [0,1]
Fix:
dEQP-VK.glsl.texture_functions.texture.samplercubearrayshadow_fragment
Signed-off-by: Nick Hamilton <nick.hamilton@imgtec.com>
Reviewed-by: Simon Perretta <simon.perretta@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39327>
