This is actually a no-op on AMD, so we really don't want to lower it to
something more complicated. There may be a more efficient way to do
this on Intel too. In addition, in the future we'll want to use this for
lowering boolean reduce operations, where the inverse ballot will
operate on the backend's "natural" ballot type as indicated by
options->ballot_bit_size, instead of uvec4 as produced by SPIR-V. In
total, there are now three possible lowerings we may have to perform:
- inverse_ballot with source type of uvec4 from SPIR-V to inverse_ballot
with natural source type, when the backend supports inverse_ballot
natively.
- inverse_ballot with source type of uvec4 from SPIR-V to arithmetic,
when the backend doesn't support inverse_ballot.
- inverse_ballot with natural source type from reduce operation, when
the backend doesn't support inverse_ballot.
Previously we just did the second lowering unconditionally in vtn, but
it's just a combination of the first and third. We add support here for
the first and third lowerings in nir_lower_subgroups, instead of simply
moving the second lowering, to avoid unnecessary churn.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25123>
Since using nir_shader_lower_instructions(), instructions get revisited
before proceeding with the next one. This already guarantees that any
subsequent lowerings of those instructions happen during the same pass
of nir_lower_subgroups().
v2: use nir_shader_lower_instructions() instead of setting the cursor.
Co-authored-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25123>
Currently, we store strides by vertex buffer id, which means that we have
to map the binding index to the vertex buffer index every time we want to
get a stride for a given binding. This also creates an order mismatch when
we pass strides directly to CmdBindVertexBuffers2EXT. Instead of converting
strides for CmdBindVertexBuffers2EXT too, we can just store strides by
binding id, and drop the mapping in other places.
Fixes: 76725452 ("gallium: move vertex stride to CSO")
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9817
Signed-off-by: Sviatoslav Peleshko <sviatoslav.peleshko@globallogic.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25305>
While earlier changes to pipe control emission allowed debug dump of
each pipe control, they also changed debug output to almost always print
same reason/function for each pc. These changes fix the output so that
we print the original function name where pc is emitted.
As example:
pc: emit PC=( +depth_flush +rt_flush +pb_stall +depth_stall ) reason: gfx11_batch_emit_pipe_control_write
pc: emit PC=( ) reason: gfx11_batch_emit_pipe_control_write
changes back to:
pc: emit PC=( +depth_flush +rt_flush +pb_stall +depth_stall ) reason: gfx11_emit_apply_pipe_flushes
pc: emit PC=( ) reason: cmd_buffer_emit_depth_stencil
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25282>
This fixes several tests when the initially uploaded buffer
from CPU was being ignored because vc4_texture_subdata was not
marking the resource as written/initialized.
The usage flags management available at vc4_resource_transfer_map
is generalized into vc4_map_usage_prep and reused at
vc4_resource_transfer_map. This makes vc4 implementation more similar
to v3d.
This fixes 7 text in the following subgroups:
-dEQP-GLES2.functional.fbo.render.texsubimage.*
-dEQP-GLES2.functional.texture.specification.basic_copytexsubimage2d.*
-spec@arb_clear_texture@arb_clear_texture-*
Cc: mesa-stable
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25297>
Iris in general doesn't really like checking the return value of its
allocations, but in some places it does assert that those pointers are
non-NULL. We've recently investigated a bug that could have been
coming from a failed bo->deps realloc(), so add the assert() here to
help give us more confidence over things the next time we're debugging
issues.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25236>
Keep most cases using the stack as it's cheaper, but fall back to the
heap when the size gets too big.
This should fix a stack overflow reported by @rhezashan for a case
where we had lots of iris_screens.
Credits to Matt Turner and José Roberto de Souza for their work on
this issue, which led us to find its root cause.
Cc: mesa-stable
Reported-by: rheza shandikri (@rhezashan in gitlab)
Credits-to: José Roberto de Souza <jose.souza@intel.com>
Credits-to: Matt Turner <mattst88@gmail.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25236>
This is the only place that touches bo->deps but does not explicitly
lock it and is not a setup/teardown function where locking won't help
anything.
I'm confident we won't hit this assertion, but I've recently had this
lock as the suspect of a bug and had to check the callers to see if we
could be calling from any unlocked place. Having the assert helps
increasing our confidence.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25236>
We want to do this in general, right now the stats are not that good but
that will be taken care of in the next commits.
RV530:
total instructions in shared programs: 93561 -> 93597 (0.04%)
instructions in affected programs: 39015 -> 39051 (0.09%)
helped: 207
HURT: 212
total temps in shared programs: 12864 -> 13019 (1.20%)
temps in affected programs: 2010 -> 2165 (7.71%)
helped: 57
HURT: 181
total cycles in shared programs: 144639 -> 144506 (-0.09%)
cycles in affected programs: 54524 -> 54391 (-0.24%)
helped: 191
HURT: 234
RV370:
total instructions in shared programs: 63692 -> 63811 (0.19%)
instructions in affected programs: 16851 -> 16970 (0.71%)
helped: 121
HURT: 141
total temps in shared programs: 9966 -> 10050 (0.84%)
temps in affected programs: 969 -> 1053 (8.67%)
helped: 33
HURT: 126
total cycles in shared programs: 101042 -> 101205 (0.16%)
cycles in affected programs: 20606 -> 20769 (0.79%)
helped: 121
HURT: 155
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24932>