The exit condition was not correct causing the pv emulation lowering
pass to emit garbage for incomplete primitives.
Fixes: 5a4083349f ("zink: add provoking vertex mode lowering")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22599>
Previously, whenever a vertex was emitted immediately after emitting a
primitive, that vertex would not use the attributes that where assigned
last because the position variable got set.
Now the temporary attributes array is treated as a ring buffer and
whenever the position is set to 0 it's previous value is used as an
offset when accessing it. This way when a new primitive is created the
attributes at index 0 correspond to the last attributes written.
Fixes: 5a4083349f ("zink: add provoking vertex mode lowering")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22599>
The provoking vertex mode pass was calculating an offset and then using
it directly instead of adding it to the base index.
Fixes: 5a4083349f ("zink: add provoking vertex mode lowering")
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22599>
otherwise the pool is freed before the query and zink will
give the vulkan driver NULL query pool which can make it crash.
this was seen when running the following cases with
primitivesGeneratedQueryWithRasterizerDiscard and color write
features disabled:
dEQP-GL45.functional.tessellation.invariance.outer_triangle_set.triangles_fractional_odd_spacing
dEQP-GL45.functional.tessellation.invariance.outer_triangle_set.triangles_fractional_even_spacing
dEQP-GL45.functional.tessellation.invariance.outer_triangle_set.quads_equal_spacing
dEQP-GL45.functional.tessellation.invariance.outer_triangle_set.quads_fractional_odd_spacing
dEQP-GL45.functional.tessellation.invariance.outer_triangle_set.quads_fractional_even_spacing
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_equal_spacing_ccw
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_equal_spacing_ccw_point_mode
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_equal_spacing_cw
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_equal_spacing_cw_point_mode
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_odd_spacing_ccw
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_odd_spacing_ccw_point_mode
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_odd_spacing_cw
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_odd_spacing_cw_point_mode
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_even_spacing_ccw
dEQP-GL45.functional.tessellation.invariance.tess_coord_component_range.triangles_fractional_even_spacing_ccw_point_mode
Fixes: e5d517f362 ("zink: rework query pool overflow")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22575>
If the submission isn't chained for any reasons, we might end by
submitting the performance counter preambles without a command
buffer that added this BO to its list.
Found by inspection.
Cc: mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22627>
This is to inform you of some planned downtime in the LAVA lab as follows:
Start: 2023-04-24 08:00 GMT
End: 2023-04-24 12:00 GMT
Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22181>
this reimplements the same functionality that exists already, but
using shader object instead of GPL
it must be disabled by default, as this extension is not (currently)
compatible with feedback loops
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22612>
Extracts some per-impl code to nir_lower_vec3_to_vec4 and then
converts to use the nir_shader_instructions_pass helper.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11683>
When wfog support is advertised, unless an orthogonal
projection matrix is detected, w is supposed to be used
instead of z for the fog equation when done in the pixel
shader.
Due to the spec being ambiguous, and tests being incomplete,
it seems we had got things wrong.
New tests confirm the behaviour.
For the explanation we will denote z_vs and w_vs the position
output's z and w channels in the vertex shader, and
z_ps, w_ps the position input z and w channels in the pixel shader.
w_ps = 1/w_vs
z_ps = z_vs/w_vs
In the programmable pixel shader, we used z_ps/w_ps, thus z_vs.
As basically z_vs and w_vs are usually in the same range, we didn't
notice an obvious difference with the correct behaviour.
In the ff pixel shader, we used z_ps for zfog and w_vs else.
z_ps was always used if a programmable vertex shader was detected.
This latter behaviour led to issue
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8341
While using z_ps/w_ps like for programmable ps fixes the issue visually
for the same reason as it did for programmable ps, it breaks
wine tests using XYZRHW. These tests show that when passing
pre-transformed vertices and an orthogonal projection matrix,
z_vs is used, and due to the XYZRHW property, this is not
recovered by the z_ps/w_ps computation (instead z_ps=z_vs).
For the game affected by the issue, the projection matrix set
is not orthogonal.
The direct3D spec indicates that the projection matrix must be
set correctly for fog to work properly, even if we do not use the
transformation pipeline (could be related to xyzrhw, or programmable vs
or both). Previous tests had shown that the projection matrix
has the last two values of the last column tested against 0 and 1,
in order to activate zfog or wfog.
The R500 spec indicates that either z or 1/1/w can be used as source
for the fog computation, but it is not clear whether this is z_vs or
z_ps.
Tests confirmed the intuition that the correct behaviour
is to use z_ps (zfog) when an orthogonal projection matrix is set
(the spec spirit being that in that case z_ps=z_vs),
and 1/w_ps (wfog) else (even if programmable shaders are used).
This patch introduces this behaviour.
Fixes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8341
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22583>
FOGTABLEMODE is 2 bits. It could thus
overwrite the part of the ps key reserved
for centroid interpolation.
Fix the size of FOGTABLEMODE and the key
Signed-off-by: Axel Davy <davyaxel0@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22583>
Apparently dEQP-VK.draw.inverted_depth_ranges.nodepthclamp_deltazero was
renamed to dEQP-VK.draw.renderpass.inverted_depth_ranges.nodepthclamp_deltazero.
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22641>
With the latest changes in opt_algebraic we got f2u32 in the final code
that should be lowered before conversion to assembly.
Fixes: b3685f3ba7
nir/algebraic: insert patterns inside optimizations list
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22640>
