On 06/06/18 19:10, Neil Roberts wrote:
Timothy Arceri <tarc...@itsqueeze.com> writes:

+static struct type_tree_entry *
+build_type_tree_for_type(const struct glsl_type *type)
+{

Do we really need this? As far as I can tell we walk the types here to
build a tree then in nir_link_uniform() we walk the tree. Why not just
walk the types directly in nir_link_uniform()?

The tree is needed as a temporary place to store the next_index and
detect whether a node in the type tree is encountered for the first time
or not. The nodes can be encountered multiple times because if there is
an array of structs or array of arrays then we process the subtree of
the array once for each element in the array.

In nir_link_uniform, it effectively _is_ directly walking the glsl_type
tree. However it simultaneously walks the type_tree tree as well for
this extra side-band information.

The GLSL linker handles this instead by using a hash table to store the
next index (see set_opaque_indices in link_uniforms.cpp). The key for
the table is the name of the uniform with all array indices removed. I
suppose we could try to do something similar for the nir linker but it
would have to use a different key because we don’t have the names.
However my gut feeling is that that wouldn’t be any more efficient then
using this side-band tree and the code to generate the hash table key
looks quite involved.

Ok thanks for the added context. I'll try take another look at this patch tomorrow.


If you can think of a simpler way to handle this then of course I am
open to suggestions.

Thanks for looking at the patch.

Regards,
- Neil

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to