This is similar to what link_intrastage_shaders is doing and it
fixes the following test:
KHR-Single-GL46.subgroups.builtin_var.compute.subgroupsize_compute
Which was failing with SPIRV but passing with GLSL, the diff being:
- SPIRV: "subgroup_size: 1"
- GLSL: "subgroup_size: 2"
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32698>
The blitter VS expects coords to fit in a signed int16. When this
is not the case, use util_blitter_draw_rectangle instead.
Since util_blitter_draw_rectangle sets vertex elements, we need
to make sure they're properly restored.
The alternative to this fallback would be to pass coordinates
unpacked (so 4 SGPRs instead of 2), but this doesn't fix the
fbo-blit-check-limits test because of uv interpolation precision
issue.
Using 2 triangles instead of a rectangle + disabling
window_space_position helps but then this breaks some GLES3 tests,
like dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_mag_reverse_src_x
(which doesn't pass either if u_blitter is used for all cases).
Using a single triangle covering the whole rectangles fixes all
cases but it then requires to setup scissors to not write too
much pixels...
So, instead of adding so much complexity, let's use u_blitter
for the "large coordinates" fallback, and keep the rectangle blit
for the other cases.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32698>
This is actually a false positive detected by static analyzer, because
it assumes that `device->instance->meta_cache_enabled` can change
between two execution points.
In order to instruct static analyzer this is not the case, we assing it
to a local variable, and do the checks based on that.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32819>
Declaring a variable-length array (VLA) based on a variable that can be
0 is declared dangerous.
In this case, the variable can't take value 0, so adding an assertion
fixes the issue.
This was detected by static analyzer.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32819>
We're about to add more sysvals, and the more we add, the bigger the
sysvals region gets, which increases the amount of memory we have to
allocate when push_uniforms are dirty.
Instead of allocating FAUs for all sysvals/push_constants, track FAU
usage per-shader, and pack those. This implies emitting an FAU buffer
per stage instead of trying to share it, but that's an acceptable
trade-off.
While at it, automate the sysval dirty tracking a bit.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
Now that panvk_cmd_buffer.h is accessible from
src/panfrost/vulkan/panvk_vX_xxx.c files, there's no reason to pass
a gazillon arguments to blend_emit_descs(). We can just pass a cmdbuf
and let the helper extract the other parameters from there. It also
allows for extra automation, like dirtying the push_uniform buffer
when the new blend config reads the blend constant.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
load_vertex_id_zero_base() is supposed to return the zero-based
vertex ID, which is then offset by load_first_vertex() to get
an absolute vertex ID. At the same time, when we're in a Vulkan
environment, load_first_vertex() also encodes the vertexOffset
passed to the indexed draw.
Midgard/Bifrost have a sligtly different semantics, where
load_first_vertex() returns vertexOffset + minVertexIdInIndexRange,
and load_vertex_id_zero_base() returns an ID that needs to be offset
by this vertexOffset + minVertexIdInIndexRange to get the absolute
vertex ID. Everything works fine as long as all the load_first_vertex()
and load_vertex_id_zero_base() calls are coming from the
load_vertex_id() lowering. But as mentioned above, that's no longer
the case in Vulkan, where gl_BaseVertexARB will be turned into
load_first_vertex() and expect a value of vertexOffset in an
indexed draw context.
We thus need to fix the mismatch by introducing two new
panfrost-specific intrinsic so we can stop abusing load_first_vertex()
and load_vertex_id_zero_base().
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
The csel-ladder we have in bi_lower_load_push_const_with_dyn_offset()
is not great, and is relying on base/range being valid. It turns out
nir_lower_mem_access_bit_sizes(), which we rely on to make push constant
accesses 32-bit aligned, doesn't preserve those when splitting accesses.
Let's simplify the thing by lowering push constant accesses with a
dynamic offset to global loads.
We also reset the base and offset values in the lowering pass, to make
sure the backend doesn't rely on them for other things.
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Reviewed-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32415>
This is required to optimize FP64 and Int64 shaders generated by
virglrenderer. It generates pack/unpack around every 64-bit op,
which NIR currently can't eliminate. This fixes that.
There is a new constraint ".y", which means that the use of an instruction
should have swizzle.y. This allows us to add patterns that have Y swizzle
on results of instructions.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32172>
