[Mesa-dev] [Bug 106915] [GLSL] Unused arrays declared without a size should be handled like arrays of size 1.

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Jun 16 01:20:09 UTC 2018


Ian Romanick <idr at freedesktop.org> changed:

           What    |Removed                     |Added
             Status|NEW                         |NEEDINFO

--- Comment #2 from Ian Romanick <idr at freedesktop.org> ---
(In reply to Ian Romanick from comment #1)
> (In reply to Eleni Maria Stea from comment #0)
> > "An array implicitly sized in one shader can be explicitly sized by another
> > shader in the same stage. If no shader in a stage has an explicit size for
> > the array, the largest implicit size (one more than the largest index used)
> > in that stage is used. There is no cross-stage array sizing. If there is no
> > static access to an implicitly sized array within the stage declaring it,
> > then the array is given a size of 1, which is relevant when the array is
> > declared within an interface block that is shared with other stages or the
> > application (other unused arrays might be eliminated by the optimizer)."
> I think we should submit a spec bug for this.  There is explicit language in
> the spec that says that only the last member of an SSBO may be declared
> without a size.  See issue #2 in the ARB_shader_storage_buffer_object spec.

Before we do that... does this work on other implementations?  I am very
surprised that this is valid, as it does not match recollection of how we
designed SSBOs.  I'll be a little surprised if this works on other drivers. 
Let's collection some information about that, then decide how to proceed.

Which ever way is determined to be correct, we should also add a test for the

You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180616/75cbec89/attachment.html>

More information about the mesa-dev mailing list