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>
This uses the vk-meta framework, so it feels more like it belongs here.
While we're at it, rename the function as well.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39304>
Since the move to MEMORY_*_LOGICAL the result value was being ignored, so
change to use that.
Since the conversion to use new registers, some issues were introduced:
- Even with `has_64bit_int` ADD with 64-bit immediate value is not supported;
- `dst_high` was not being filled if there was no overflow;
- Only `dst_low` returned.
Found when writing some new code involving large block loads.
Fixes: b79e85a93f ("brw: always use new registers for load address increments")
Fixes: b55f77161d ("intel/brw: Switch to emitting MEMORY_*_LOGICAL opcodes")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39282>
This catches a number of bugs in the current NIR algebraic optimizations
or opcodes implementations (as fixed in this series, or documented in the
XFAIL tests), and should prevent many future bugs from landing.
This required bumping the test timeout, because s390x is very slow to
emulate in CI.
Closes: #3338
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39076>
This way as a pattern author/editor you can immediately see whether it's
getting test coverage and if there are known issues with the pattern.
This will also give us clear outcomes from testing as we fix failing
patterns.
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39076>
nir_algebraic_pattern_test can validate shaders with the following
structure:
%0 = @provide(base = 0)
...
%N = @provide(base = input_count)
// multiple equivalent expressions
a = ...
b = ...
valid = ieq(a, b)
@use(valid)
Expressions are evaluated by emulating the shader using
nir_eval_const_opcode.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39076>
Same trick we do for nir_imul evaluation -- do the multiply in unsigned to
get defined behavior from C. Fixes UBSan failures with
nir_opt_algebraic_pattern_tests.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39076>
We all know that (int)0xff << 24 is fine, but UBSan doesn't like it.
These were triggered by nir_opt_algebraic_pattern_tests.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39076>
These opcodes are generated inside NIR algebraic when the shift is
constant, but this will help us do automated algebraic pattern testing
with arbitrary inputs that are unaware of the opcode's restrictions.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39076>
This is unused by any callers currently, but will be useful for nir
algebraic pattern testing, and as a way to turn our comments in
nir_opcodes.py into actual C code. For now, always returns false.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39076>
We know what's at the four bits starting at 11:0; that's the uniform
count. But we don't know whats at 12:0, so let's update the start
address here.
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38493>
When calculating the relative offset for a branch the pco_first_igrp
function is used to find the first instruction of a block.
However if the block is empty the function does not return NULL as it
description implies but returns a pointer to the list head which is not a
valid node. Using this leads to a garbage relative offset been calculated
which leads to unexpected behaviour.
Fix is to add a check for the list been empty and return NULL (the same
issue also exists in pco_last_igrp). This leads to the calling function,
pco_cf_node_offset, searching for the next none empty block which is the
expected behaviour.
Fix deqp:
dEQP-VK.graphicsfuzz.cov-two-nested-loops-switch-case-matrix-array-increment
dEQP-VK.graphicsfuzz.stable-binarysearch-tree-false-if-discard-loop
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/39287>
The previous approach does ensure that all entries are zero'd, but that
may not be clear to the reader (i.e., me). Using `{ 0 }` is clearer.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/39245>
