[Bug 109532] ir_variable has maximum access out of bounds -- but it's not out of bounds

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Feb 5 16:02:40 UTC 2019


https://bugs.freedesktop.org/show_bug.cgi?id=109532

--- Comment #9 from asimiklit <andrey.simiklit at gmail.com> ---
(In reply to Ilia Mirkin from comment #8)
> (In reply to asimiklit from comment #7)
> > (In reply to Ilia Mirkin from comment #2)
> > > Looks like this is happening in link_uniform_blocks. The type gets updated:
> > > 
> > >       if (b->array != NULL &&
> > >           (b->type->without_array()->interface_packing ==
> > >            GLSL_INTERFACE_PACKING_PACKED)) {
> > >          b->type = resize_block_array(b->type, b->array);
> > >          b->var->type = b->type;
> > >       }
> > > 
> > > But no change to the corresponding max_data_access. However doing the naive
> > > thing here didn't help -- the shader fails. I didn't investigate why. I
> > > think create_buffer_blocks also needs to be involved somehow.
> > 
> > Thanks a lot your message was very helpful to find the start point of
> > investigation.
> > 
> > Looks like this thing is helped:
> > 
> > ---
> >  src/compiler/glsl/link_uniform_blocks.cpp | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/src/compiler/glsl/link_uniform_blocks.cpp
> > b/src/compiler/glsl/link_uniform_blocks.cpp
> > index 0b890586298..5197870a6d9 100644
> > --- a/src/compiler/glsl/link_uniform_blocks.cpp
> > +++ b/src/compiler/glsl/link_uniform_blocks.cpp
> > @@ -438,8 +438,15 @@ link_uniform_blocks(void *mem_ctx,
> >        if (b->array != NULL &&
> >            (b->type->without_array()->interface_packing ==
> >             GLSL_INTERFACE_PACKING_PACKED)) {
> > +         const int new_max_array_access =
> > (int)(b->array->num_array_elements - 1);
> >           b->type = resize_block_array(b->type, b->array);
> >           b->var->type = b->type;
> > +
> > +         assert(((int)b->array->array_elements[new_max_array_access] ==
> > +                b->var->data.max_array_access ||
> > +                b->var->data.max_array_access == -1) && "Is last index is
> > proper");
> > +
> > +         b->var->data.max_array_access = new_max_array_access;
> >        }
> >  
> >        block_size.num_active_uniforms = 0;
> > -- 
> > 2.17.1
> > 
> > Did you mean the same thing saying "naive thing" or this change helps?
> 
> Well, as I recall the thing I tried was just saying max_array_access = 0 or
> -1 unconditionally. It could also have been due to some secondary issue with
> nouveau that this failed -- like I said, I didn't investigate. I'll have a
> closer look tonight.

Got it.

> 
> You're basically setting
> 
> b->var->data.max_array_access = b->type->length - 1
> 
> right?

Yes. I guess that the optimized array size - 1 is a new max_array_access. 


But in case if optimization algorithm has some unexpected behavior and could
left some unused elements in array I guess the search will be required:
for (int i = 0; i < b->array->num_array_elements; i++)
{
   if(b->var->data.max_array_access == b->array->array_elements[i])
   {
     b->var->data.max_array_access = i;
     break;
   }
}(In reply to Ilia Mirkin from comment #8)
> (In reply to asimiklit from comment #7)
> > (In reply to Ilia Mirkin from comment #2)
> > > Looks like this is happening in link_uniform_blocks. The type gets updated:
> > > 
> > >       if (b->array != NULL &&
> > >           (b->type->without_array()->interface_packing ==
> > >            GLSL_INTERFACE_PACKING_PACKED)) {
> > >          b->type = resize_block_array(b->type, b->array);
> > >          b->var->type = b->type;
> > >       }
> > > 
> > > But no change to the corresponding max_data_access. However doing the naive
> > > thing here didn't help -- the shader fails. I didn't investigate why. I
> > > think create_buffer_blocks also needs to be involved somehow.
> > 
> > Thanks a lot your message was very helpful to find the start point of
> > investigation.
> > 
> > Looks like this thing is helped:
> > 
> > ---
> >  src/compiler/glsl/link_uniform_blocks.cpp | 7 +++++++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/src/compiler/glsl/link_uniform_blocks.cpp
> > b/src/compiler/glsl/link_uniform_blocks.cpp
> > index 0b890586298..5197870a6d9 100644
> > --- a/src/compiler/glsl/link_uniform_blocks.cpp
> > +++ b/src/compiler/glsl/link_uniform_blocks.cpp
> > @@ -438,8 +438,15 @@ link_uniform_blocks(void *mem_ctx,
> >        if (b->array != NULL &&
> >            (b->type->without_array()->interface_packing ==
> >             GLSL_INTERFACE_PACKING_PACKED)) {
> > +         const int new_max_array_access =
> > (int)(b->array->num_array_elements - 1);
> >           b->type = resize_block_array(b->type, b->array);
> >           b->var->type = b->type;
> > +
> > +         assert(((int)b->array->array_elements[new_max_array_access] ==
> > +                b->var->data.max_array_access ||
> > +                b->var->data.max_array_access == -1) && "Is last index is
> > proper");
> > +
> > +         b->var->data.max_array_access = new_max_array_access;
> >        }
> >  
> >        block_size.num_active_uniforms = 0;
> > -- 
> > 2.17.1
> > 
> > Did you mean the same thing saying "naive thing" or this change helps?
> 
> Well, as I recall the thing I tried was just saying max_array_access = 0 or
> -1 unconditionally. It could also have been due to some secondary issue with
> nouveau that this failed -- like I said, I didn't investigate. I'll have a
> closer look tonight.

Got it.

> 
> You're basically setting
> 
> b->var->data.max_array_access = b->type->length - 1
> 
> right?

Yes. I guess that the optimized array size - 1 is a new max_array_access.

But in case if optimization algorithm has some "unexpected behavior" and could
left some unused elements at the end of array for some reason I guess the some
search may be required:

for (int i = 0; i < b->array->num_array_elements; i++)
{
   if(b->var->data.max_array_access == b->array->array_elements[i])
   {
     b->var->data.max_array_access = i;
     break;
   }
}

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-3d-bugs/attachments/20190205/5948cc48/attachment.html>


More information about the intel-3d-bugs mailing list