[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