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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #35 from asimiklit <andrey.simiklit at gmail.com> ---
Created attachment 143430
  --> https://bugs.freedesktop.org/attachment.cgi?id=143430&action=edit
patch to disallow an elimination of the first unused ub/ssbo array elements

(In reply to Ian Romanick from comment #33)
> (In reply to andrii simiklit from comment #32)
> > (In reply to andrii simiklit from comment #31)
> > > (In reply to Mark Janes from comment #30)
> > > > (In reply to Mark Janes from comment #28)
> > > > >   https://android-review.googlesource.com/c/platform/external/deqp/+/901894
> > > > 
> > > > Mesa still asserts with this fix.  I also tested Andrii's mesa patch with
> > > > the dEQP fix and the test fails.
> > > Do you mean the Chris's dEQP fix here, yes?
> > > But looks like the mentioned Chris's dEQP fix considers some GL limitations
> > > and doesn't affect the expectations of binding points.
> > > 
> > > Also the assertion is a separate issue, I created the piglit test for that:
> > > https://patchwork.freedesktop.org/patch/286287/
> > > But yes, we unable to fix the test fail without assertion because of crash
> > > :-)
> > > 
> > > > 
> > > > Since non-mesa drivers have found issues with the original dEQP change, I
> > > > suspect there are still deeper problems with the test.
> > > Possible they have the same issue with binding points mismatch after
> > > optimizations by glsl compiler. 
> > > They could try this fix/hack for deqp which is already helped us:
> > > https://github.com/asimiklit/deqp/commit/
> > > 91cff8150944213f6da533e281ee76d95ca00f21
> > > If it helps them we will know that it is a common issue and it could
> > > expedite this:
> > > https://github.com/KhronosGroup/OpenGL-API/issues/46
> > 
> > So we have an answer from Piers Daniell:
> >   "I believe all buffer binding points should be consumed, regardless
> > whether 
> >    the array elements are used or not. This would be the behavior of least 
> >    surprise to the developer. I didn't see any language that would indicate 
> >    that unused elements should not be counted when assigning the element to 
> >    the buffer binding point."
> 
> I think this basically agrees with my earlier sentiment that we shouldn't
> trim elements from the beginning of the array.  It's generally ok (and in
> some cases expected) to trim elements from the end.

Are you talking about something like attached variant?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190221/22b26eb9/attachment-0001.html>