This is based on the example given by the Vulkan specification: https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#textures-texel-anisotropic-filtering
The basic idea is to compute the axis in which the uv coordinates
change the fastest in screen space (rho_y and rho_y). If rho_x is larger
than rho_y, samples are summed up along the x-Axis and the y-Axis
viceversa. The x/y offsets are mapped back into texture (u/v) space
using a linear approximation of u(x,y) and v(x,y).
This approach does not use a nested loop and the number of samples is
basically limited to max_anisotropy (+/-). The sample count of the
previous approach could explode in some situations, leading to
frametimes >1s.
Reviewed-by: Aleksi Sapon <aleksi.sapon@autodesk.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31748>
Currently the list of buffer usage bits specified is hardcoded with
transform feedback bits, which leads to a validation layer error report
with ID VUID-VkBufferCreateInfo-None-09499 when EXT_transform_feedback
is not available.
Only set these bits when EXT_transform_feedback extension is really
available to suppress this error.
Cc: mesa-stable
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32386>
One new rv410 flake and one new rv530 fail which I can't reproduce
locally. Also remove the vs-varying-array-mat3* flakes, those were
failing because we run out of varyings, however this should no longer be
an issue since nir_opt_varyings was enabled for everyone.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32897>
The push_constant_loc[] array is always an identity mapping these days,
so it's kind of pointless. Just use the original uniform number and
skip the unnecessary "remap" step. With that gone, and shrinking UBO
ranges gone, assign_constant_locations() is now empty and can be removed
as well.
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32841>
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>
