[Mesa-dev] About the usage of the "flat" interpolation qualifier with input (unsigned) integers and doubles in fragment shaders

[Andres Gomez]

Hi,

Thanks, Jason and Ian, for the feedback. See the patch sent at:
https://lists.freedesktop.org/archives/mesa-dev/2016-April/111842.html

Br.

On Wed, 2016-03-23 at 14:51 -0700, Ian Romanick wrote:
> On 03/18/2016 09:52 PM, Jason Ekstrand wrote:
> > 
> > 
> > 
> > On Fri, Mar 4, 2016 at 5:43 AM, Andres Gomez <agomez at igalia.com
> > <mailto:agomez at igalia.com>> wrote:
> > 
> >     Hi,
> > 
> >     as complementary work to the one done to "Add FP64 support to
> > the i965
> >     shader backends" at:
> >     https://bugs.freedesktop.org/show_bug.cgi?id=92760
> > 
> >     I've been working to add piglit tests that would check the new
> > features
> >     added by this addition.
> > 
> >     Checking the specification of the extension, when talking about
> > inputs,
> >     the extension instructs that any fragment input being a double
> > or
> >     derived type must be qualified with the interpolation qualifier
> > "flat".
> > 
> >     This extends the restriction that already existed for signed
> > and
> >     unsigned integers to doubles too.
> > 
> >     In following versions of the spec, when doubles are already
> > part of it
> >     we can read:
> > 
> >     "
> >     Fragment shader inputs that are signed or unsigned integers,
> > integer
> >     vectors, or any double-precision floating-point type must be
> > qualified
> >     with the interpolation qualifier flat.
> >     "
> > 
> >     The specification doesn't explicitly say it, but as far as I
> > understand,
> >     it is reasonable to think that the restriction applies to input
> >     variables in the form of arrays or members of structures of
> > these types.
> > 
> > 
> > Yes, I think that's a reasonable assumption.  The reason it's
> > required
> > for integers is because you can't interpolate them at all.  Some
> > hardware may also not support interpolating doubles so they are
> > included
> > in the statement.  Incidentally, we could implement it in i965
> > because
> > Intel hardware does its interpolation in the shader.  That does
> > not,
> > however, mean that we should :-)
> That might be an interesting extension, should anyone ever care.
> *shrug*
> 
> > 
> >     In fact, current implementation already fails on compilation if
> > a
> >     non-flat integer is in a fragment input as an array or a struct
> > member.
> >     The same happens with doubles (llvmpipe).
> > 
> >     It is also reasonable to think that the restriction would also
> > apply to
> >     input interface blocks holding variables of these types.
> > 
> >     However, the compilation doesn't fail when using a non-flat
> > integer or a
> >     double. On execution, the integer version just gives bogus
> > values while,
> >     with doubles, it crashes.
> > 
> >     --
> > 
> >     The situation with the glslangValidator is (it doesn't support
> > doubles):
> >           * When using a non-flat integer as a fragment input in
> > the form of
> >             an array or as a member of a struct it fails with an
> > error of
> >             the type:
> > 
> >     int' : must be qualified as flat in
> > 
> >           * When using a non-flat integer as a fragment input in
> > the form of
> >             a member of an interface block it succeeds on
> > compilation.
> > 
> > 
> > Glslang is an ok compiler, but I wouldn't give it too much
> > weight.  Just
> > because it's billed as a "reference compiler" doesn't mean you
> > should
> > trust it to get all the edge cases right.  I've personally fixed
> > enough
> > bugs in it to now better ;-)
> I would suggest submitting a bug against glslang as well.
> 
> > 
> >     The situation with nvidia proprietary driver is:
> >           * When using a non-flat integer as a fragment input in
> > the form of
> >             a scalar, an array, a member of a struct or a member of
> > an
> >             interface block it doesn't fail on compilation but on
> > linkage
> >             with an error of the type:
> > 
> >     error C5215: Integer varying <variable> must be flat
> > 
> >           * When using a double as a fragment input in the form of
> > a scalar
> >             or an array it fails on compilation with an error of
> > the type:
> > 
> >     error C7570: 64 bit input '<variable>' should be flat
> > 
> >           * When using a double as a fragment input in the form of
> > a a
> >             member of a struct or a member of an interface block it
> > doesn't
> >             fail. Actually, it seems to do some kind of
> > interpolation.
> > 
> >     --
> > 
> >     Hence, based on this, my proposal would be:
> >           * To enforce the usage of the "flat" qualifier when in a
> > member of
> >             an input block interface in a fragment shader for
> > (unsigned)
> >             integers and doubles.
> > 
> > 
> > Agreed.  That seems like the right thing to do.
> >  
> > 
> >           * Open a bug in Khronos specs bugzilla about the
> > ambiguity of
> >             this.
> > 
> > 
> > Done.  Khronos bug #15671.
> > 
> >     Opinions?
> > 
> >     --
> >     Br,
> > 
> >     Andres
> > 
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 
-- 
Br,

Andres

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160404/bb64c8f8/attachment.sig>