[Mesa-dev] [PATCH 08/12] nir/types: Make glsl_get_length smarter

Jason Ekstrand jason at jlekstrand.net
Fri Apr 17 10:38:39 PDT 2015


On Fri, Apr 17, 2015 at 6:06 AM, Rob Clark <robdclark at gmail.com> wrote:
> On Fri, Apr 17, 2015 at 9:03 AM, Rob Clark <robdclark at gmail.com> wrote:
>> On Fri, Apr 10, 2015 at 8:48 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>> Previously, this function returned the number of elements for structures
>>> and arrays and 0 for everything else.  In NIR, this is almost never what
>>> you want because we also treat matricies as arrays so you have to
>>> special-case constantly.  We already had a helper for this in two places
>>> and should have had one in lower_vars_to_ssa.  We might as well make
>>> glsl_get_length just do the right thing in the first place.
>>>
>>> This also fixes a bug in locals_to_regs caused by not checking for the
>>> matrix case in one place.
>>
>> so, as this is, it blows up ttn, because all of a sudden vec4's become
>> length 4 instead of 0.. see below
>>
>>
>>> ---
>>>  src/glsl/nir/nir_lower_locals_to_regs.c | 11 ++---------
>>>  src/glsl/nir/nir_lower_var_copies.c     | 24 ++----------------------
>>>  src/glsl/nir/nir_lower_vars_to_ssa.c    | 26 +++-----------------------
>>>  src/glsl/nir/nir_types.cpp              | 16 +++++++++++++++-
>>>  4 files changed, 22 insertions(+), 55 deletions(-)
>>>

[snip]

>>> diff --git a/src/glsl/nir/nir_types.cpp b/src/glsl/nir/nir_types.cpp
>>> index f0d0b46..10be6df 100644
>>> --- a/src/glsl/nir/nir_types.cpp
>>> +++ b/src/glsl/nir/nir_types.cpp
>>> @@ -103,7 +103,21 @@ glsl_get_matrix_columns(const struct glsl_type *type)
>>>  unsigned
>>>  glsl_get_length(const struct glsl_type *type)
>>>  {
>>> -   return type->length;
>>> +   switch (glsl_get_base_type(type)) {
>>> +   case GLSL_TYPE_STRUCT:
>>> +   case GLSL_TYPE_ARRAY:
>>> +      return type->length;
>>> +   case GLSL_TYPE_FLOAT:
>>> +   case GLSL_TYPE_INT:
>>> +   case GLSL_TYPE_UINT:
>>> +   case GLSL_TYPE_BOOL:
>>> +      if (type->is_matrix())
>>> +         return type->matrix_columns;
>>> +      else
>>> +         return type->vector_elements;
>>
>> So I *think* you want to return 0 instead of type->vector_elements..
>> either that or for a matrix you would want matrix_columns *
>> vector_elements?  It at least seems inconsistent for a vector to
>> return number of elements, but a matrix to only return number of
>> vectors

The idea was to return whatever number of "thing"s the type has.  From
NIR's perspective, since we don't have a matrix type, a matrix is a
vec4[4] so it has 4 things.  An array has the length number of things,
a structure has field elements, and a vector has components.  The
reason for this last one is that, if we ever want to scalarize
load/store operations, we will need vectors to also have a length.
Even there, how does it make sense for a vec4 to have a length of 0?
Should it be at least 1?

>> I'm not quite sure what you expect the array length to be for vecN's..
>> it's possible that we need to adjust expectations in ttn (and vc4 and
>> freedreno/ir3)..
>
> oh, I should add that with this locally changed to return 0 instead of
> vector_elements, on top of your other variable-indexing patches: 11
> fail->pass out of variable-indexing tests..

Glad to hear it!
--Jason


More information about the mesa-dev mailing list