<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - ir_variable has maximum access out of bounds -- but it's not out of bounds" href="https://bugs.freedesktop.org/show_bug.cgi?id=109532#c36">Comment # 36</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - ir_variable has maximum access out of bounds -- but it's not out of bounds" href="https://bugs.freedesktop.org/show_bug.cgi?id=109532">bug 109532</a> from <a class="email" href="mailto:andrey.simiklit@gmail.com" title="asimiklit <andrey.simiklit@gmail.com>"> asimiklit</a> <pre>(In reply to Ian Romanick from <a href="show_bug.cgi?id=109532#c33">comment #33</a>) > (In reply to andrii simiklit from <a href="show_bug.cgi?id=109532#c32">comment #32</a>) > > (In reply to andrii simiklit from <a href="show_bug.cgi?id=109532#c31">comment #31</a>) > > > (In reply to Mark Janes from <a href="show_bug.cgi?id=109532#c30">comment #30</a>) > > > > (In reply to Mark Janes from <a href="show_bug.cgi?id=109532#c28">comment #28</a>) > > > > > <a href="https://android-review.googlesource.com/c/platform/external/deqp/+/901894">https://android-review.googlesource.com/c/platform/external/deqp/+/901894</a> > > > > > > > > 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: > > > <a href="https://patchwork.freedesktop.org/patch/286287/">https://patchwork.freedesktop.org/patch/286287/</a> > > > 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: > > > <a href="https://github.com/asimiklit/deqp/commit/">https://github.com/asimiklit/deqp/commit/</a> > > > 91cff8150944213f6da533e281ee76d95ca00f21 > > > If it helps them we will know that it is a common issue and it could > > > expedite this: > > > <a href="https://github.com/KhronosGroup/OpenGL-API/issues/46">https://github.com/KhronosGroup/OpenGL-API/issues/46</a> > > > > 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. Ilia could you please share your thoughts about this solution? Do you agree with Ian suggestion as to disallow the elimination from the beginning of the array? I am asking about it to understand have we consensus as to a direction of the fix or not.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>