<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#c50">Comment # 50</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#c49">comment #49</a>) > After discussing <a href="https://github.com/KhronosGroup/OpenGL-API/issues/46">https://github.com/KhronosGroup/OpenGL-API/issues/46</a> in the > Khronos call today, I realized that my thinking about this bug may have been > slightly incorrect. I believe that there are two separate issues here. > > 1. The issue with the array type and the maximum index. > > 2. The way the bindings are assigned to the elements that are used. > > No matter what happens, if the shader says > > layout(packed, binding = 3) buffer Block > { > float b[1]; > } block[4]; > > Then the thing accessed in the shader as block[2].b[0] **must** be at > binding point 5 (from the API). The user as explicitly set that to binding > 5 by the declaration in the shader, so we absolutely have to respect that. > Had the application not explicitly set the bindings, I think we would be > free to assign whatever values we wanted. I believe that means the bindings > set by the CTS in the problematic test are correct. > > I think we also cannot reuse the intermediate bindings. The app may have > expectations that those bindings are for elements of block, and it may > blindly bind buffers to those bindings. If those bindings are used for > other things, only problems can result. I think this means we effectively > cannot eliminate array elements from buffer block arrays that have explicit > bindings. 85% sure, anyway. Ian could you please confirm if I understood everything correctly and clarify the **implicit case** too. 1. So everything is clear when user explicitly set binding point, in this case we should not optimize anything at all. 2. But looks like we are not 100% sure what to do with the **implicit case**. Let's consider options: layout(packed) buffer Block { float b[1]; } block[6]; (The shader uses block[1] and block[4]) 2.1. As it works now. Eliminate any unused array elements and shrink array to reuse binding points. (Note: will not pass deqp test) + we spend just 2 binding points for Block[1], Block[4] - it very unexpected behavior for user because: Block[0] is eliminated Block[1] binding point is 0 Block[2] is eliminated Block[3] is eliminated Block[4] binding point is 1 Block[5] is eliminated 2.2. Find first and last used elements and eliminate any before the first and after the last. This option was suggested by Ilia, Ian do you agree it? (Note: looks like should pass deqp test) + we spend 4 of 6 binding points - it better than 2.1 but looks like still not very expected behavior for user: Block[0] is eliminated Block[1] binding point is 0 Block[2] binding point is 1 Block[3] binding point is 2 Block[4] binding point is 3 Block[5] is eliminated 2.3. Find just last used element and eliminate any after the last. + we spend 5 of 6 binding points (Note: but if there is a big array with a big unused tail it should helps) +- quite expected behavior for user: Block[0] binding point is 0 Block[1] binding point is 1 Block[2] binding point is 2 Block[3] binding point is 3 Block[4] binding point is 4 Block[5] is eliminated 2.4. Avoid elimination at all like for explicitly case + very expected behavior for user - we spend 6 of 6 binding points Block[0] binding point is 0 Block[1] binding point is 1 Block[2] binding point is 2 Block[3] binding point is 3 Block[4] binding point is 4 Block[5] binding point is 5 I created MR for it: <a href="https://gitlab.freedesktop.org/mesa/mesa/merge_requests/332">https://gitlab.freedesktop.org/mesa/mesa/merge_requests/332</a> It has WIP status because we aren't reached an agreement yet. But anyway I will be glad to see any advices there.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>