On 29/11/17 00:54, Gert Wollny wrote:
Am Dienstag, den 28.11.2017, 08:45 +1100 schrieb Timothy Arceri:
If I understand the comments in opt_array_splitting, arrays of
arrays are not properly handled there. Curretly, I don't see how I
can fix this, because I simply didn't look at any code there
before.
There is more to it than that. We don't even split varyings at all
currently.
"This skips uniform/varying arrays, which would need careful
handling due to their ir->location fields tying them to the GL API
and other
shader stages."
This is enforced in get_variable_entry() via:
if (var->data.mode != ir_var_auto &&
var->data.mode != ir_var_temporary)
return NULL;
As per my previous email I don't think there is much value in putting
a bunch of work into this pass.
For me this raises the question whether it would make sense to push the
patch that I sent (probably changing the name of the method to
"split_arrays") and that addresses the problem in the glsl->tgsi stage
(I can't push it anyway) and is currently useful at least for r600?
Since I think about another improvement in this stage(*) that would
further reduce the register pression, I wonder whether it is worth to
put effort in this or whether this change you talked about switch to
nir->tgsi can be expected to replace glsl->tgsi anytime soon?
Seems not, I was sure a nir->tgsi pass with limited support already
existed but seems I was dreaming.
(*) The idea is to also implement array merging and interleaving,
because with r600 the number of registers is quite limited, and arrays
really cut into that, especially if the arrays use only one component.
Yes I have NIR patches to do the same thing, they also do some cross
linking so that undefined or unused components are remove across stages.
many thanks,
Gert
Best,
Gert
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
