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>
In general, sinking ALU instructions can negatively impact register pressure,
since it extends the live ranges of the sources, although it does shrink the live range
of the destination.
However, constants do not usually contribute to register pressure. This is not a
totally true assumption, but it's pretty good in practice, since...
* constants can be rematerialized (backend-dependent)
* constants can often be inlined (ISA-dependent)
* constants can sometimes be promoted to free uniform registers (ISA-dependent)
* constants can live in scalar registers although the ALU destination might need
a vector register (and vector registers are assumed to be much more expensive
than scalar registers, again ISA-dependent)
So, assume that constants have zero effect on register pressure. Now consider an
ALU instruction where all but one source is a constant. Then there are two
cases:
1. The ALU instruction is moved past when its source was otherwise killed. Then
there is no effect on register pressure, since the source live range is
extended exactly as much as the destination live range shrinks.
2. The ALU instruction is moved down but its source is still alive where it's
moved to. Then register pressure is improved, since the source live range is
unchanged while the destination live range shrinks.
So, as a heuristic, we always move ALU instructions where n-1 sources are
constant. As an inevitable special case, this also (necessarily) moves unary ALU
ops, which should be beneficial by the same justification. This is not 100%
perfect but it is well-motivated. Results on AGX are decent:
total instructions in shared programs: 1796101 -> 1795652 (-0.02%)
instructions in affected programs: 326822 -> 326373 (-0.14%)
helped: 800
HURT: 371
Inconclusive result (%-change mean confidence interval includes 0).
total bytes in shared programs: 11805004 -> 11801424 (-0.03%)
bytes in affected programs: 2610630 -> 2607050 (-0.14%)
helped: 912
HURT: 462
Inconclusive result (%-change mean confidence interval includes 0).
total halfregs in shared programs: 525818 -> 515399 (-1.98%)
halfregs in affected programs: 118197 -> 107778 (-8.81%)
helped: 2095
HURT: 804
Halfregs are helped.
total threads in shared programs: 18916608 -> 18917056 (<.01%)
threads in affected programs: 4800 -> 5248 (9.33%)
helped: 7
HURT: 0
Threads are helped.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24833>
