[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 #50 from asimiklit <andrey.simiklit at gmail.com> ---
(In reply to Ian Romanick from comment #49)
> After discussing https://github.com/KhronosGroup/OpenGL-API/issues/46 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:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/332
It has WIP status because we aren't reached an agreement yet.
But anyway I will be glad to see any advices there.

-- 
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/20190228/68a8f538/attachment.html>