Otherwise a scoped memory barrier containing nir_var_mem_ubo (which
memoryBarrier() does lower to) would incorrectly prevent the
optimization to happen in UBOs.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5980>
We've hand-rolled this loop 10 places and those are just the ones I
found easily.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5966>
Now that nir_foreach_variable_with_modes can handle multiple modes at
one time, we can simplify things a bit and only walk the list once.
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5966>
Instead of having separate lists of variables, roughly sorted by mode,
use a single list for all shader-level NIR variables. This makes a few
list walks a bit longer here and there but list walks aren't a very
common thing in NIR at all. On the other hand, it makes a lot of things
like validation, printing, etc. way simpler. Also, there are a number
of cases where we move variables from inputs/outputs to globals and this
makes it way easier because we no longer have to move them between
lists. We only have to deal with that if moving them from the shader to
a nir_function_impl.
Reviewed-by: Rob Clark <robdclark@chromium.org>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5966>
We can get the result type information easily from nir_tex_instr itself
by looking at dest_type. There's no reason to construct a vector and
try to index into it.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5966>
We also very slightly change the semantics. It no longer is one index
per list for global variables and is a single index over-all.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5966>
We also add a new list iterator which takes a modes bitfield and
automatically figures out which list to use. In the future, this
iterator will work for multiple modes but today it assumes a single mode
thanks to the behavior of nir_variable_list_for_mode. This also doesn't
work for function_temp variables.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5966>
There are a bunch of cases where we really do want to walk the list that
is nir->uniforms because we want all things declared "uniform" in the
GLSL. Add a helper for this but restrict it to the GL linking code.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5966>
This one's a bit more complex because it filters off only those
variables with mode == nir_var_uniform. As such, it's not exactly a
drop-in replacement for nir_foreach_variable(var, &nir->uniforms).
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5966>
For the most part, this doesn't actually matter today. We already only
call remove_dead_vars on the lists that are specified in the modes. The
only functional change here is for the uniform, mem_ubo, and mem_ssbo
modes because they share a list. If nir_remove_dead_variables is called
with a mode of nir_var_uniform, it will no longer remove UBOs or SSBOs,
for instance.
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5966>
The "Fixes:" tag example has the commit title in double quotes, whereas the
suggested git fixes alias, a couple of lines below, also adds some outer
parenthesis.
Although there doesn't appear to be a consistent format for the "Fixes:" tag,
other than it should be a git commit sha followed by the commit title, the
information in the docs should at least be consistent. As the "Fixes:" tag was
inspired by the Linux kernel, which does have parenthesis, update the example to
match the git fixes output.
Signed-off-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6106>
We are using unnamed arrays to describe repeating portions of a pm4
packet. So allow the name to be optional. Instead of just using
the empty-string hack, drop the attribute.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6107>
Rhys Perry
Caio Marcelo de Oliveira Filho
Jason Ekstrand
Frank Binns
Rob Clark