Making use of the relatively recent FDO_BASE_IMAGE feature of the
templates, the x86_test-base image contents are shared as a separate
layer by the x86_test-gl/vk images (meaning the former only needs to be
downloaded once for either or both of the latter). This should be more
efficient in terms of overall network bandwidth and storage, in
particular if the base image changes less often than the -gl/vk ones.
v2:
* List x86_test-base in needs: along with x86_test-gl/vk (see parent
commit)
* Always put $STABLE/TESTING_EPHEMERAL on separate lines, will make it
easier to add any non-ephemeral packages
Reviewed-by: Eric Anholt <eric@anholt.net> # v1
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5186>
The CS compiler now produces multiple SIMD variants, so the previous
trade-off between "always using SIMD32" and "having a smaller max
invocations" is now gone.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5142>
This was used to decide which SIMD width to generate code for
ARB_compute_variable_group_size. Now that compiler will generate
multiple SIMD widths, this information is unused.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5142>
This will make the GL drivers pick the right SIMD variant for a given
group size set during dispatch. The heuristic implemented in
brw_cs_simd_size_for_group_size() is the same as in brw_compile_cs().
The cs_prog_data::simd_size field was removed. The generated SIMD
sizes are marked in a bitmask, which is already used via
brw_cs_simd_size_for_group_size() by the drivers.
When in variable group size, it is OK if larger SIMD shader spill,
since we'd need it for the cases where the smaller one can't hold all
the invocations.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5142>
There's an update for INTERFACE_DESCRIPTOR_DATA at dispatch, so we can
just move the KSP assignment there. This flexibility will later allow
variable group size to pick the right SIMD variant.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5142>
Move the decision one level up, let brw_compile_*() functions use the
spilling information to decide whether or not a certain width
compilation can spill (passed via run_*() functions).
The min_dispatch_width was used to compare with the dispatch_width and
decide whether "a previous shader is already available, so don't
accept spill".
This is replaced by:
- Not calling run_*() functions if it is know beforehand a smaller width
already spilled -- since the larger width will spill and fail;
- Explicitly passing whether or not a shader is allowed to spill. For
the cases where the smaller width is available and haven't spilled,
the larger width will be compiled but is only useful if it won't
spill.
Moving the decision to this level will be useful later for variable
group size, which is a case where we want all the widths to be allowed
to spill.
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5142>
integer and float compare ops cannot take boolean types, so the bit size
of the inputs should be checked here so that we can swap to the logical
equality functions if we're being passed a bool value
resolves tons of validator errors in glsl piglit tests
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5231>
After the recent optimizations in ppir lowering that increase options
for combining, node_to_instr now may have multiple options of nodes to
insert and needs to decide which is better.
For example, if an instruction uses both a varying and a texture, there
are two nodes nodes that can be inserted to the load varying slot in the
same instruction (ld_var and ld_coords). It is much more advantageous to
pipeline the load texture coords since that enables the higher precision
path for texture coordinates. However, with the current recursive
expansion, this cannot be influenced.
This simple ready list implementation in node_to_instr allows it to
choose the next node to expand based on a priority score, rather than
relying on the random order coming from the recursive expansion.
Other than preferring nodes with pipeline output (which covers ld_coords
vs ld_var), nodes using later slots in the pipeline are now expanded
first, allowing node_to_instr to make all of the earlier (pipelineable)
nodes available in the ready list so the best one can be chosen when
picking nodes for the earlier slots.
Fixes: 632a921bd0 lima/ppir: optimize tex loads with single successor
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5092>
We don't force w=1 for Bifrost textures. We already compose this into
the swizzle as necessary, so we can just ignore this field I think. But
let's identify it so we don't forget what it is.
The blob uses it to force w=1 for <= 3-channel formats (0x10), as well
as a flag to swap r/b for BGRA (0x4). There are probably other flags
here but it doesn't.. really matter to us.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5232>
The cu bitmap in amd gpu info structure is
4x4 size array, and it's usually suitable for Vega
ASICs which has 4*2 SE/SH layout.
But for Arcturus, SE/SH layout is changed to 8*1.
To mostly reduce the impact, we make it compatible
with current bitmap array as below:
SE4,SH0 --> cu_bitmap[0][1]
SE5,SH0 --> cu_bitmap[1][1]
SE6,SH0 --> cu_bitmap[2][1]
SE7,SH0 --> cu_bitmap[3][1]
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5212>
It was found that dual-source blending hangs with SIMD16 dispatch in some
specific but unknown situation. Which in the wild happen when rgba
anti-aliasing is enabled for fonts.
Cc: <mesa-stable@lists.freedesktop.org>
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2183
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5037>
This avoids a validator warning when for instance generating mipmaps.
Fixes: d2bb63c8d4 ("zink: Use optimal layout instead of general. Reduces valid layer warnings. Fixes RADV image noise.")
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5199>
This will be used to import images which have different layout from what
turnip uses by default. For example non-UBWC (linear) images from the video
decoder on some hardware have a 512 pitch alignment.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4596>
Currently the nir linker resizes the amount of storage needed to hold
uniform information on the fly while linking. As shaders can contain
thousands of uniforms this can be very slow. For example some Godot
shaders can take 30 seconds to compile on some machines.
In this change we count the amount of storage needed before we start
processing the uniforms. This is what the GLSL IR linker does also.
Fixes: 95f555a93a ("st/glsl_to_nir: make use of nir linker for linking uniforms")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2996
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5137>
Generally we do not completely stop compilation as soon as we see an error,
instead we continue on to attemp to find any futher errors.
This means we shouldn't be checking state->error to see if any error has
happened during the compilation process, doing so was causing
process_parameters() to fail on completely valid functions if there was
any error found in the shader previously. This then caused the valid
functions not to be found because the paramlist was considered empty,
resulting in the compiler spewing out misleading error messages.
Here we simply add the IR error value to the param list when we have
an issue with processing a parameter, this leads to much better error
messaging.
Fixes: 53e4159eaa ("glsl: stop processing function parameters if error happened")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5205>