Back in the bad old days (vec4?) we had a bunch of smarts in the backend
to dead code eliminate unused vector components and re-pack regular
uniforms, so we really couldn't decide how much data we were pushing
until very late in the backend. Nowadays we have none of that - we do
all of our elimination and packing in NIR. anv shrinks ranges to deal
with Vulkan API push constants, and iris treats everything as a UBO and
as of the previous commit will also shrink appropriately.
So we don't need to do this anymore...which will let us simplify quite
a bit of code.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
anv already does this limiting, since it needs to handle non-UBO push
constants as well. iris treats everything as a UBO, but doesn't have
a limiter and was relying on the backend to handle it.
Do this in the NIR pass so that we can eliminate the backend code.
It's not necessary for anv, but handling it here is simple and less
error prone for iris, which calls this in a number of places. We know
we need to limit things to this much; anv can limit more if needed.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
The value of the PIPE_SHADER_CAP_MAX_CONST_BUFFERS parameter should be
less than PIPE_MAX_CONSTANT_BUFFERS, otherwise, it will lead to some
assert failures. For example:
void
cso_unbind_context(struct cso_context *cso)
{
...
int maxsam = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_TEXTURE_SAMPLERS);
int maxview = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SAMPLER_VIEWS);
int maxssbo = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SHADER_BUFFERS);
int maxcb = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_CONST_BUFFERS);
int maximg = scr->get_shader_param(scr, sh,
PIPE_SHADER_CAP_MAX_SHADER_IMAGES);
assert(maxsam <= PIPE_MAX_SAMPLERS);
assert(maxview <= PIPE_MAX_SHADER_SAMPLER_VIEWS);
assert(maxssbo <= PIPE_MAX_SHADER_BUFFERS);
assert(maxcb <= PIPE_MAX_CONSTANT_BUFFERS); // Crash here
assert(maximg <= PIPE_MAX_SHADER_IMAGES);
...
}
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32889>
Now that ACO has become the default on pre-RDNA GPUs, all pre-merge CI
coverage of radeonsi+LLVM has disapeared. Let's fix this by making
our post-merge glcts-vangogh-valve job run inpre-merge pipelines.
However, we are limited in vangogh capacity, so rather than running the
full glcts/piglit test suites we run a fraction of it to stay under 15
minutes of execution time on a single Steam Deck.
Suggested-by: Marek Olšák <maraeo@gmail.com>
Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32865>
It's not entirely clear to me why this has moved from Crash/Fail to
Pass, the only thing I can see in the commit history between the last
nightly pass and failure is an optimization of unpacing 8-bit values
from a 64-bit value. It's a bit suspicious that an optimization makes
somethign pass...
But we need to have correct CI expectations, otherwise we won't notice
new failures. So let's update to the new reality, and debug this if the
problem reappears in the future.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32833>
Looks like this changed when IO-lowering was changed in the GLSL
linker, but because the traces job here runs post-merge, it wasn't
noticed at the time.
There's only a single pixel that has changed, from a very dark color to
another very dark color. Neigher the before nor after images looks
obviously more correct than the other.
Fixes: 73d675451b ("ci: update fail lists and trace checksums")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32833>
In OpenGL, non-multisample targets always have full coverage, and shader
writes to gl_SampleMask are ignored. On Vulkan, sample mask writes on
single-sample targets are treated the same way as writes with >1 sample.
Fixes dEQP-VK.pipeline.*.multisample_shader_builtin.write_sample_mask.1_samples
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32636>
Fix defect reported by Coverity Scan.
Arguments in wrong order (SWAPPED_ARGUMENTS)
swapped_arguments: The positions of arguments in the call to
hk_ia_update do not match the ordering of the parameters:stat_c_inv is
passed to c_prims.stat_c_prims is passed to c_inv.
Fixes: a3b796ba19 ("libagx,hk: handle pipeline stats queries without a GS")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32853>
The Vulkan spec says:
"The application can enable a logical operation between the
fragment’s color values and the existing value in the framebuffer
attachment. This logical operation is applied prior to updating
the framebuffer attachment. Logical operations are applied only
for signed and unsigned integer and normalized integer
framebuffers. Logical operations are not applied to floating-point
or sRGB format color attachments."
Missing VKCTS coverage has been reported.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12345
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32826>
